拜读完brooks的《设计原本》后颇有感触。这个天才设计师用简单的200多页纸浓缩了软件设计中的种种问题，并给出了行之有效的建议，可谓是精彩绝伦。读完以后有茅塞顿开之感，要点总结如下：
1、设计需要过程模型来指导设计进程，现在看到最符合实际的过程模型是Boehm的螺旋模型，但brooks认为还有很大改进空间。
2、需求永远和合同有密切关系，而需求的变化又和合同本身发生了割裂。brooks建议了一种合同模型，这种模型将设计和实现分成两个合同分别签署。
3、无论是本地协作还是远程协作，最重要也是最需要解决的问题是各团队对架构本身的一致理解，即架构的概念完整性。brooks坚信面对面交流是最好的协作方式，无论用什么高级工具（邮件、即时通信等）效果都很差，除非双方已经合作多年，才不会出现偏差。
4、brooks认为软件设计，不仅需要理性主义，即充分的思考和理论的推导，更要证实主义，即要将设计尽快转化为可用原型来证实设计的正确性。（我在这几年也几乎被变成了一个证实主义者，呵呵）
5、千万不要去猜测用户的行为，因为设计师不是用户，一定要与客户交流，确保清楚用户的真正行为，而不是靠经验去假设和猜测。
6、要准确识别什么是核心资源？内存？CPU TICK？每个部件只能耗多少瓦？这些资源需要严格控制，确保系统的高效。
7、约束，是明确设计的朋友，像是画家需要知道画布大小。室内设计师需要知道房间大小一样。明确的约束可以带来更好的设计，到需要注意的是约束会随着时间变化，比如，内存已经不再是一个重要的约束。
8、设计中的美学，与风格相关，看看iphone和ios系统的设计就清楚了。
9、过去的成功的方法，现在不一定也成功，brooks认为这来自于设计师的自负。并举例说明了JCL语言在以往系统中的成功，但在System360系统中的彻底失败。
10、在大规模系统，专业学习时间长，分工更细的情况下，需求、设计、实现的分离，导致实现与设计不一致的问题非常突出，为了解决该问题，brooks提出了4种补救办法。这各种办法总结在我的（需求，设计，实现分离的问题——源自《设计原本》）中有总结。
11、设计决策，变更需要有明确的记录或日志，这是为了设计师从历史学习更多东西，避免无知的低级错误。而这个记录几乎不能很好的被保存，市面上有很多工具，都很有诱惑力，但公开的工具大都效果不好。
12、伟大的设计来自于伟大的设计师，而非伟大的设计过程。
13、繁杂的过程和琐碎的管理工作只能培养出优秀的设计师，而非伟大的设计师。要有意识的培养他们，甚至于书本知识也不算浪费。防止他们分心，并在不断的设计草图上，批判、修改、再批判、再修改中成长。
14、无论是设计阶段还是实现阶段，仔细的检查核实非常重要，就算是顶尖的设计师也会犯错误。
15、设计中一定要考虑后期如何维护，因为在交付使用后会经常维护。
16、brooks坚信在设计上多花时间不会提高这几个产品的成本。
17、与用户大量交谈，向他们现实原型，再次检查各人员工作，确保这些理解是正确的。
18、将设计工作量投入到更重要的地方，比如，厨房和起居室呆的时间更多，那么就需要投入更多时间去设计这两个地方。
19、仿真环境与仿真模型比起来效果更加突出，在虚拟环境上执行大量用例，会更好的验证设计。
20、市场预测在已有产品上才有效，对于新产品，设计师应今早让市场人员理解新产品的概念。
21、联合设计的问题。何方利益的界定能组成组织结构的快速达成共识。需要制定一个仲裁方案保障各方利益。设立各方各团体代表，保障各方利益。定期组织会议解决各方冲突。会议议题必须在下面评审通过再上会，避免无效会议。
