第6章 当你编码时

读书笔记 摘自：《程序员修炼之道》

---

31 靠巧合编程　　

44. 不要靠巧合编程
Don’t Program by Coincidence
只依靠可靠的事物。注意偶发的复杂性，不要把幸运的巧合与有目的的计划混为一谈。

总是意识到你在做什么；
不要盲目的编程；按照计划行事；
依靠可靠的事物（不要依靠巧合或假定）；
为你的假定建立文档；
不要只是测试你的代码，还要测试你的假定，不要猜测，要实际尝试它；
为工作划分优先级；
不要做历史的奴隶，不要让已有的代码支配将来的代码，如果不再适用，所有的代码都可被替换，不要让已经做完的事情约束你下一步要做的事情。
知其然，知其所以然；
能工作，要知道为何能工作；会失败，要知道为何会失败。
不要靠巧合去七拼八凑。

32 算法速率　　

45. 估计你的算法的阶
Estimate the Order of Your Algorithms
在你编写代码之前，先大致估算事情需要多长时间
46. 测试你的估计
Test your Estimates
对算法的数学分析并不会告诉你每一件事情。在你的代码的目标环境中测定他的速度。

估计算法适用的资源－时间、处理器、内存等
用大O表示法来分析算法的效率。培养一种直觉，对一些常见的算法，一看流程就能说出其大O表示，如冒泡排序O(n^2)，遍历O(n)。

33 重构　　

47. 早重构，常重构
Refactor Early, Refactor Often
就和你会在花园里除草、并重新布置一样，在需要时对代码进行重写、重做和重新架构。要铲除问题的根源。

重写、重做和重新架构代码－重构
重复、非正交的设计、过时的知识、性能，需要重构
需要慎重、深思熟虑、小心进行。
　　
1. 不要试图在重构的同时增加功能
2. 拥有良好的测试，经常运行测试
3. 采取短小、深思熟虑的步骤

我并不同意很多书中宣称的一定要重构，以及他们的理由。重构始终是一种艺术，你要在理想与现实之间做出一个权衡。

《重构》那本书介绍了许多重构的方法。但其实我们更需要的是一个比较可靠、高效的重构器，至少C++方面做的还不够好，VS本身未提供多少，而VA插件的重构功能相当有限。

34 易于测试的代码　　

48. 为测试而设计
Design to Test
在你还没有编写代码时就开始思考测试问题。
49. 测试你的软件，否则你的用户就得测试
Test Your Software, or Your Users Will
无情地测试。不要让你的用户为你查找bug。

单元测试可提供：
１.一些例子，说明怎样使用你的模块的所有功能。
２.用以构建回归测试，以验证未来对代码的任何改动是否正确的一种手段。

易于测试的代码会有非常简洁的接口，非常明确的约定，从而也有更好的质量。这是从比较细节的，代码的角度来看的。
而从软件角度来看，就应该提供完善的log机制与诊断功能，这样才能在客户环境下精确的定位错误。

35 邪恶的向导　　

50. 不要使用你不理解的向导代码
Don’t Use Wizard Code You Don’t Understand
向导代码可以生成大量代码。在你把它们合并进你的项目之前，确保你理解全部这些代码。

如果你只是为了编写一个测试程序，你可以不理解向导产生的代码；但是如果你需要基于向导创建一个软件，理解向导产生的代码就显得十分必要了。我想这也是为什么《深入浅出MFC》如此风行的原因吧，大家其实都意识到这个问题了。

部分评论摘自豆瓣书评

---

===========文档信息============
读书笔记由博主整理编辑，供非商用学习交流用
版权声明：非商用自由转载-保持署名-注明出处
署名(BY) ：dkjkls（dkj卡洛斯）
文章出处：http://my.csdn.net/dkjkls