给我看你的流程图而藏起你的表，我将仍然是莫名其妙。如果给我你的表，那么我将不再要你的流程图，因为它们太明显了。
数据结构设计是程序构造过程的中心环节。一旦数据结构安排好了，算法就像是瓜熟蒂落，编码也比较容易。
-- <<人月神话>> <<程序设计实践>>
“90%的功能现在能实现，比100%的功能永远实现不了强”
“97%的时间里，我们不应考虑蝇头小利的效率提升：过早优化是万恶之源”
-- <>
> 封装和最佳和最佳模块大小
模块化代码的首要特质就是封装。封装良好的模块不会过多向外部披露自身的细节，不会直接调用其它模块的实现码，也不会胡乱共享全局数据。模块之间通过应用程序编程接口（API）——一组严密、定义良好的程序调用和数据结构来通信。这就是模块化原则的内容。
API在模块间扮演双重角色。在实现层面，作为模块之间的滞塞点（choke point），阻止各自的内部细节被相邻模块知晓；在设计层面，正是API(而不是模块间的实现代码)真正定义了整个体系。
有一种很好的方式来验证API是否设计良好：如果试着用纯人类语言描述设计（不许摘录任何源代码），能否把事情说清楚？养成在编码前为API编写一段非正式书面描述的习惯，是一个非常好的办法。实际上，一些最有能力的开发者，一开始总是定义接口，然后编写简要注释，对其进行描述，最后才编写代码—— 因为编写注释的过程就阐明了代码必须达到的目的。这种描述能够帮助你组织思路，本身就是十分有用的模块说明，而且，最终你可能还想把这些说明做成路标文档（roadmap document），方便以后的人阅读代码。
模块分解得越彻底，每一块就越小，API的定义也就越重要。全局复杂度和受bug影响的程度也会相应降低。软件系统应设计成由层次分明的嵌套模块组成，而且每个层面上的模块粒度应降至最低，计算机科学领域从二十世纪七十年代起就已经渐渐明白了这个道理（有[Parnas]之类文章为证）。
然而，也可能因过度划分造成模块太小。证据[hatton97]如下：绘制一张缺陷密度和模块大小关系图，发现曲线呈U形，凹面向上（见图4.1）。跟中间大小的模块相比，模块过大或者过小都和更多的bug相关联。另一个观察这些同样数据的方法是，绘制每个模块的代码行数和bug的关系曲线图。曲线看上去大致成对数上升至平坦的“最佳点”（对应缺陷密度曲线中的最小值），然后按代码行数的平方上升（这正是人们根据Brook定律对整个曲线的直观预期）。[1]
在模块很小时，bug发生率也出乎意料地增多，这在大量以不同语言实现的各种系统中均是如此。Hatton曾经提出过一个模型，将这种非线性同人类短期记忆的记忆块大小相比较[2]。这种非线性的另一种解释是，模块小时，几乎所有复杂度都在于接口；想要理解任何一部分代码前必须理解全部代码，因此阅读代码非常困难。我们将在第7章讨论程序划分的更高级形式；在那里，当组件进程规模更小以后，接口协议的复杂度也就决定了系统的整体复杂度。
用非数学术语来说，Hatton的经验数据表明，假设其它所有因素（如程序员能力）都相同，200到400之间逻辑行的代码是“最佳点”，可能的缺陷密度达到最小。这个大小与所使用的语言无关——这个结论有力支持了本书中其它地方提出的建议，即尽可能用最强大的语言和工具编程。当然，不能完全照搬这些具体数字。根据分析人员对逻辑行的理解以及其它偏好（比如注释是否剔除）的不同，代码行的统计方法会有较大差别。根据经验，Hatton建议逻辑行与物理行之间为两倍的折算率，即最佳物理行数建议应在400至800行之间。
-- <>
阅读(1326) | 评论(0) | 转发(0) |
