《程序员修炼之道：专业程序员必知的33个技巧》笔记-----第一章

编写生产质量的代码似乎是一个明摆着的目标。

技巧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或改善可读性。了解规则背后的原因，而不是仅仅知道规则是什么。

Google C++编程风格指南

技巧7：改善遗留代码

1.通过复用部分旧程序遏制移植风险。如旧程序是用像C这样常见的语言写的，许多其他编程语言都有一种跟C代码打交道的方法(如Java本地接口，Ruby扩展等)

2.要小心区分Bug(明显的错误行为)和看上去奇怪的代码。

技巧8：代码审核要早且多

1.计数器的循环和迭代器的循环：使用迭代器可以消除"差一"的风险。(很好的代码风格，很有道理)

2.有些项目要求凡是要check-in到代码库的代码都要有"伙伴"签字。