1.做个“建筑工程师”:打好编码基础

在开始动手构建软件之前，我们的前期准备其实就已经决定了我们项目的成败。这就像建筑中的打地基环节，如果前期计划没有做充分（就像地基没有打好），那么在建造过程中就会偏离方向。
所以在构建之前，阿道建议大家给自己戴上一顶“建筑工程师”的帽子，为项目制订计划，做好项目的前期准备。引用《代码大全》（CodeComplete）中的一句话：“如果你在项目的开始阶段强调质量，那么你就会计划、要求并设计一个高质量的产品。”这意味着我们要花时间去弄清楚我们要完成什么样的项目，但这样总比我们花费了人力、物力进行构建，结果要返工重来划算得多。

（1）定义问题

我们的项目是为了解决客户的什么问题呢?或者说为了解决客户的某个问题，我们要完成一个什么样的项目?其中的关键在于客户的问题是什么。所以在项目初期，我们可以邀请客户写下自己的问题，这个问题只是单纯的问题，不涉及任何解决方案或者过程。在客户提出问题之后，我们就可以对需求进行分析、澄清了。

（2）澄清需求

在需求分析和澄清阶段，要注意的是不能出现“一千个观众有一千个哈姆雷特”的现象，如果对需求的理解不一致，或者在与用户/客户沟通的阶段没有确认好需求，那么到了构建过程中可能会有严重的失误，造成损失。
沟通中存在问题而导致失败的情况不胜枚举。早前，某国的一颗火星气候探测器在尝试进入火星轨道的过程中失联，造成巨大损失。事故调查结果显示，导致这次损失的“根本原因"在于测量系统的不一致，该国相关单位测量时采用了英制单位，而一家承包商却使用的是公制单位。这类问题本应该是在沟通过程中提前发现并规避的。这也警示我们，在澄清需求的过程中要更加细致，使需求清晰、明确。

（3）提高架构质量

在构建过程中最不想看到的事情是需求变更，同样，架构变更也是如此。在前期准备中，我们也要注意架构设计中容易出现的问题，努力提高架构质量。

（4）制订项目计划

项目计划能够确认项目目标实现的可行性，并使项目按照一定的节奏进行。

2.确认设计：寻找软件架构之道

尽管我们可以做“建筑工程师”，但这和真正的建筑工程师还是有所区别的，其中最显著的差异是架构设计：建筑架构是趋于稳定的，而软件架构是不断变化的。
所以，什么是软件架构？2007年，国际标准化组织这样定义软件架构：系统的基础组织，包括它的组件、组件间的关系、环境以及管控系统设计和演进的原则。

（1）明确程序构造

首先，我们要对最终软件的构造有一个清晰的认知，如设定某一组协同的类共同实现交互功能、显示功能等。其次，我们应详细定义程序中主要的类，包括每个主要的类的交互方式与责任、如何组织成子系统等。

（2）提高性能

进行性能目标的定义以及优先级的排序，如系统对请求做出响应的时间（响应时间）、系统在单位时间处理请求的数量（吞吐量）、系统可以同时承载的正常使用系统功能的用户数量（并发用户数）等。架构设计能够提供性能预估数据来帮助我们更好地进行前期准备。

（3）保证安全性

架构设计的安全性是我们需要重点关注的问题，这包括但不限于用户认证的安全、权限及授权的安全、数据隐私的安全、信息传输的安全等。因为这些问题并不直接与系统和业务相关联，所以我们在做架构设计的时候往往容易忽视，但安全风险系数的上升无疑是系统的隐患，所以我们可以通过身份验证、日志记录、监控系统、隔离存储、访问控制等来保证架构设计的安全性。

（4）提高可维护性

要提高系统架构的可维护性，就要在需求分析的阶段考虑到能够影响系统可维护性的部分，从而为将来可能进行修改的部分提前做好准备。

（5）提高可测试性

可测试性差会大大增加测试成本。那么我们该如何提高系统的可测试性呢?基本原则是需要测试工程师提前介入。我们需要在设计之前就考虑到后续测试的操作成本，思考某个功能是不是可以与其他的界面分离，或者是否需要淡化两个子系统之间的依赖关系等。

（6）遵循ETC原则

分时操作系统先驱费尔南多·科尔巴托（Fernando Corbato）曾说过:“设计中的bug常常不易被发现;随着演化的进行，系统不断增加新的功能特性和用途，早期的设计假设渐渐被忘记，这时设计中的bug就会现身。”因此，架构设计要遵循ETC原则，也就是“Easier To Change”（易于变更）。架构师应该提前预测哪些地方可能会出现变化，从而做出足够灵活的架构来应对这些变化。

总之，软件架构是为了解决复杂性问题，帮助团队成员化繁为简，更好地实现软件交付。那么如何“化繁为简”？这就是我们要持续思考的问题。

来源：《程序员生存手册》

【每日一学 20261008】《程序员生存手册》——编码前的准备