我在 2021 年最喜欢的六首新音乐

架构不必是独白；从集中少数人的思想和口中自上而下地传递。本文描述了另一种架构方式；作为一系列对话，由分散和授权的决策技术驱动，并由四种学习和调整机制支持：决策记录、咨询论坛、团队来源的原则和技术雷达

商业集成工具已经出现了二十多年，但是很少有关于何时以及如何使用它们的总体架构原则。在本文中，我认为“购买”决策机制导致我们夸大了此类工具的价值主张，通常导致强制使用某种集成工具而不是通用语言。我声称，此类工具在一个将集成主要视为连接系统的世界中蓬勃发展，但数字化组织已经将集成重新构想为主要是在数字功能前面放置干净的接口，强调功能而不是系统。最后，我列出了现代集成视图背后的一些关键原则，并声称最好使用通用语言来管理它们，将商业集成工具的主要价值主张重新定位于简化战术实施问题。

我的老同事 Dave Farley 一直在运营一个越来越受欢迎的关于软件开发的 YouTube 频道。这是很好的素材，与我自己的观点非常一致，毕竟他的经验对我的思想有很大影响。我们谈论了一系列关于软件工程当前角色的话题，特别关注了我目前支持的三个大型写作项目：数据网格、分布式系统模式和遗留系统替换模式。

在每个正常规模的团队中，将任何技术类别的备选方案限制为三个。这些是：当前合理的默认方案、我们正在试验的方案以及我们讨厌并希望退役的方案。

良好的技术设计决策非常依赖于上下文。定期为共同目标合作的团队能够定期沟通并快速协商变更。这些团队表现出强大的协作力，并且可以做出利用这种强大力量的技术和设计决策。当我们放大到一个更大的组织时，在独立工作且协作频率较低的团队和部门之间存在着越来越弱的力量。认识到这些强力和弱力的差异，我们就可以为每个级别做出更好的决策并提供更好的指导，从而使团队能够更快地行动。

在 DevOps 文化中集成必要的安全控制和审计功能以满足合规性要求可以利用 CI/CD 管道自动化，但在组织扩展时会带来独特的挑战。了解所选实施方案带来的二阶影响和意外后果是构建有效、安全和可扩展解决方案的关键。

提交/展示/询问是一种分支策略，它结合了拉取请求的功能和持续交付变更的能力。变更被分类为提交（无需审查即可合并到主线）、展示（打开拉取请求以供审查，但立即合并到主线）或询问（在合并之前打开拉取请求以供讨论）。

有趣的软件很少孤立存在。团队编写的软件通常必须与外部系统交互，这些系统可能是库、对外部服务的远程调用、与数据库的交互或与文件的交互。通常，外部系统会提供某种形式的 API，但从我们软件的角度来看，该 API 通常显得 awkward。API 可能会使用不同的类型，需要奇怪的参数，以在我们上下文中没有意义的方式组合字段。处理这样的 API 会导致在使用它时出现不和谐的错配。

网关充当了对抗这个“外国人”的单一入口点。我们系统中的任何代码都与网关的接口交互，该接口旨在以我们系统使用的术语工作。然后，网关将这个方便的 API 转换为“外国人”提供的 API。

演讲一直是我职业生涯的支柱之一。我在世界各地的软件活动中做过主题演讲。其中一些演讲在 YouTube 上的观看次数达数万甚至数十万。但我一直讨厌演讲，因此决定不再演讲。

关于测试组合应该是金字塔形还是更像蜂窝状存在争议。我对这场争论的第二个最大疑问是，由于人们不清楚单元测试和集成测试之间的区别，因此这场争论变得模糊不清。

开发者生产力平台越来越被认为是管理工程团队认知负荷和缩短新功能上市时间的一种方式。但是，组织需要培养一些基本能力，才能成功执行平台战略。平台团队需要将平台视为软件产品，需要与其用户对话，关注可靠的运营，以及健康的团队环境。

我如何使用 R 语言绘制柔和的意大利面条线图，包括分面。

通常需要访问某些属性的历史值。但有时，历史本身需要根据追溯更新进行修改。双时态历史将时间视为两个维度：实际历史记录了在信息完美传输的情况下历史应该是什么样子，而记录历史则记录了我们对历史的认识是如何变化的。

当人们想到代码审查时，他们通常会想到开发团队工作流程中的一个明确步骤。如今，在拉取请求上执行的集成前审查是最常见的代码审查机制，以至于许多人天真地认为不使用拉取请求就完全没有机会进行代码审查。这种狭隘的代码审查观点不仅忽略了许多明确的审查机制，更重要的是忽略了可能是最强大的代码审查技术——由整个团队完成的持续精炼。

拉取请求是由 GitHub 推广的一种机制，用于帮助合并工作，特别是在开源项目的上下文中。贡献者在中央存储库的 fork（克隆）中进行贡献。贡献完成后，他们会创建一个拉取请求，通知中央存储库的所有者他们的工作已准备好合并到主线中。工具支持并在接受请求之前鼓励对贡献进行代码审查。拉取请求已在软件开发中得到广泛使用，但批评者担心增加集成摩擦会阻碍持续集成。

技术正在变得越来越智能和强大。我经常观察到，随着这些技术的引入，组织的生产力非但没有提高，反而降低了。这是因为该技术增加了开发人员的复杂性和认知负担，降低了他们的效率。在本文（本系列文章的第一篇）中，我将介绍一个最大限度地提高开发人员效率的框架。通过研究，我确定了关键的开发人员反馈循环，包括开发人员每天执行 200 次的微反馈循环。应该对这些循环进行优化，使其对开发人员来说快速、简单且有效。我将研究一些组织如何利用这些反馈循环来提高整体效率和生产力。

最近的事件表明，我们需要采取严厉措施来打击正在破坏民主的谎言。