设计方式、记录及检查表——代码大全学习笔记

关于设计启发的总结下面是对主要的设计中的启发式方法的总结：

• 
  寻找现实世界的对象

• 
  形成一致的抽象

• 
  封装实现的细节

• 
  在可能的情况下继承

• 
  信息隐藏

• 
  找出容易改变的区域

• 
  保持松散耦合

• 
  探寻通用的设计模式

• 
  高内聚性

• 
  构造分层结构

• 
  严格描述类契约

• 
  分配职责

• 
  为测试而设计

• 
  避免失误

• 
  有意识地选择绑定时间

• 
  创建中央控制点

• 
  考虑使用蛮力

• 
  画一个图

• 保持设计模块化

记录你的设计成果

• 
  把设计文档插入到代码中

在代码注释中写明关键的设计决策，通常放在文件或类的开始处。

• 
  用Wiki记录设计讨论和决策

• 
  写总结邮件

• 
  使用数码相机

把白板上画出的图表照成相片让后插入到设计文档中，这样可以带来事倍功半的效果。

• 
  保留设计挂图

张贴在项目工作区域的墙上，随时查阅浏览。

• 
  使用CRC（类、职责、合作者）卡

使用索引卡片，在每张卡片上，设计者写下类的名称、职责和合作者（与这个类合作的其他类）。一个设计团队便按照这些卡片的内容展开工作，直到他们认为已经创建出一个好的设计方案为止。那时，你只需把这些卡片保留下来，留待日后引用。

• 
  在适当的细节层创建UML图

软件构造中的设计的检查表设计实践

• 
  你已经做过多次迭代，并且从众多尝试结果中选择最佳的一种，而不是简单选择第一次尝试的结果吗？

• 
  你尝试用多种方案来分解系统，以确定最佳方案吗？

• 
  你同时用自下而上和自上而下的方法来解决设计问题吗？

• 
  为了解决某些特定的问题，你对系统中的风险部分或者不熟悉的部分创建过原形、写出数量最少的可抛弃的代码吗？

• 
  你的设计方案被其他人检查了吗（无论正式与否）？

• 
  你一直在展开设计，直到实施细节跃然纸上了吗？

• 
  你用某种适当的技术——比如说Wiki，电子邮件，挂图，数码照片，UML，CRC卡或者在代码写注释——来保留设计成果吗？

设计目标

• 
  你的设计是否充分地处理了由系统架构层定义出并且推迟确定的事项？

• 
  你的设计被划分为层次吗？

• 
  你对把这一程序分解为子程序、包和类的方式感到满意吗？

• 
  你把对这个类分解成为子程序的方法感到满意吗？

• 
  类与类之间的交互关系是否已设计为最小化了？

• 
  类和子程序是否被设计为能够在其他的系统中重用？

• 
  程序是不是易于维护？

• 
  设计是否精简？设计出来的每一部分都绝对必要吗？

• 
  设计中是否采用了标准的技术？是否避免使用怪异且难以理解的元素？

• 整体而言，你的设计是否有助于最小化偶然性的和本质性的复杂度吗？

理想的设计特征最小的复杂度（Minimal complexity）设计的首要目标是让复杂度最小。要避免“聪明的”设计，因为“聪明的”设计常常都是难于理解的。应该做出简单且易于理解的设计。如果你的设计方案不能让你在专注于程序的一部分时安心地忽视其他部分的话，这一设计就没有什么作用了。

易于维护（Ease of maintenance）
意味着在设计时为做维护工作的程序员着想。请时刻想着维护程序员可能会就你写的代码而提出的问题。把这些程序员当成你的听众，进而设计出能自解释的系统来。

松散耦合（loose coupling）
意味着在设计时让程序的各个组成部分之间关联最小。通过应用类接口中的合理抽象、封装性及信息隐藏等原则，设计出相互关联尽可能最少的类。减少关联也就减少了集成、测试与维护工作量。

可扩展性（extensibility）
是说你能增强系统的功能而无须破坏其底层结构。你可以改动系统的某一部分而不会影响到其他部分。越是可能发生的改动，越不会给系统造成什么破坏。

可重用性（reusability）
意味着所设计的系统的组成部分能在其他系统中重复使用。

高扇入（high fan-in）
是说让大量的类使用某个给定的类。这意味着设计出的系统很好地利用了在较低层次上的工具类（utility classes）。

低扇出（low fan-out）
是说让一个类里少量或适中地使用其他的类。高扇出（超过约7个）说明一个类使用大量其他的类，因此可能变得过于复杂。

可移植性（portability）
设计出的系统应该很方便地移植到其他环境中。

精简性（cleanness）
设计出的系统没有多余的部分。任何多余的代码也需要开发、Review和测试，并且修改了其他代码后还要重新考虑这部分。

层次性（stratification）
意味着尽量保持系统各个分解层的层次性，是你能在任意的层面上观察系统，并得到某种具有一致性的看法。

标准技术（Standard techniques）
要尽量用标准化的、常用的方法，让整个系统给人一种熟悉的感觉。


找出容易改变的区域应对易变区域的措施，把看起来容易变化的项目分离出来。

• 
  业务规则

• 
  对硬件的依赖性

• 
  输入和输出

• 
  非标准的语言特性

• 
  困难的设计区域和构建区域

• 
  状态变量
• 数据量的限制