《代码大全》摘抄

《代码大全》摘抄（后续更新）

1. 文字写作这一隐喻暗示着软件开发过程是一种代价昂贵的试错过程，而非仔细规划和设计。
2. 进行增量式开发时，我们先做出软件系统的一个尽可能简单，但能运行的版本。它不必接受真实的输入，也无需对数据进行真正的处理，更不用产生真实的输出，它仅仅需要构成一个足够强大的骨架，支撑起来未来将要开发的真实系统。
3. 有时候用户在一开始并不完全确定自己想要的是什么，因此值得花费比理想情况下更多的力气，找出他们真正想要的同喜。但至少比“先做出一个错误的东西出来，然后扔掉，并从头来过”的成本低廉。
4. 预先详细说明100%的需求和设计时不切实际的，不过对绝大多数项目来说“尽早把哪些是最关键的需求要素和架构确定下来”是很有价值的。
5. 一条很有用的经验规则是，计划好预先对大约80%的需求做出详细说明。并给“稍后进行详细说明的额外需求”分配一定时间。然后在项目开发过程中，实施系统化的变更控制措施-只接受最优价值的新需求。另一种替代方案是，预先只对最重要的20%的需求做出详细说明，并且计划以小幅增量开发软件的剩余部分，随着项目的进行，对额外的需求和设计做出详细说明。
6. 采用上述不同的开发方法，有以下几点指标：一.需求是否稳定。二.设计是否简单。三.开发人员是否足够熟悉该领域。四.项目失败风险。五.“长期可预测性”是否重要。六.后期修改代码代价。
7. 问题定义在需求分析工作之前，而需求分析是对所定义的问题的深入调查。
8. 重视需求有助于减少开始编程开发之后的系统变更情况。
9. 在编写代码之前，客户无法可靠的描述他们想要什么，问题并不在于客户是低级生物，就如同你做这个项目的时间越长，对这个项目的理解越深一样，用于参与项目时间越长，对项目理解也就越深入。
10. 架构的质量决定了系统的“概念完整性”。后者鸡儿决定了系统的最终质量。一个经过慎重考虑的架构为“从顶层到底层维护系统的概念完整性”提供了必备的结构和体系，为程序员提供指引。
11. 在软件中，链条的强度不是取决于最薄弱的一环，而是等于所有薄弱环节的乘积，架构应该清楚地指出程序员应该“为了谨慎起见宁可进行过度工程（OverEngineering）”，还是应该做出最简单的能工作的东西。后续为我的补充：我们在做交易系统，涉及到大量的资金流动，应该严格按照过度工程来做，每个环节应该对上个环节采取白名单的保守策略，这样才能减少系统异常来的亏损问题。
12. 在软件开发中，设计中的问题往往通过解决或者部分解决才能被明确。