编程核对表

编程核对表

摘自Code 代码大全，在编码时需要注意确认的事项

一、需求核对表

1.针对功能的需求

是否详细定义了系统的全部输入,包括来源精度取值范围出现频率等。
是否详细定义了系统的全部输出，包括目的地精度取值范文出现频率格式等。
是否详细定义了所有输出格式（web页面、报表等）
是否详细定义了硬件及软件的外部接口
是否详细定义了全部外部通信接口，包括握手协议,纠错协议,通讯协议等
是否列出了用户想要做的全部事情
是否详细定义了每个任务所用到的数据,以及每个任务得到的数据

2.针对非功能需求（质量需求）

是否全部为必要的操作,从用户的视角,详细描述了期望响应的时间
是否详细描述了其他与计时有关的考虑,例如处理时间、数据传输率、系统吞吐量
是否详细定义了安全级别
是否详细定义了可靠性,包括软件失灵的后果,发生故障时要保护的至关重要的信息、错误检查以及恢复策略等
是否详细定义了机器内存和剩余磁盘空间的最小值
是否详细定义了系统的可维护性,包括适应特定功能的变更、操作环境的变更、与其他软件的接口的变更能力
是否包含对“成功”及“失败”的定义

3.需求的质量

需求时用用户的语言书写的嘛,用户也是这么认为的嘛
每条需求都不与其他需求冲突吗
是否详细定义了互相竞争之间的权衡，例如健壮性和正确性的权衡。
是否避免在需求中规定设计（方案）
需求是否在详细程度上保持相当一致的水平？有些需求应该更详细的描述吗？有些需求应当更粗略的描述吗？
需求是否足够清晰，即使转交给一个独立的小组去构建他们也能理解吗？开发者也这么想吗？
每个条款都与待解决的问题及解决方案相关吗？能从每个条款上追溯到他在问题域中对应的根源吗？
是否每条需求都是可测试的？是否可以进行独立的测试，以检验满不满足各项需求
是否详细描述了所有可能的对需求的改动，包括各项改动的可能性？

4.需求的完备性

对于在开始之前无法获得的信息，是否详细描述了信息不完全的区域
需求的完备度是否能达到这种程度：如果产品满足所有需求，那么他就是可以被接受的
你对所有需求都感到很舒服吗？你是否已经去掉了哪些不可能实现的需求（只是为了安抚客户和老板的东西）

二、架构核对表

1.针对各架构的主题

程序的整体组织是否清晰？是否包含一个良好的架构全局观？
是否明确的定义了主要的构造块？
是否涵盖了需求中列出的所有功能？
是否描述并论证了最关键的类？
是否描述并论证了数据设计？
是否详细定义了数据库组织结构和内容？
是否指出了所用关键的业务规则，并描述其对系统的影响？
是否描述了用户界面设计策略？
是否将用户界面模块化使其不会影响到程序的其他部分？
是否描述并论证了处理I/O的策略
是否估算了稀缺资源（线程，数据库链接，句柄，带宽等）？是否描述了资源管理策略？
是否描述了架构安全需求？
架构是否为每个类，每个子系统，每个功能域提供空间时间预算？
架构是否描述了如何达到可伸缩性？
架构是否关注互操作性？
是否描述了国际化/本地化策略？
是否提供了一套内聚的错误处理策略？
是否规定了容错办法？
是否证实了各系统各个部分技术的可行性？
是否详细描述了过度工程的方法？
是否包含必要的”买vs造”决策？
架构是否描述了如何加工被复用的代码，使之符合其他架构目标？
是否将架构设计的能够适应很可能出现的系统变更？

2.架构的总体质量

架构是否解决了全部的需求？
有没有哪个部分是过度架构和欠缺架构？
整个架构是否再概念上协调一致？
顶层设计是否独立于他的机器和语言？
是否说明了所有决策的动机？
你做为一名程序员，是否对这个架构感觉良好？

三、前期准备核对表

是否辨明了自己从事软件的类型，并对所用的开发方法进行相应的裁剪？
是否明确的定义了需求？且需求足够稳定，能够开始构建了？（需求核对表）
是否充分明确地定义了架构，以便开始构建？（架构核对表）
是否已经指出你当前项目种的独有的风险?

四、构建核对表

1.编码

有没有确定有多少设计工作要预先进行，多少设计工作在编码的同时进行?
有没有规定诸如名称注释代码格式等编码约定？
有没有规定特定的，由软件架构确定的编码实践？如异常处理，安全事项，借口约定，重用代码规则。
有没有确定自己在技术浪潮中的位置？并且相应调整自己的措施？

2.团队工作

有没有一整套的集成工具？有没有规范好一套特定的步骤？如合并分支。
程序员结对编程还是独自编程？

3.质量保证

编码之前是否先编写测试用例？
会写单元测试嘛？
在check in时会调用调试器调试嘛？
在check in时会进行集成测试嘛？
会review或检查别人的代码嘛？

4.工具

是否选用了某种版本控制工具？
是否确定语言和编译器版本？
是否明确某个编程框架？
是否允许使用费标准语言特性？
是否选定并拥有了其他将要用到的工具？如编译器，重构工具，调试器，测试框架，语法检查。

五、构建种的设计核对表

1.设计实践

你已经做过多次迭代，并且从众多尝试结果种选择最佳的一种，而不是简单的选择第一次尝试的结果么？
你尝试过多种方案来分析系统，以确定最佳方案么？
你同时使用自下而上和自上而下的方法来解决设计问题么？
为了解决某些特定问题，你对系统中的风险部分或者不熟悉的部分创建过原型，写出数量最少的可抛弃的代码么？
你的设计方案被别人检查过了么？
你一直在展开设计，知道实施细节跃然纸上了么？
你用某种适当的技术来保留你的设计成果了么？比如wiki，UML，数码照片，代码注释

2.设计目标

你的设计是否充分的处理了由系统底层定义出并且推迟确定的事项？
你的设计被划分了层次么？
你对把这一程序分解成为子程序、包、类的方式感到满意么？
你把对这个类分解成子程序的方法感到满意么？
类与类之间的交互关系是否已经设计最小化了？
类和子程序是否被设计成了能在其他系统种重用？
程序是不是易于维护？
设计是否精简？设计出来的每一个部分都绝对的必要么？
设计中是否采用了标准技术？是否避免了使用怪异且难以理解的元素？
整体而言，你的设计是否有助于最小化偶然性和本质性的复杂度么？

要点：
管理复杂度
简单性的获取：减小同一时间关注的本质复杂度；避免不必要的偶然复杂度
设计是一种启发式的过程，固执于某一种单一的方法回损害创新能力，从而损害你的程序
好的设计都是迭代的，你尝试的可能性越多，你最终设计的方案就会变得越好
信息隐藏是个非常有价值的概念

六、类质量核对表

1.抽象数据类型

你是否把程序忠的类都看做是抽象数据类型乐？是否从这个角度评估他们的借口了？

2.抽象

类是否有一个中心目的
类的名字是否恰当，是否能表达其中心目的
类的接口是否能展现了一致的抽象
类的接口是否能让人清楚的明白应该如何用它
类的接口是否足够抽象，使你能不必顾虑它是如何实现其服务的？你能把类看作黑盒嘛？
类提供的服务是否完整，能让其他类无需动用其内部数据
是否从类中除去无关的信息？
是否考虑过把类进行进一步的分解为组件类？是否已尽可能将其分解？
在修改类时是否维持了其接口的完整性？

3.封装

是否把类的成员可访问性降到最小？
是否避免暴露类中的数据成员
在编程语言许可的范围内，类是否已经尽可能的对其它类隐藏了自己的实现细节
类是否避免对其使用者，包括其派生类会如何使用它做了假设
类是否不依赖其他类。它是松散耦合吗？

4.继承

继承是否只用来建立一个is a的关系？派生类是否遵循了里氏替换原则？
类文档中是否记载了其继承策略
派生类是否避免了覆盖不可覆盖的方法
是否把公用的接口数据和行为都尽可能的放到高的继承层次中了？
继承层次是否很浅？
基类中所有的数据是否都被定义为private而非protected？

5.跟实现相关的其他问题

类是否只有大约7个或者更少的数据成员？
是否把类直接或者间接调用其他类的子程序的数量减到最小了？
类是否旨在绝对必要的时候才与其他类互相协作？
是否在构造函数中初始化了所有的数据成员？
除非拥有经过测量的，创建浅层次副本的理由，类是否都被设计成为当作深层次副本使用？

6.语言相关的问题

你是否研究过所用的编程语言里和类相关的各种特有问题？

七、子程序核对表

1.大局事项

创建子程序的理由足够充分嘛？
一个子程序中所有适于单独提出的部分是不是已经被提出到单独的子程序中了？
过程名是否使用了强烈清晰的动+宾词组？函数名字是否描述了返回值？
子程序是否正确描述了它所作的所有的事？
是否给常用的操作建立了命名规则？
子程序是否具有强烈的功能性的内聚性？
子程序之间是否有松散耦合？子程序之间的链接是否是最小的、明确的、可见的、灵活的？
子程序的长度是否由其功能和逻辑自然决定？而非遵循任何人为标准？

2.参数传递事项

整体看来，子程序的参数表是否表现出一种具有整体性且一致的接口抽象？
子程序参数排列是否合理？
接口假定是否已经在文档中说明
子程序的参数是否超过了7个？
是否用到了每一个输入参数？
是否用到了每一个输出参数？
子程序是否避免了把输入参数用作工作变量？
如果子程序是一个函数，那么他是否在所有的可能的情况下都能返回一个合法的值？

八、防御式编程核对表

1.一般事宜

子程序是否保护自己免遭有害数据的破坏？
你用断言来说明编程假定么？其中包括了前条件和后条件么？
断言是否只是用来说明从不应该发生的情况？
你是否在架构或者高层设计中规定了让错误处理更加倾向于健壮性还是正确性？
你是否建立了隔栏来遏制错误可能造成的破坏？是否减少了其他需要关注错误处理代码的数量？
代码中用到辅助调试的代码了么？
如果需要启用或者禁用辅助助手的话，是否无需大动干戈？
在防御式编程时引入的代码量是否适宜？
你在开发阶段是否采用了进攻式编程来使错误难以被忽视？

2.异常

你在项目中定义了一套标准化的异常处理方案么？
是否考虑过异常之外的其他替代方案？
如果可能的话，是否在局部处理错误而不是把他当作一个异常抛到外部？
代码中是否避免了在构造和析构函数中抛出异常？
所有异常是否都与抛出他们的子程序处于同一抽象层次上？
每个异常是否都包含了关于异常发生的所有背景信息？
代码中是否没有使用空的catch语句？

3.安全事宜

检查有害输入数据的代码是否也检查了故意的缓冲区溢出，sql注入，html注入，整数溢出依以及其他恶意输入的数据？
是否检查了所有错误返回码？
是否捕获了所有异常？
出错消息中是否避免出现有助于攻击者攻入系统所需要的信息？