我们不能只是希望消除或“修复”复杂性的原因是，每一个解决方案——无论是技术还是方法——都会以某种方式重新分配复杂性。解决方案重组问题。当微服务(一种软件架构方法，其中应用程序或系统由许多较小的部分组成)出现时，它们似乎解决了单体架构(其中应用程序是一个单一的联锁系统)带来的许多维护和开发挑战。然而，在这样做的过程中，微服务对工程团队提出了新的要求;它们需要在实践和过程方面更加成熟。这就是为什么我们在2018年版的技术雷达中提醒人们不要“羡慕微服务”的原因之一，CTO Rebecca Parsons写道，微服务永远不会被推荐采用技术雷达，因为“并非所有组织都准备好了微服务”。我们注意到，有一种趋势是采用微服务，只是因为它很流行。
这并不意味着解决方案很差或有缺陷。更重要的是，我们需要认识到解决方案是一个权衡。在Thoughtworks，当人们问及某种技术或方法的价值时，我们喜欢说“视情况而定”。它是关于它如何适应你的组织的需求，当然，还有你管理它的特殊需求的能力。这是技术中本质复杂性的一个例子——它是无法去除的东西，无论你多么想达到一种你觉得舒适的简单程度，它都会持续存在。
就微服务而言，我们注意到越来越多的人急于采用这种特殊的体系结构方法。我们的一些同事甚至建议用“单体复兴者”这个词来描述那些从微服务转向单体软件架构的人。虽然软件世界不太可能完全回归到单体架构，但是像Spring模块化这样的框架——一个帮助开发人员构建代码的框架，在需要的时候可以更容易地将单体架构分解成更小的微服务——表明从业者正在越来越敏锐地意识到管理构建和维护软件的不同方法之间的权衡。
因为技术解决方案有重新组织复杂性的习惯，我们需要仔细关注如何管理这种复杂性。如果做不到这一点，可能会严重影响工程团队的生产力和效率。在Thoughtworks，我们有许多用于管理复杂性的概念和方法。例如，合理的默认值是一个项目或一项工作的起点。它们不是我们需要简单地当作规则来接受的东西，而是我们共同认为对大多数项目有效的实践和工具。它们为个人和团队提供了一个基准，以判断哪些地方可以做得不同。
合理默认的好处之一是，它们可以保护你免受新奇和炒作的诱惑。尽管一项新技术可能很有趣或令人兴奋，但明智的默认设置可以将您固定在对您重要的事情上。这并不是说像生成式人工智能这样的新技术不应该被热情和兴奋地对待——我们的一些团队一直在试验这些工具，并看到了令人印象深刻的结果——而是说，采用新工具需要以一种与你的工作方式和你想要实现的目标适当整合的方式来完成。事实上，有很多方法可以实现GenAI，从ChatGPT这样的知名工具到自托管llm。有效地使用GenAI不仅是关于技术专业知识，也是关于了解为您和您的团队实现的正确方法的问题。
有趣的是，能够帮助我们管理复杂性的工具并不一定是新的。在Technology Radar的最新版本中出现的一件事是基于风险的故障建模，这是一个用于了解影响、可能性和检测系统各种故障方式的能力的过程。这源于失效模式和影响分析(FMEA)，这是一种可以追溯到第二次世界大战后的实践，用于航空航天等领域的复杂工程项目。这表明有些挑战是持续存在的;虽然总会出现新的解决方案来对抗它们，但我们也应该乐于回顾过去的工具和技术。
麦肯锡关于开发团队的生产力可以被成功测量的观点在软件工程领域引起了轰动。虽然拥有正确的度量标准当然很重要，但是当涉及到复杂的系统和不断变化的解决方案时，在我们的思维中优先考虑生产力可能会导致比解决更多的问题。《科技雷达》(Technology Radar)发表了一篇文章，主题是“衡量生产力有多高效?”这凸显了在DX DevEx 360等工具的帮助下关注开发者体验的重要性。
以麦肯锡建议的方式关注生产力可能会导致我们错误地将编码视为软件工程的“真正”工作，而忽略了架构决策、测试、安全分析和性能监控等事情。这是有风险的——采用这种观点的组织将很难从他们的数字项目中看到切实的好处。这就是为什么当今软件的主要挑战是拥抱复杂性;不要把它视为不惜一切代价最小化的东西，而是需要在过程、实践和治理中深思熟虑的挑战。关键的问题是这个行业是否意识到了这一点。
本内容由Thoughtworks制作。这篇文章并非由《麻省理工科技评论》的编辑人员撰写。
