编写生产质量的代码似乎是一个明摆着的目标。
技巧1:敲打代码
保证代码的品质是一个很大的主题。主要有以下几种形式保证代码质量:
(1)代码评审:让另一个程序员去阅读它从而发现问题,并且有利于团队成员之间传播知识。结对编程算是一种实时的代码评审。
(2)单元测试:测试内部的各个类,方法,验证各个单独部分的逻辑。立足于由内而外地审视产品。
(3)接受测试:模拟真实用户与系统交互。一般是自动化执行,以叙述式文档写出来。需要保证:所有系统组件正在像预期的那样协调工作。
(4)负载测试:讲产品置于真实压力下测试,度量其相应。
(5)定向探索测试:通常人工进行,将程序的边界情况挖掘出来(被(3)疏忽的),并将有用的测试加入到(3)中。
(6)机构测试:外界机构对硬件进行评估测试。
(7)环境测试:硬件产品的对温度和湿度进行极限测试。
(8)兼容性测试:当产品需要与其他产品进行交互操作时,就需要定期验证。
(9)耐久性测试:测试时间需要长些,否则有些隐蔽性错误难以发现。如:计算机在49.7天后停止运行。
(10)Beta测试:让用户试用一段时间以测试产品。
(11)运行中测试。在产品上市后继续测试。
技巧2:坚持正确
1.尽量要隔离有副作用函数和纯函数(纯函数只会改变局部变量)。区分开纯和不纯代码有助于测试正确性。
2.Ruby是动态类型的,因为它直到运行时才验证类型。
3.不要满足100%的测试覆盖率。书写优秀的测试需要思考和优秀的判断。
4. c++中单元测试框架:https://code.google.com/p/googletest/
技巧3:测试驱动设计
1.编程需要严谨,测试为你提供了同时用于设计和满足严谨性的工具。
2.只需测试那些对于确定函数行为必需的值就够了。这既包含正常路径也包含错误情况。
3.几个C/C++的xml解析器http://blog.csdn.net/duanlove/article/details/6919757
技巧4:驯服复杂度
1.理解复杂度的两种来源:必然复杂度和偶然复杂度。
2.《Lions' Commentary on UNIX 6th Edition》[Lio 77]一书中写道:单个程序员能够理解和维护的程序大小的实际限制规模是1万行代码。(我觉得不能太绝对)
3.两点有助于减少软件偶然复杂度:清晰思考和清晰表达。
4.当一组逻辑是隔离的而不是内嵌在一大段代码体内时,它的测试和严格证明要容易得多。
5.当工作在巨大丑陋的代码上时,依次考虑:这段代码想表达什么含义?它有没有办法说得更清楚一点?如果它是清晰表达的问题,你需要把那些碍事的代码段抽象出来。若代码还是有点混乱,那可能是没有清晰思考的产品,需要在设计层面返工。
技巧5:优雅地失败
1.你可能无法修复失败,但代码至少应该尽量失败得优雅一点。
2.在进行可能引起阻塞的操作时,不应该持有锁。
3.使用自动测试工具注入失败来模拟关键资源无响应、死亡、用尽、失效、终止和称为过期资源时的情景,从而可以全面考虑-并验证-每个潜在的奔溃场景。
技巧6:确定风格
1.注释不应该告诉读者代码是如何工作的。应该要把注释的重点放在以下事项上:
(1)若代码不直观,那它的目的是什么?
对于公共API而言,函数前的一段概括性注释会很有帮助。如JavaDoc,Doxygen
(2)有没有什么是你临时需要记下的? //TODO, FIXME
(3)期望的参数和返回值是什么?
(4)文件的版权和许可证是什么?
2.不论正常返回还是异常离开,c++都将调用栈上任何实例的析构函数。
3.找到你使用的风格指南,优先考虑对每天规则的理由进行解释的那份指南。有些规则有点随意,但大多数的目的是为了减少偶发Bug或改善可读性。了解规则背后的原因,而不是仅仅知道规则是什么。
技巧7:改善遗留代码
1.通过复用部分旧程序遏制移植风险。如旧程序是用像C这样常见的语言写的,许多其他编程语言都有一种跟C代码打交道的方法(如Java本地接口,Ruby扩展等)
2.要小心区分Bug(明显的错误行为)和看上去奇怪的代码。
技巧8:代码审核要早且多
1.计数器的循环和迭代器的循环:使用迭代器可以消除"差一"的风险。(很好的代码风格,很有道理)
2.有些项目要求凡是要check-in到代码库的代码都要有"伙伴"签字。