本期主题
云：多即是少？
在主流云服务提供商提供的核心功能日益趋同的当下，竞争焦点已经转移到他们能够提供的附加服务上，这就鼓励了云服务商以惊人的速度发布新产品。为在竞争中取得优势，很多新服务还在存有瑕疵、功能尚不完整的阶段，就被匆匆推向市场。过分关注速度以及产品扩张，常常导致这些由收购或仓促打造而来的服务缺陷频出，文档质量差，难于实现自动化，以及与服务商自己的其他服务不能完整集成。团队在尝试使用云服务提供商承诺的功能却经常遇到问题的时候，会感到挫败。考虑到在选择云服务提供商时，通常都是由组织高层基于各个不同维度进行决策，我们建议实施团队：不要假设你们的云服务提供商的所有服务都能确保相同的质量，应该对关键功能进行测试。如果你们的产品上市时间能够容纳额外的运维开销，可以考虑替代的开源解决方案，或者使用多云策略。
保护软件供应链
组织应该抵制冗长的人工检测和需要审批的象牙塔治理规则。相反，自动化的依赖保护（依赖漂移适应度函数），安全性（安全策略即代码）和其他治理机制（运行成本纳入架构适应度函数）可以保护软件项目中重要但不紧急的部分。这个关于策略、合规性和治理即代码的主题在我们对话中多次出现。我们看到自动化不断提升的软件开发生态系统的自然演化：与自动测试、持续交付和基础设施即代码的持续集成，以及如今的自动化治理。云成本、依赖管理、架构结构等以往人工流程的自动化呈现出一种自然演进的态势；我们正在学习如何让软件交付中的所有重要方面自动化。
打开机器学习的黑匣子
通过使用模式匹配、反向传播和其他众所周知的技术，机器学习通常貌似能解决人类所无法解决的问题。然而，尽管这些技术功能强大，但许多模型本质上令人费解。这意味着机器学习所计算的结果，无法用逻辑推理来解释。所以，当需要了解决定是如何做出，或存在将偏见、抽样、算法或其他偏差引入模型的风险时，人们就会一筹莫展。现在我们看到，诸如假设分析之类的工具，以及道德偏差测试这样的技术正在涌现出来。这些工具和技术可以帮助我们发现模型的局限性，并预测模型的输出结果。尽管这些在可解释性方面的改进，是朝着正确方向迈出的一步，但理解深度神经网络，仍然是一个遥不可及的目标。因此，在选择机器学习模型时，数据科学家开始将可解释性视为第一要务。
软件开发是一项团队运动
技术雷达诞生之初，我们就提醒不要使用那些会分隔开发团队、阻碍反馈及协作的工具和技术。通常，当新的专业人才参与项目后，为避免陷入“常规”开发的混乱局面，从业者、供应商和工具会要求某一些开发工作必须在隔离的环境中完成。我们反对这种观念，也在不断寻求新的方法使软件开发重回团队协作。在构建诸如软件之类的复杂工程时，反馈是至关重要的。随着项目不断提升对专业人才的需求，我们努力让他们融入常规的团队协作和反馈互动中。我们特别不提倡“10倍工程师”的理念，更喜欢专注于创建和赋能“10倍团队”。我们已经看到这在如何将设计、数据科学和安全融入跨功能团队，并获得成熟的自动化支持方面发挥了作用。下个阶段应致力于引入更多治理方法和合规行为。
相关洞见
贡献者
Vol.21
技术雷达由ThoughtWorks技术顾问委员会编制撰写，成员包括：
下载
点击下载最新一期和过往版本