总评：

《人月神话》作者Brooks写的书《设计原本》，觉得做架构师或者做设计工作的同学们都看看，真的很好，里面将设计提升为方法学、哲学的高度，而不是单纯讲案例、讲准则。当然个人认为有些内容是和设计本身没有太大的关联，可能和作者的工作内容有关而呈现出来的，但绝对值得一读：

 

印象比较深刻的论断：

 

。关于完整性：同一个系统的架构实际上不应该有多个架构师同时设计（每个人一部分），至少要有一个架构师负责统筹，才能保证完整性。比如头脑风暴的方式实际上并不合适运用在设计方案的选择上；

 

。Raymond的集市模型：即当前Linux社区采用的模式，每个人都可以对系统进行贡献，贡献内容的质量取决于其他人对该产品使用的频繁程度，在某些条件下可以工作的很好。

 

。关于相互协作：当面沟通永远是最好的方式、视频会议次之、电话沟通再次之、邮件|文档共享沟通效果最差。之前在一家日资公司工作的时候这种感觉非常明显。

 

。理性主义还是经验主义：理性主义者倾向于采用严格的方式方法进行软件设计，极端情况下设计出来的东西本身就是没有缺陷的；经验主义者通过测试的手段进行正确性保证，假定设计出来的东西本身就是有缺陷的。 作者是一个经验主义者，但是我本人认为一个真正驱动行业前进的动力则是理性主义做法，尽管目前来看采用理性主义的方式进行软件设计困难重重。

 

。基于约束的设计：没有约束就没有设计，这个是我个人的观点。但是更准确的把握约束的本质却是设计者需要下功夫做的（之前我做过一个设计决策，和开发人员讨论，其中有一个开发人员就提出，这个设计决策会影响其中两个系统的通讯性能（几十毫秒 --> 几百毫秒），所以不能采纳。 我就问他，为什么不能采纳呢，他说因为之前的需求里面说明的。然后我就问他，变成几百毫秒之后对用户、对系统压力有什么影响呢，他说没有（这个系统调用次数比较少），后来沟通这下，把这个约束去掉了）

 

。基于范本的设计：我一直想找一本关于架构设计的、较为具体化的设计模式的书籍，但是没有找到，但是觉得确实我们需要这个东西。比如如果数据库的访问量很高，应该如何做设计（加缓存、数据库读写分离、分库、分表等手段该如何做选择等）。本书也不是设计范本，而是阐述了基于范本的设计师比较理智的

 

。软件过程对设计的影响：卓越的设计来源于卓越的人才，而不是卓越的过程。在有些情况下，卓越的过程是影响人才发挥的。 苹果公司的一句话是，我们的过程成熟度永远都是1（CMMI5级成熟度，最低级为1），但是并不妨碍我们生产出伟大的产品。 一个例子是IBM位于德国的一个实验室，有很多天才的设计师，在其他方面都很成功，唯独面对IBM一些项目则比较失败。后来发现原因是这些项目对过程要求比较苛刻，面对这些规则，这些人畏手畏脚，限制了他们的发挥。

       我本人的观点是：越是天才的设计师、程序员，给他们的过程约束应该越是轻量级。轻量级过程适合天才，重量级过程适合土人