代码大全2阅读笔记
出版时间:2006年
<代码大全2>是一本完整的软件构建手册, 涵盖了软件构建过程中的所有细节. ## 第三章 * IBM和其他公司的研究发现, 平均水平的项目在开发过程中, 需求会有25%的变化. 在典型的项目中, 需求变更导致的返工占到返工总量的75%到85%. * 发现错误要尽可能接近引入错误的时间, 缺陷在软件食物链里面呆的时间越长, 它对食物链的后级造成的损害就越严重. * "问题定义"只定义了"问题是什么", 而**不涉及任何可能的解决方案**, 应该用客户语言来写, 从客户角度来描述问题. * 需求分析之前, 而需求分析是对所定义问题的深入调查, p42 核对表: 需求 ## 第四章 * 深入一种语言去编程的程序员首先决定他要表达的思想是什么, 然后决定如何使用特定语言提供的工具来表达这些思想. 而不是将自己的思想限制于"语言直接支持的那些控件" ## 第五章 * 项目的失败大多数是由差强人意的需求, 规划和管理导致的. 但是, 当项目确由技术因素导致失败时, 其原因通常就是失控的复杂度. 有关的软件变得极端复杂, 让人无法知道它就行是做什么的. 当没人知道对一处代码的改动会给其他代码带来什么影响时, 项目也就快停止进展了. 理想的设计特征 1\. 最小的复杂度: 简单而易于理解. 专注于程序的一小部分即可. 2\. 易于维护 3\. 松散耦合: 设计出相互关联尽可能少的类 4\. 可扩展性: ? 增强系统的功能而不需要改动底层结构 5\. 可重用性 6\. 高扇入: 让大量的类使用某个给定的类 7\. 低扇出: 让一个类少量或适中的使用其他类 8\. 可移植性 9\. 精简性: 尽量不要有多余代码 10\. 层次性 11\. 标准技术 软件系统->子系统/包->类->子程序->子程序内部 尽量不要越级思考 ### 系统层次化 #### 子系统/包 (系统规模很小时, 可以不设置此层次) 严格限制子系统之间的通信, 以降低更改模块时的难度, 降低系统整体熵. 最好是能设计成有向无环图. 尽量减少子系统之间的交互(调用子程序->包含另一个子程序的类->集成另一个子程序的类) 子程序常见分类 * 业务规则 * 用户界面 * 数据库访问 * 系统依赖 #### 类 把所有的子系统进行适当的分解, 并确保分解出的细节都恰到好处, 能够用单个类实现. 准确的说是定义好类的接口 #### 分解成子程序 这个是说要注重类的私有子程序, 辅助接口的完成 ### 抽象与封装 封装的深刻含义有两个, 一个是抽象, 让开发人员在更高的层面来看待问题, 解决问题. 另一种是隐藏, 即你能看到的即是你全部能得到的.