代码走查

目标:
体系架构/设计：
单一职责原则：每个类应该有且只有一个职责。更甚于此，我一般会将此原则应用于方法之上。对于某个方法来说，如果需要用“和”来描述方法的功能，那么该方法的抽象级别就可能是有问题的。
开/闭原则：如果是面向对象的语言，那么是不是所有的对象都对于扩展是开放的，而对于修改是封闭的？
重复代码：关于重复代码，我遵循“三振出局法”。第一次出现代码拷贝，可以保持现状，暂不处理，尽管我并不喜欢这样。如果第二次出现代码拷贝，就需要进行代码重构，将公共的功能抽象出来。
编码风格：
主要考察方面:方法命名，变量命名， 函数长度，类长度，文件长度，文档注释，已注释代码，方法参数数量以及可读性等。
** 测试：**
从测试的角度来说，则需要从测试覆盖度、测试粒度、模拟器的数量、是否符合需求等方面考虑代码走查工作。
关于心态
开发人员有责任保持可正常运转并且易于维护的代码。因此在代码走查的过程中，务必要保持开放的心态。虽然这对于所有人而言都并非易事。
一般来讲，对于审查人员所提出的建议，如果没有明确的不采纳理由，最好根据建议修改代码。如果审查人员对某行代码提出问题，也就意味着这行代码将来也会对其他人造成困扰。此外，代码改动有可能会帮助揭示出更大的架构性问题或缺陷。