《代码大全》笔记
1.重要的研发成果产自于类比，其使用隐喻的方法称为“建模”。一个好的隐喻应该是简单的，而不同的模型可以看到不同的现象，提出不同的问题。软件开发一开始的隐喻是“写作”，但写作上原创性比较重要，但对于软件构建来说，专注于重用以往项目的一些设计思想、代码以及测试用例的开发更为重要。这表明软件开发与学习要站在巨人的肩膀上，也要多参考样例。“计划扔掉一个软件”不是一个好的建议，诀窍在于在成本最低的时候多试几次。
“培植系统”这一隐喻告诉我们“一次做一点事情。”，也就是增量技术，将成果一点点添加到整个系统当中。以增量方式进行设计、编译和测试都是目前已知的最强有力的软件开发概念。
增量式开发：先做出软件系统的一个尽可能简单、但是能运行的版本。不必接受真实的输入，无须对数据进行真正的处理。需要一个强大的架构。对于每一个基本功能，只需要类与之对应。
“建造”这一隐喻带给我们的：开发软件时需要大量使用高级语言所提供的程序库，比如一些容器类、科学计算函数、用户界面组件、数据库访问组件。自己编写那些能买到的现成的代码通常是没有意义的。为了让产品的各个部分无缝对接，拥有一致的外观和体验，可能要自己编写容器类或各种组件等等。
2.The plan is important.两种开发方法：序列式开发和迭代式开发。迭代式开发应用更广，但两者的前期准备工作都很重要。
3.“需求”详细描述了软件系统应该做什么，这是达成解决方案的第一步。要有一套明确的需求。这有助于使用户驾驭系统的功能，避免因“程序要做什么”带了的程序员之间的争论，有助于减少变成开发之后的系统变更情况。稳定的需求是软件开发的圣杯。但是需求的变更不可避免。
4.架构：架构的质量决定了系统的“概念完整性”。好的架构使得构建活动变得容易。构架应该包含多个视角。构架要全面但也要简洁。
程序组织中，系统架构首先要以概括的形式对有关系统做一个综述。这就需要系统组织结构，该组织结构要清晰而明确，比如说编写一个类，那么你就要对这个类有一个清晰的构思。
架构应该定义程序的主要构造块。各个构造块可能是单个类，也可能是由许多类组成的一个子系统。每个构造块共同实现一种高层功能，诸如用户交互、显示web页面、解释命令、封装业务规则、访问数据，等等。每个在需求中的功能特性都至少应该有一个构造块去覆盖它，如果两个或多个构造快生成实现同一项功能，那么它们就应该相互配合而不会冲突。应该明确定义各个构造块的责任，每个构造块应该负责某一个区域的事情，并且对其他构造块负责的区域知道得越少越好。要明确每个构造块的通信规则。
主要的类中，架构应该详细定义所用的主要的类。应该指出每个主要的类的责任，以及该类如何与其他类交互。
对于数据设计，架构应该描述所用到的主要文件和数据表的设计。数据通常只应该由一个子系统或一个类直接访问；或者通过访问器类和访问器子程序来访问数据。
在用户界面设计中，架构应该详细定义Web页面格式、GUI、命令行接口等主要元素。
对于资源管理，要有管理稀缺资源的计划。稀缺资源包括数据库连接、线程、句柄等等。
考虑安全性就要建立威胁模型。
在此性能主要指空间和时间预算。可伸缩性指系统增长以满足未来需求的能力。
在输入输出方面，架构详细定义读取策略是先做、后做、还是及时做。而且英爱描述在哪一层检测I/O错误：在字段、记录、流、或者文件的层次。
错误处理要有同一地处理错误的方案以达到用户界面统一。
5.设计是一项明确的活动，就是把需求分析和编码调试连在一起的活动。设计包含着不断被修改的过程。好的设计源于对一小批设计概念的理解。软件的首要技术使命是管理复杂度。作为软件开发人员，我们不应该试图在同一时间把整个程序装进大脑，而应该试着以某种方式去组织程序，以便能够在一个时刻可以专注于一个特定的部分。在软件架构的层次上，通过分解为多个子系统可以简单化问题，子系统间相互依赖越少越好。设计特征中，松散耦合意味着各部分关联度最小。可扩展性要求增强系统功能无须破坏底层结构。
设计要有层次性，一个层次中要进行模块化，模块与模块之间要限制通信，否则就会像是熵的增加，所以需要设计通信规则。原则是简化子系统之间的交互关系。最简单：调用不同子系统的子程序；稍复杂：包含另一个子系统中的类；最复杂：继承另一个子系统中的类。基本原则：设计应为无环图。常用的子系统：业务规则、用户界面、数据库访问、对系统的依赖性（主要就是接口吧）。
