《代码大全2》读书笔记

软件的复杂性来自本质性和偶然性

 

没有人的大脑装得下一个现代的计算机程序，所以必须把程序组织起来，一次只关注一小部分。

 

信息隐藏要隐藏的是复杂度和变化源

 

concept blockbusting有一些设计的习题，有助于锻炼智力

How To Solve It: A New Aspect of Mathematical Method

How to Solve It: Modern Heuristics

 

 

警惕从语义上破坏封装，主要是指函数执行一些接口上无法知道的东西

 

 

核对表：架构

针对各架构主题

  程序的整体组织结构是否清晰？是否包含一个良好的架构全局观（及其理由）？

  是否明确定义了主要的构造块（包括每个构造块的职责范围及与其他构造块的接口）？

  是否明显涵盖了“需求”中列出的所有功能（每个功能对应的构造块不太多也不太少）？

  是否描述并论证了那些最关键的类？

  是否描述并论证了数据设计？

  是否详细定义了数据库的组织结构和内容？

  是否指出了所用关键的业务规则，并描述其对系统的影响？

  是否描述了用户界面设计的策略？

  是否将用户界面模块化，使界面的变更不会影响程序其余部分？

  是否描述并论证了处理I/O的策略？

  是否估算了稀缺资源（如线程、数据库连接、句柄、网络带宽等）的使用量，是否描述并论证了资源

管理的策略？

  是否描述了架构的安全需求？

  架构是否为每个类、每个子系统、或每个功能域(functionality area)提出空间与时间预算？

  架构是否描述了如何达到可伸缩性？

  架构是否关注互操作性？

  是否描述了国际化/本地化的策略？

  是否提供了一套内聚的错误处理策略？

  是否规定了容错的办法（如果需要）？

  是否证实了系统各个部分的技术可行性？

  是否详细描述了过度工程(overengineering)的方法？

  是否包含了必要的“买 vs. 造”的决策？

  架构是否描述了如何加工被复用的代码，使之符合其他架构目标？

  是否将架构设计得能够适应很可能出现的变更？

架构的总体质量

  架构是否解决了全部需求？

  有没有哪个部分是“过度架构/overarchitected”或“欠架构/underarchitected”？是否明确宣布

了在这方面的预期指标？

  整个架构是否在概念上协调一致？

  顶层设计是否独立于用作实现它的机器和语言？

  是否说明了所有主要的决策的动机？

  你，作为一名实现该系统的程序员，是否对这个架构感觉良好？

 

核对表：软件构造中的设计
设计实践
 你已经做过多次迭代，并且从众多结果中选择最佳的一种，而不是选择第一次尝试的结果吗？
  你尝试用多种方案来分解系统，以确定最佳方案了吗？
 你同时用自下而上和自上而下的方法来解决问题了吗？
 为了解决某些特定问题，你对系统中的风险部分或下熟悉的部分创建过原型、写出数量最少胡可抛弃的代码了吗？
 你的设计方案被其他人检查了吗？
 你一直在开展设计，直到实施细节跃然纸上了吗？
 你用某种适当的技术－－比如说wiki，电子邮件，挂图，数码照片，UML，CRC卡或者代码注释－－来保留设计成果了吗？
设计目标：
 你的设计是否充分体现出由系统架构层定义出并且推迟确定的事。
 你的设计被划分为层次了吗？
 你对把这一程序分解成子程序的方法感到满意吗？
 类与类之间的交互关系是否已经设计为最小化了
 类和子程序是否已经设计为能其他系统中重用
 程序是不是易于维护。
 设计是否精简，设计出来的每一部分都绝对必要吗？
 整体而言，你的设计更不有助于最小化偶然性的和本质性的复杂度吗？