最近项目开发比较密集，也遇到了一些方式的碰撞，这个时候再翻到《代码大全》，真是瞌睡时碰到枕头的感觉了。决定好好读一遍，记录一下。
xxiv: 软件构建是项目必须完成的阶段，它要为小型项目75%的错误负责，为大型和中型项目50%-75%的错误负责。——我们在项目的错误中，往往只看重设计的重要性，其实大部分错误都来自软件构建（即编程）本身。
P11：如何利用隐喻Metaphors（对软件的建模），将影响如何解决这个问题。
P28：程序员是软件食物链的最后一环。架构师吃掉需求，设计师吃掉架构，而程序员则消化设计。
P35：前期做好准备的项目，返工的成本是最低的。如果无法做到完全的准备，准备80%的需求，并为20%留够时间是一个可行的做法。
P46：架构应该确定软件采用的组织结构，并尽量列举其他可能的方案以及选择最终方案的理由。依据80/20原则，架构可以对确定决定项目80%功能的20%的类进行详细说明。
架构设计的常规内容(挑几个觉得重要的)：
- 程序组织 Program Orgnization
- 主要的类 Major Classes
- 数据设计 Data Design
- 业务规则 Business Rules
- 安全性 Security
- 性能 Performance
- 可伸缩性 Scalability
- 容错性
P51：在软件开发的链条中，链条的强度不是等于最薄弱的环节，而是所有薄弱环节的乘积。
P53：架构应该描述决策的动机，谨防“我们向来这么做”的说法。有个有趣的例子：Beth 想做丈夫 Adbul 家祖传的炖肉。Adbul 说，先撒上胡椒和盐，然后去头去尾，最后放在锅里盖上盖子炖就好了。Beth 就问了，“为什么要去头去尾呢？” Abdul 回答说，我不知道，我一直这么做，这要问我妈。他打电话回家一问，母亲也说不知道，她一直这么做，这个问题要问奶奶。母亲就打了个电话给奶奶，奶奶回答说，“我不知道你为什么要去头去尾，我这么做是因为我的锅太小了装不下”。
P62：选择合适的编程语言很重要。如果C的表达能力是1的话，C++和Java就是2.5。而perl和python却有 6。
P69：“深入一种语言编程”，而不只是“使用一种语言编程”。
P74：设计是一个险恶(Wicked Problem)的问题——只有解决或者部分解决才能被明确的问题。
P75：设计是一个了无章法的过程(Sloppy Process)，优、劣设计之间的差异往往非常微妙。
P77：软件的首要使命是管理复杂度。人们很少把技术原因归结为项目失败的主要因素，项目的失败多数由差强人意的需求、规划和管理导致的。但是，当项目确实由技术因素导致失败时，其原因通常就是失控的复杂度。
P79：拆分实际上是一种“关注点分离”。
高代价、低效率的设计源于三种根源：
- 用复杂的方法解决简单的问题。
- 用简单但错误的方法解决复杂的问题。
- 用不恰当的复杂方法解决复杂的问题。
P81：
高扇入(high fan-in)：指底层工具类被更多的类使用。
低扇出(low fan-out)：指一个类尽量少的依赖其他的类。
P84：程序调用、组合、继承的依赖程度从轻到中。继承是非常重度的耦合。
P90：