代码大全核对表2

 

伪代码编程过程
[] 是否把伪代码正确地翻译成代码了?
[] 你反复使用伪代码编码过程了吗?有没有根据需要把一些子程序拆分成更小的子程序?
[] 在做出假定的时候有没有对它们加以说明?
[] 已经删除掉那些冗余的注释了吗?
[] 你是否采取了几次迭代中最好的那个结果?还是在第一次迭代之后就停止了?
[] 你完全理解你的代码了吗?这些代码是否容易理解?

表驱动法
如果无法用一种简单的数组索引(像age示例中那样)去访问表,那么你把计算访问键值的功能提取成单独的子程序,而不是在代码中重复地计算键值吗?

质量保证计划
[] 项目计划中是否有计划有步骤地保证了软件在开发各阶段的质量?
[] 管理层是否能理解为了质量保证在前期消耗额外成本,目的就是在项目后期减少成本?

有效的结对编程
[] 是否己经有一个编码规范,以便让程序员始终把精力集中到编程,而不是编码风格的讨论上?
[] 结对的双方是否都积极地参与?
[] 是否避免了滥用结对编程,而是选择那些能够从中获得好处的工作进行结对编程?
[] 是否有规律地对人员和工作任务进行轮换?
[] 结对组合是否在开发速度和个性方面互相匹配?
[] 是否有一个组长专注于项目管理以及与项目外其他人的沟通?

有效的详查
[] 你是否有一个核对表,能让评论员将注意力集中于曾经发生过问题的领域?
[] 你是否专注于找出错误,而不是修正它们?
[] 你是否考虑制定某些视角或者场景,以帮助评论员在准备工作的时候集中注意力?
[] 你是否给予评论员足够的时间在详查会议之前进行准备,是否每一个人都做了准备?
[] 是否每一个参与者都扮演一个明确的角色——主持人、评论员及记录员等?
[] 会议是否以某种高效的速度进行?
[] 会议是否限制在两个小时以内?
[] 是否所有详查会议的参与者都接受了如何进行详查的针对性培训?是否主持人接受了有关主持技巧方面的针对性培训?
[] 是否将每次详查所发现的错误数据都收集起来,使你能调整本组织以后使用的核对表?
[] 是否收集了准备速度和详查速度方面的数据,以便你去优化以后的准备和详查工作?
[] 是否每次详查中被指派下去的活动都被正确跟进了,无论是通过主持人自己还是一次重新详查?
[] 管理层是否理解他们不应该参与详查会议?
[] 是否有一个用于保证修正正确性的跟进计划?

重构的理由
[] 代码重复。
[] 子程序太长。
[] 循环太长或者嵌套太深。
[] 类的内聚性太差。
[] 类的接口的抽象层次不一致。
[] 参数表中参数太多。
[] 类的内部修改往往局限于某个部分。
[] 需要对多个类进行并行修改。
[] 对继承体系的并行修改。
[] 需要对多个case语句进行并行修改。
[] 相关的数据项只是被放在一起,没有组织到类中。
[] 成员函数更多地使用了其他类的功能,而非自身类的。
[] 过于依赖基本数据类型。
[] 一个类不做什么事。
[] 连串传递流浪数据的子程序
[] 中间人对象什么也不干。
[] 某个类同其他类关系过于密切。
[] 子程序的命名太差。
[] 数据成员被设置为公用。
[] 派生类仅仅使用了基类的一小部分成员函数。
[] 用注释来掩饰拙劣的代码。
[] 使用了全局变量。
[] 在子程序调用前使用设青代码,调用后使用收尾代码。
[] 程序包含的某些代码似乎在将来某个时候才会被用到。

重构总结
语句级别的重构
在嵌套的if-then-else语句中一旦知道结果就立刻退出,而不是仅仅赋一个返回值。
将条件语句中不同部分中的重复代码合并。
系统级的重构
[] 为无法控制的数据创建明确的索引源。
[] 使用工厂函数而非简单的构造函数。
[] 用异常代替错误代码,或者反其道而行之。

[] 在重构之前,你保存了初始代码了么?
[] 在重构时你是否把要做的事情一条条列了出来?
[] 你是否设置了一个停车场,把你在重构时所想到的任何东西记下来?
[] 在每次重构后你会重新测试么?
[] 如果所做的修改非常复杂,或者影响到了关键代码,你会重新检查这些修改么?
[] 你是否考虑过特定重构的风险,并以此来调整你的重构方法?
[] 你所做的修改是提升还是降低了程序的内在质量?
[] 你是否避免了将重构作为先写后改的代名词,或者作为拒绝重写拙劣代码的托词?


代码调整方法
同时改善代码执行速度和规模
[] 用查询表替换复杂逻辑。
[] 合并循环。
[] 使用整型变量而非浮点变量。
[] 预先计算结果。
[] 将关键子程序代码转化为某种低级语言代码
仅仅提高代码执行速度
[] 在知道答案后就停止执行判断。
[] 根据各种情况的出现频率对case语句和if-then-else串排序。
[] 把执行最为频繁的循环放在嵌套循环的最里面。
[] 减轻内层循环的强度。
[] 将多维数组改为一维数组。
[] 最大限度减少数组索引。
[] 对频繁使用的值进行缓存。

配置管理
口你的软件配置管理计划是否用于帮助程序员,并能将额外负担降至最低?
口你的软件配置管理方法是否避免了对项目的过度控制?
口你是否将一些变更请求聚成一组?无论采用非正式的方法(如创建一份未决更改的列表)还是更加系统的方法(如设立变更控制委员会)。
口你系统地评估了每一项提交的更改对成本、计划和质量的影响吗?
口你是否把重大的变更看做是需求分析还不够完备的警报信号?

口你定期地备份项目中的所有资料吗?
口你定期地把项目备份数据转移到off-site storage里了吗?
口所有的资料,包括源代码、文档、图表和重要的笔记都得到备份了吗?
口你测试过备份与恢复的过程吗?


口你用版本控制软件来促进配置管理吗?
口你用版本控制软件来减少团队工作中的协调问题吗?

集成
口每次build 后是否都运行冒烟测试,让你知道这个build 能否工作?
口你是否己使build 和冒烟测试自动进行?
口开发人员是否频繁地check in他们的代码——两次check in之间最多间隔一两天?
口冒烟测试是否与代码同步更新,随代码发展而发展?
口破坏build是罕见事件吗?
口是否在有压力的情况下,也对软件进行build和冒烟测试?


编程工具
口你的IDE集成了:源代码控制、build/测试/除错工具,以及其他有用的功能吗?
口如果你正面对超大型的项目,你是否使用了数据字典或者其他“包含系统中使用的各个类的权威描述”的中央知识库
口总而言之,你的工作环境有没有从“充足的工具支援”中获益?

自说明代码
数据名
] 类型名描述有助于说明数据声明吗?
[] 你的变量名有意义吗?
[] 变量只用在其名字所代表意义的场合吗?
[] 你的循环变量名能给出更多信息,而不是i、j、k之类的吗?
[] 你用了名字有意义的枚举类型,而非临时拼凑的标识或者布尔变量吗?
[] 用具名常量代替神秘数值或者字符串了吗?
[] 你的命名规范能区分类型名、枚举类型、具名常量、局部变量、类变量以及全局变量吗?


设计
[] 代码直截了当吗?是不是避免了自作聪明或新花样?
[] 实现细节尽可能隐藏了吗?
[] 程序是尽可能采用问题领域的术语,而非按照计算机科学或者编程语言的术语编写的吗?

posted @ 2020-10-23 09:57  谢凌  阅读(181)  评论(0编辑  收藏  举报