初探架构之美

中国科学技术大学软件学院 王松 原创作品版权所有转载请注明出处

本科时就听说过《架构之美》这本书，但一直觉得会很深奥而没敢去看。这次课外阅读书籍中再次出现这本书，于是下定决心拜读一下这本著作。

敲了几年代码，总觉得代码比较实际，架构比较空洞。“虚幻”的架构往往让人摸不着头脑，因为架构难以落在纸上，人们谈起架构时又总是以一种只可意会不可言传的姿态。美丽的架构无法定义，可它却一定是自然的、简单的、可复用的、人文的，甚至是外行人也可以细细品味其思想的。

什么是架构？我们将“架构”作为一个名词，它意味着一组工件，包括像蓝图和构建规范这样的文档。这些工件描述了要构建的对象。Jim Waldo和其他人曾指出，没有什么过程可以保证你学了以后就能创造出好的架构，更不必说美的架构了，所以我们将更关注工件，而非过程。从这些能看出，虽然我们无法学习创造美的架构的步骤，但是我们可以通过学习判断怎样的架构是美的来帮助我们不断发现架构中的缺陷。那些被我们所津津乐道的架构，都是大师们在日常工作里经历了大量的错误、重复的尝试、无数的代码、长久的考验所积淀下来的。如果我们也能找出架构中的不足不断改进，总有一天会创造出美的架构。

架构之美体现了关注点的分离与结合。在软件设计中，设计师需要考虑多方面的关注点。漂亮的设计让这些关注点尽可能分离，然后以最简单的机制结合在一起，从而得到高内聚、低耦合的系统。而这些关注点往往都包含以下几点：

功能性

产品向它的用户提供哪些功能？

可变性

软件将来可能需要哪些改变？哪些改变不太可能发生，不需要特别容易进行这些改变？

性能

产品将达到怎样的性能？

容量

多少用户将并发使用该系统？该系统将为用户保存多少数据？

生态系统

在部署的生态环境中，该系统将与其他系统进行哪些交互？

模块化

如何将编写软件的任务分解为工作指派（模块），特别是这些模块可以独立地开发，并能够准确而容易地满足彼此的需要？

可构建性

如何将软件构建为一组组件，并能够独立实现和验证这些组件？哪些组件应该复用其他的产品，哪些应该从外部供应商处获得？

产品化

如果产品将以几种变体的形式存在，如何开发一个产品线，并利用这些变体的共性？产品线中的产品以怎样的步骤开发？在创建一条软件产品线时，要进行哪些投资？开发产品线中不同变体的选择，预期会得到怎样的回报？特别是，是否可能先开发最小的有用产品，然后再添加（扩展）组件，在不改变以前编写的代码的情况下，开发产品线的其他成员？

安全性

产品是否需要用户认证，或者必须限制对数据的访问？数据的安全性如何得到保证？如何抵挡“拒绝服务”攻击或其他攻击？

好的架构必须满足系统的利益相关人的功能和质量关注点。那么超过足够好的架构是怎样的呢？我们要从这些好的结构中进一步筛选，就要设立更高的门槛。首先，我们应该关注架构的实用性，它必须每天都被许多人使用。但是，在使用它之前它应该先构建，所以我们应该关注该架构的可构建性。接下来，我们想寻找那些展示了持久性的架构，也就是说，那些经过了时间考验的架构。最后，我们还想寻找这样一些架构，它们的特征让使用、构建、测试这些架构的开发人员和测试人员，以及由它而形成的系统的用户感到由衷的高兴。

作者通过“混乱大都市”和“设计之城”两个例子向我们展示了架构如何对软件项目产生深远的影响。架构几乎会影响所有与之相关的人和事。从这两个例子，我们可以看出好的架构是很多因素的结果，包括以下方面（但不限于此）：

确实进行有意为之的前端设计。（许多项目甚至还没开始，就因为这一点而失败了。）
设计者的素质和经验。（以前犯过一些错误是有帮助的，这能在下一次为你指出正确方向！）
在开发过程中，保持清晰的设计观点。
授权团队负责软件的整体设计，而团队也承担起这一责任。
不要害怕改变设计：没有什么是一成不变的。
让合适的人加入到团队中，包括设计者、程序员和经理，确保开发团队的规模合适。确保他们具有健康的工作关系，因为这些关系将不可避免地影响代码的结构。
在合适的时候做出设计决定，当你知道所有必要信息时再做出决定。延迟那些暂时不能做出的决定。
好的项目管理，以及合适的最后期限。

最后作者通过企业级应用架构、系统架构、最终用户应用架构以及语言与架构这些方面举例说明了经典架构的美丽之处。

我们总是认为不良的架构只是会影响到软件的代码，但是读完这本书后，我发现，不良的架构的影响不仅限于代码，它会进一步影响到人、团队、过程和时间表。开发团队的成员，尤其是新成员会被系统的复杂性惊吓到，项目会给他们带来巨大的压力，尤其是规划新的功能会导致极大的恐惧。由于系统的复杂性，所以即使是最简单的变更都需要花费大量的实践，从而导致管理项目的开发周期显得极其困难。

记得之前和宿舍的人一起讨论工程实践的概要设计时，他问了我几个架构设计的问题，但当我问到他们的需求是什么时，他却没法给我明确的答复。我无法想象他们在没有抓准需求的情况下做出的概要设计会是什么样的。正如此书中所讲的，“重要的是要在开始设计系统之前知道你打算设计什么。如果你不知道它是什么，也不知道它将做什么，暂时不要开始设计它。只设计你知道需求的东西。”

“混乱大都市”之所以混乱的一个重要原因：在项目开始之初，团队并不知道要构建的是什么。在规划“大都市”的早期阶段，有太多的架构师。面对糊涂的需求，他们都拿着一块拼不起来的拼图，试图独自工作。他们在工作时没有考虑到整个项目，所以当他们试图将这些拼图拼在一起时，就拼不起来了。没有时间进一步思考架构，软件设计的各个部分有一些重叠，于是开始了“大都市”的城市规划灾难。

很多同学不理解工程实践开题时为什么要做那么细致的需求调研，还要对系统做出整体的概要设计。看完这本书，我开始明白这么做的意图。如果我们在需求不清，整体设计不明的情况下就开始了项目的开发，最后我们的软件肯定会成为另一个“混乱大都市”，甚至仅仅只能称作“凌乱小房间”。

对于我们平时遇到的这些小项目而言，我们需要决定的关注点可能没有那些架构名人堂中的经典之作那么多。但我们同样应该在项目的早期就决定一些基本的关注点，它能确保代码能够容易而一致地增长，这些决定包括：顶层文件结构，我们如何对事物命名，“内部”展示的风格，共用的编码惯例，选择单元测试框架，支持基础设施（例如版本控制、适合的构建系统的持续集成）。

当作出了设计决定后，就要进行品质控制过程。常见的品质控制手段包括：结对编程，对没有结对编程的工作进行代码/设计复审，对每一段代码进行单元测试。一提到测试，估计很多程序员就开始烦恼了。大部分都很讨厌测试环节，但是测试却又非常重要。一组好的自动化测试可以让我们在进行架构变更时风险最小。编写单元测试确保了每个代码模块的内聚性，也确保了与系统其他部分之间的松耦合。单元测试迫使我们仔细考虑每个单元的接口，确保该单元的API是有意义的，内部是一致的。

读完整本书后感觉架构不再是那么神秘了，而是与每一位程序员都息息相关的，只要不断从所经历的项目的架构中吸取经验，我们也能成为架构大师。在读这本书期间，我担任着工程实践项目的组长，架构的设计也是我的任务之一。利用书中所学，我也开始一步步规划起属于我的“设计之城”。纸上得来终觉浅，只有在实践中慢慢摸索，才能体会到架构的美丽之处。