软件架构：核心挑战

第 1 章. 没有 "最佳做法 "会怎样？

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

为什么像软件架构师这样的技术专家要在会议上发表演讲或著书立说？因为他们发现了俗称 "最佳实践 "的东西，，这个词被用滥了，以至于说这个词的人越来越受到反感。不管用什么术语，技术专家都会写书，因为他们找到了解决一般问题的新方法，并希望将其传播给更多人。

但是，对于那些没有好的解决方案的大量问题，该怎么办呢？软件架构中存在着许多问题，这些问题没有通用的好解决方案，而是在（几乎）同样混乱的问题中进行权衡后得出的一套混乱的解决方案。

软件开发人员在网上搜索解决当前问题的方法时掌握了出色的技能。例如，如果他们需要弄清楚如何在自己的环境中配置某个工具，专业人员就会使用 Google 找到答案。

但对于建筑师来说，情况并非如此。

对于架构师来说，许多问题都会带来独特的挑战，因为它们与组织的具体环境和情况相混淆--有多大可能有人遇到过这种情况，并将其写入博客或发布在 Stack Overflow 上？

架构师们可能会想，与框架、应用程序接口等技术主题相比，为什么有关架构的书籍如此之少。架构师很少遇到常见问题，但却经常在新情况下为决策而苦恼。对于架构师来说，每个问题都是一个 Snowflake。在许多情况下，问题不仅在特定组织内是新颖的，而且在全世界都是新颖的。没有任何书籍或会议可以解决这些问题！

建筑师不应该一味地寻找解决问题的灵丹妙药，因为现在这种灵丹妙药和弗雷德-布鲁克斯在 1986 年创造这个词时一样稀少：

无论是技术还是管理技巧，没有任何一项发展本身能保证在十年内将生产率、可靠性和简便性提高哪怕一个数量级（十倍）。

弗雷德-布鲁克斯，选自 "没有银弹"

因为几乎每一个问题都会带来新的挑战，所以建筑师的真正工作就在于他们能够客观地判断和评估一个重要决策的两方面权衡，从而尽可能好地解决这个问题。作者并不谈论 "最佳解决方案"（无论是在本书中还是在现实世界中），因为 "最佳 "意味着建筑师已经设法将设计中所有可能的竞争因素最大化。取而代之的是，我们语带调侃的建议如下：

提示

不要试图在软件架构中找到最好的设计；相反，要努力实现最差的权衡组合。

通常情况下，建筑师所能创造的最佳设计是最不糟糕的权衡集合--没有任何一种建筑特性能像单独存在时那样出类拔萃，但所有相互竞争的建筑特性的平衡却能促进项目的成功。

这就引出了一个问题："建筑师如何才能找到最差的权衡组合（并有效地记录下来）？本书主要讲述决策制定，使建筑师在面对新情况时能够做出更好的决策。

为什么是 "困难部分"？

为什么我们把这本书叫做《软件架构：困难的部分？事实上， ，书名中的 "难 "有双重含义。首先，"难"意味着 "困难"，而架构师经常要面对一些前人从未面对过的棘手问题，这些问题涉及大量具有长期影响的技术决策，以及必须做出决策的人际和政治环境。

其次，"硬"意味着 "稳固"--就像硬件和软件的分离一样，"硬"的东西应该更少改变，因为它为 "软"的东西提供了基础。同样，建筑师也会讨论建筑和设计之间的区别，前者是结构性的，而后者更容易改变。因此，在本书中，我们讨论的是架构的基础部分。

软件架构的定义本身已经在从业者之间引起了许多无益的讨论。其中一个最受欢迎的调侃式定义是："软件架构是以后难以改变的东西"。这正是我们这本书的主题。

提供关于软件架构的永恒建议

软件开发生态系统不断发生着混乱的变化和发展。 几年前风靡一时的主题，要么已被生态系统所吸纳并消失，要么已被不同/更好的东西所取代。 ...