摘自代码大全第三章,以备做架构时确认用。防止易得倾向性。
以下是一份问题列表,优秀的架构应该关注这些问题。这张核对表并非用做一份如何做架构的完全指南,而是作为一种实用的评估手段,用来评估软件食物到了程序员这一头还有多少营养成分。这张核对表可用做你自己的核对表的出发点。就像“需求”的核对表一样,如果你从事的是非正式项目,那么你会发现其中某些条款甚至都不用想。如果从事的是大型的项目,那么大多数的条款都会很有用的。
针对各架构主题
1.程序的整体结构是否清晰?是否包含一个良好的架构全局观(及其理由)?
2.是否明确定义了主要构造块(包含每个构造块的职责范围及与其他构造块的接口)?
3.是否明显涵盖了“需求”中列出的所有功能(每个功能对应的构造块不太多也不太少)?
4.是否描述并论证了那些关键的类?
5.是否描述并论证了数据设计?
6.是否详细定义了数据库的组织结构和内容?
7.是否指出了所有关键的业务规则,并描述其对系统的影响?
8.是否描述并论证了处理I/O的策略?
9.是否估算了稀缺资源(如线程、数据库连接、句柄、网络宽带等)的使用量,是否描述并论证了资源管理的策略?
10.是否描述了架构的安全需求?
11.架构是否为每个类,每个子系统,或者每个功能域(functionality area)提出空间和时间预算?
12.架构是否描述了如何达到可伸缩性?
13.架构是否关注互操作性?
14.是否描述了国际化/本地化的策略?
15.是否提供了一套内聚的错误处理策略?
16.是否规定了容错的办法(如果需要)?
17.是否证实了系统各个部分的技术可行性?
18.是否详细描述了过度工程(overengineering)的方法?
19.是否包含了必要的“买vs.造”的决策?
20.架构是否描述了如何加工被复用的代码,使之符合其他架构的目标?
21.是否将架构设计的能够适应很可能出现的变更?
架构的总体质量
1.架构是否解决了全部需求?
2.有没有哪个部分是“过度架构/overarchitected”或“欠架构/underarchitected”?是否明确宣布了在这方面的预期指标?
3.整个架构是否在概念上协调一致?
4.顶层设计是否独立于用作实现它的机器和语言?
5.是否说明了所有主要的决策的动机?
6.你,作为一名实现该系统的程序员,是否对这个架构感觉良好?