《人月神话》打动我的那些章节----论几十年前的软件工程开发理念在当代还有多少理论行得通（二）

在经过上篇的总结之后，我们继续走在与前人思想交流的道路上。

第四章 贵族专制，民主政治和系统设计---论概念设计的完整性有多么重要

我们需不需要创造一个结构设计师的贵族专制，和一群创造性天赋和构思被压制的平民编程实现人员的编程王朝来获得概念的完整性。

并且如何避免结构设计师制定出无法实现或是代价高昂的技术规格说明，使大家陷入困境？

如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确的理解，并整合到产品中？

获得概念的完整性，首先要知道软件的设计应该增加计算机的易用性，只有花费在记住纷繁复杂的软件用法的时间少于花费在学习，记忆搜索用户手册的时间时，易用性才是真正的提高。为了达到易用性的目标，需要我们设计上的一致性和概念上的完整性。

概念上的完整性设计必须由一个或几个有默契的人来实现，然而现实的进度压力要求添加更多的人手，对于大型项目来说将设计方法，体系结构方面的工作与具体实现相分离是一种很有效的做法。因此，架构师如同建筑结构师一样，是用户的代言人，需要用专业知识为用户带来真正的利益而不是维护销售和制作人员鼓吹的利益。

因此项目是需要这样的相对专制的，但是并不需要压制实现人员，他们的才华同样对性价比发挥着重要的作用。有了严格规则的体系下的创造性往往高于那些没有规矩的体系。

然而对于由小型团队来编写编程系统的外部技术说明的情况，具体编程人员提出了三个反对意见：一说明的功能过于繁多，对实际成本考虑较少。二结构师获得了所有创造发明的快乐，剥夺了实现人员的创造力。三当体系结构的队伍缓慢工作时，很多实现人员只能空闲的等待着。

对于这些问题，只有第一个是缺失危险的，将在下一个章中进行讨论。第二个只是误解，第三个可以通过在说明完成的时候才雇佣编程实现人员。并且，体系结构，设计实现和物理实现在实际情况中往往可以同时开始和并发地进行。

第五章画蛇添足---架构师的自我修养

如果将制定功能规格说明的责任从开发快速，成本低廉的产品的责任中分离出来，那么有什么养的准则和机制来约束架构师的创造性热情呢？

那么架构师的交互准则和机制就要发挥作用了。架构师需要牢记开发人员是实现主体，所以架构师只能是建议而不能支配。时刻准备为所指定的说明建议一种实现的方法，同样准备接受其他的任何能达到目标的方法。对上述建议保持低调和不公开。

其次自律--了解到第二个系统所带来的后果。第一个系统往往架构师因为对正在进行的任务不够了解而谨慎工作，但是第二个系统，会被加入大量的第一个系统中搁置的装饰和润色功能，这时候会造成系统的过分设计，让系统陷入过分臃肿，这时候需要架构师的自律精神来不断的反省自我。

第六章 贯彻执行---手册，定义以及标准和其他

在这一章阐述了软件系统的约束缰绳，包括一份风格清晰完整和准确的规格说明文档，包含用户可见和所有不可见的功能的用户手册。以及牢记定义唯一核心的标准，其他标准只能用于辅助说明，以精确定义问题。

在解决手段上提倡周例会和年度大会的相结合，不仅仅可以解决决策上的问题而且使每个人对复杂约束和决策之间的相互关系有了更透彻的理解。

记录开发日志，好记性不如烂笔头在每个行业都是实用的建议。

设立测试小组。这也是发现未贯彻执行，设计决策没有正确理解或实现的重要手段，因此需要尽早的着手。