代码大全读后感二

第四章 关键的“构建”决策

 

> 选择编程语言：熟悉的语言比不熟悉的语言生产力高；高级语言（java, c++, python, perl…）比低级语言生产力高。

> 编程约定，如变量命名、类命名、函数命名、格式、文档等。

> 在技术浪潮中的位置：浪潮后期可以稳定持续地编写新功能，而浪潮前期需要耗费更多时间应对不完善的技术。

> Working in a language vs. working into a language

Working in a language意味着对一种语言不够了解，被语言本身的逻辑限制；working into a language意味着在了解已有语言的基础上，由思想确定使用的语言及使用语言的方式。

> 选择主要的构建方法，如编码约定、团队工作方式、质量保证措施、各种工具等。

 

 

* 创造高质量的代码

 

第五章 软件构建中的设计

 

> 设计的限制：

设计是一个“险恶”的问题：只有通过解决或至少部分解决，才能明确地定义它。

设计中会有很多错误和修正的过程。

设计有诸多限制，要针对限制与需求进行取舍。

设计是不确定的，是启发式的过程，是自然而然的。

> 管理复杂度：把任何人在同一时间需要处理的本质复杂度减小到最小（模块化、分工），不要让偶然复杂度无谓地增长（封装、良好的问题处理机制）

> 理想的设计特征：

复杂度最小（可以为此牺牲算法的精巧）；易于维护；松散耦合；可拓展；可复用；高扇入，即让某个特定的类被大量调用，意味着更好地利用低层次的工具类；低扇出，即让某个特定的类尽可能少调用其它的类，减少依赖关系；可移植性；精简性；层次性；标准化。

> 设计层次：

1. 系统层次

2. 分解为子系统或包，常用的有业务规则、用户界面、数据库访问、系统依赖性。

对子系统之间的交互关系要加以限制到最简，一个常用原则是应该无环。

3. 分解为类

4. 分解为子程序

5. 子程序内部设计

> 一些帮助设计的启发式方法：

>> 找出现实世界中的对象：辨识对象及其属性，定义可对对象执行的操作，定义对象可对其它对象执行的操作，如继承、包含，定义对象哪些属性对其它对象可见定义每个对象的接口。

>> 形成一致的抽象。基类就是一种抽象。可以忽略不必要的细节。

>> 用封装实现细节。

>> 当集成能简化设计时要继承。

>> 信息隐藏，隐藏复杂度及隐藏变化源。要避免循坏依赖。不要因为考虑性能放弃信息隐藏，应该在后期寻找性能瓶颈。信息隐藏很有价值，要养成问自己“我应该隐藏什么”的习惯。

>> 找出容易改变的区域，用封装将它与其它区域隔离。如：业务规则，硬件依赖性，IO，非标准的语言特性，困难的设计区域，状态变量，数据量的限制（如数组大小，用宏定义、const替代），。

>> 松散耦合。

标准：规模，耦合越小越好；可见性，接口应该公开；灵活性。

耦合种类：

简单数据耦合：Object1要求Object2传递简单数据为参数，正常的耦合

简单对象耦合：一个模块实例化一个对象，正常的耦合

对象参数耦合：Object1要求Object2传递Object3，耦合较紧密

语义的耦合：十分危险

>> 查阅常用的设计模式

>> 其它，如：高内聚性，一组代码在支持同一目标上的紧密程度；分层结构；严格描述类契约；分配职责；为测试而设计；考虑并避免失误；有意识地选择绑定时间；“唯一一个正确位置的原则”：每一段代码应该只在一个地方能看到，也只在一个地方能进行维护和修改；考虑暴力算法；画图；保持模块化。

> 设计实践：

>> 分治

>> 自上而下 vs. 自下而上

自上而下：从高抽象层次向下逐层增加细节的层次，简化问题的复杂性

自下而上：从具体需要执行的工作出发，进行分类、组合

二者实际没有矛盾，应该配合使用。

>> 构建原型（同样在《程序员修炼之道》中提到过）：用最简单的方式写出仅用来试用某个功能、隐藏细节的代码，随时可以丢弃

>> 合作设计

>> 记录设计成果，方式如将设计文档写入代码、Wiki、总结邮件、数码相机、设计挂图、索引卡片、uml图