最初，这篇文章只是对这本书的评论，但随着我深入阅读，我意识到我想谈谈它所描述的方法如何适用于几个不同的群体（安全人员和开源项目），所以我继续写下去了。
那么，我是如何接触到这本书的呢？几个月前，我参加了一个会议（圣地亚哥开发者周），并决定参加其中一个会议，因为它看起来很有趣。演讲者是 Rebecca Parsons 博士，我非常喜欢她所讲的内容，以至于我订购了这本书，这本书的主题是她的演讲主题，以便在我几天后返回家时送到。
构建进化型架构：支持持续变革 这本书不是关于安全性的，而我是一名安全人员，但它将安全性视为其方法的一个应用，并且非常有说服力。作者（均为 ThoughtWorks 的员工）确定的核心问题，简化来说，虽然我们擅长为应用程序创建功能，但我们不太擅长创建和维护系统的更广泛属性。他们认为，现代开发实践的快速和不断变化的性质加剧了这个问题，在现代开发实践中，“企业架构师不能再依赖静态规划”。
他们提出的替代方案是考虑“适应度函数”，“您希望您的架构展示或朝着目标发展的目标”。至关重要的是，这些是架构或系统的属性，而不是功能或特定功能。应该创建测试来监控特定功能，但它们不会是您的标准单元测试，也不一定是“时间点”测试。相反，它们将衡量各种问题，可能是在一段时间内，以让您知道您的系统是否满足您正在衡量的特定适应度函数。书中有很多关于如何衡量这些适应度函数的讨论，但我希望看到更多。从我的角度来看，这是涵盖的最有价值的主题之一。
坦率地说，以上可能足以推荐这本书，但还有更多。他们强烈主张创建增量更改以满足您的需求（逐步更改，而不是重大更改）和“可进化架构”，鼓励您认识到
- 您可能无法在开始时满足所有适应度函数；
- 可能在某个时间点满足适应度函数的应用程序可能会停止在以后满足它们，原因有很多；
- 您的架构可能会随着时间的推移而变化；
- 您的需求，以及因此您赋予每个适应度函数的优先级，将随着时间的推移而变化；
- 即使您的适应度函数保持不变，您需要监控它们的方式也可能会发生变化。
在我看来，所有这些对于任何设计和构建系统的人来说都是极其有用的见解。将它们与架构思维相结合就更有价值了。
正如现代 O'Reilly 书籍的标准做法一样，书中贯穿始终都有示例，包括一家有特定需求的特定公司的虚构咨询之旅，引导您了解本书中的一些实践。有时，这感觉有点牵强，但这种机制通常很有帮助。有时，这本书似乎偏离了其核心方法（正如书名所示，它是架构方面的），转而通过伪代码进行解释，但这些支持了本书的有用方面之一，即给出了一些示例，说明哪些架构或多或少适合更理论部分中阐述的原则。一些读者可能更喜欢理论性的，另一些读者可能更喜欢基于示例的方法（我倾向于前者），但总的来说，这似乎是一个适当的平衡。在我看来，将这些与“架构耦合”的影响联系起来特别有帮助。
康威定律（“设计系统的组织……被约束产生与其组织沟通结构副本的设计。”）中的一些建议为本书提供了有用的基础，这让我思考我们如何根据这种视角来建模开源项目及其架构。还有（正如现在也很常见的）模式和反模式：我通常认为这些是任何关于设计和架构的书籍的有用组成部分。
为什么这本书适合安全人员？
从我作为安全系统架构师的角度来看，这本书最重要的意义在于它不是关于安全性的。书中提到了安全性，但并未被认为对本书至关重要，以至于值得在附录中提及。但关键是，系统的安全性（架构的体现）是适应度函数的完美示例。将此作为项目的起点将帮助您做两件事。
首先，您将避免专注于功能和特性，而着眼于大局。其次，您将考虑您真正需要系统中的安全性，以及这如何转化为诸如要采取的安全态势以及您将采取的措施以在整个生命周期中验证它等问题。
可能比这两点更重要的是，它将迫使您考虑安全性相对于其他适应度函数（例如，弹性或易用性）的优先级，以及相对优先级将如何以及应该随着时间的推移而变化。认识到我们不是生活在真空中，并且我们的优先级并不总是与项目中其他利益相关者的优先级相同，这始终是有用的。
为什么这本书适合开源人员？
通常情况下（出于完全可以理解和可以原谅的原因），开源项目的架构最初是自然增长的，在其生命周期的各个阶段需要进行重大修改和重构。当然，这并不是说这种情况不会发生在专有软件项目中，但开源项目重点和需求的有时频繁的变化，贡献者和贡献的潮起潮落，以及有时，嗯，旨在最终用户的文档级别降低可能意味着功能优先于我们可以认为是项目的核心愿景。纠正这种情况的一种方法是考虑项目的适当适应度函数，预先声明它们，并由社区定期审查，以确保它们是
- 仍然相关；
- 在这个项目阶段正确地确定了优先级；
- 实际上正在被满足。
如果以上任何一项受到质疑，那么现在是考虑社区更广泛审查以及项目重构或部分重新设计的好时机。
开源项目（非常正确地）有各种不同的使用模型和目标用户。可能对项目产生负面影响的偶然事件之一是，当它被确定为可能适合最初并非针对它的用例时。例如，旨在提高准确性而非性能的学术软件可能不适合企业研究，就像旨在最小化计算资源的面向家庭用户的项目可能不适合高可用性企业部署一样。明确这一点的方法之一是预先非常清楚地说明您期望您的项目满足的适应度函数，反之亦然，说明您在寻找选择项目时希望实现的适应度函数。很容易专注于功能和特性，而忽略系统的更多非功能性方面，而适应度函数使我们能够就如何平衡这些决策做出一些明智的选择。
本文最初发布在 Alice, Eve and Bob - 一个安全博客。
评论已关闭。