五. 画蛇添足
系统的架构师都会有一种诱惑，设计一个完美的系统，这个系统会覆盖到需求的方方面面，并且这个系统要没有任何的bug。
但是呢，这个诱惑通常会在需求的变更，进度的压力，团队的其他成员无法准确理解，或者甚至是新手程序员经验不足的各种情况下，逐渐陷入一个没完没了的焦油坑中。所以架构师经常要在范围，质量，进度中作出妥协。
在前面《贵族专制，民主政治》这一章节中，提到了架构师和实现人员，也就是程序员之间的关系。但是具体他们之间是怎么样的一种配合关系呢？又是怎么样去在项目中实操呢？又怎么样的去协调系统架构师完美的设计和过高的开发成本？
书中的《画蛇添足》章节中提到：
- 牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而不能支配；
- 时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法;
- 对上述的建议保持低调和不公开;
- 准备放弃坚持所作的改进建议。
一般开发人员会反对体系结构上的修改建议。通常他是对的——当实现产品时，某些次要特性的修改会造成意料不到的成本开销。
也就是说，架构师和程序员之间的责任界面是代码（这里提的是两个角色，而不是具体的人员，当前的实际操作过程中，架构师往往也是核心代码的编写者）。而架构师需要将这种创造性放手给程序员，这样能充分调动团队的积极性和参与人员的成就感，对整个团队的共同前进是非常有益的。
书中我自己理解的一个就是完美性和成本的协调：
在开发第一个系统时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以会谨慎、仔细地工作。在设计第一个项目时，他会面对不断产生的装饰和润色功能。这些功能都被搁置在一边，作为“下一个”项目的内容。第一个项目迟早会结束，而此时的结构师，对这类系统充满了十足的信心，其精通这一级别系统，并且时刻准备开发第二个系统。
第二个系统是设计师们所设计的最危险的系统。而当他着手第三个或第四个系统时，先前的经验会相互验证，得到对此类系统通用特性的判断，而且系统之间的差异会帮助他识别出经验中不够通用的部分。
实际上，现在在产品研发里经常提到的“mvp”概念，也就是minimum viable product—最简可实现产品。第一个产品或者第一版的产品通常是会被设计成精简的。而陷阱往往出现在第二个产品，在第一版产品获得成功之后，控制不住完美系统或者是市场的诱惑，高估开发能力或者是低估开发成本，提出大量可有可无，性价比较低的功能需求，从而在第二版系统上折戟。在后续的版本中吸取经验反而会进行准确的评估。书中提到了对结构师的要求—自律，或者说对工作量谨慎的评估。
六. 贯彻执行
在確定好团队结构，团队之间责任界面之后，剩下的工作就是执行了。书中在这一章里主要提到以下几个方面：
1. 文档化的规格说明—手册
文档的重要性不需要过多强调，书中描述的已经非常清楚了。
手册或者书面规格说明，是一个非常必要的工具，仅有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一细节；同样地，它也是结构师主要的工作产物。
随着用户和实现人员反馈的增加，规格说明中难以使用和难以构建实现的地方不断被指出，规格说明也不断地被重复准备和修改。然而对实现人员而言，修改的阶段化是很重要的—在进度表上应该有带日期的版本信息。
手册不仅要描述包括所有界面在内的用户可见的一切，还要避免描述用户看不见的事物。后者是编程实现人员的工作范畴，而其设计和创造是不应该被限制的。体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实现过程。
规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义,所以每条说明必须重复所有的基本要素,所有文字都要相互一致。这往往使手册读起来枯燥乏味,但是精确比生动更加重要。
上面提到的是面向用户的，实际上需要将团队的下游团队也考虑成用户，也就是团队内部的文档也必须满足上述要求。
2. 形式化定义：实际上，对这一点有较深的理解，我们的自然语言往往存在着一些歧义，特别又是以灵活见长的中文，在不同的语言环境中可以有这不一样的含义。这里原没有一些形式化定义的严谨，比如公式之类。不过往往很多需求不太可能完全使用公式或者严谨的形式化定义。个人觉得一种折中的方式，是对自然语言在团队内做内部的统一，也就是术语库。保证团队内部对关键的术语和概念无歧义。
3. 直接整合：实际上我理解就是统一规划的全局变量，接口以及代码风格。
4. 会议：会议是必要的。一般来说，技术人员往往对会议比较排斥，认为是浪费时间。实际上是项目经理或者管理层必须严格的控制会议数量，会议范围和时长。做到高效的会议。
- 晨会，一般采用站立晨会，非常有必要，可以在一个课题小组之间召开，时长控制在10-15分钟。
- 技术讨论会，有必要，提升团队能力和成员的团队感。
- 预计超过1个小时以上的会议，必须提前做好工作，将会议内容和材料提前知会参会人员，并督促参会人员熟知（督促是有必要的，程序员往往专注于代码而忽略邮件）
- 会议纪要，不要使得会议没有结论，没有结论和记录的会议是低效的。