程序员修炼之道（下）
Friday, March 30, 2018
15:17
就如同我在上篇读书笔记中说的那样，这本书中的一些方法和思想，需要我们在之后的编程学习过程中一点一点的参悟和领会。
曳光弹
比如说从我的第一次个人作业中，我对书中提到的曳光弹代码就有了很深的感触：根据书中给出的例子，我对“曳光弹”的理解是MVP，最小可用产品。甚至是比MVP更简单，进一步最小化的，一段核心算法，一个可操作的简单界面...等等。避免从复杂繁重的文档和大而全的设计开始，直击要害（或者说是你认为的“要害”），实现一个可供操作和评估的东西，观察用户的反应。一旦命中，再对其进行修缮和完备，反复在系统的各个部分实施这样的动作，形成最终的产品。在这次第一次的个人作业代码编写中，有一个很重要的功能实现就是文件夹的遍历，这是我所不熟悉的文件操作里面的，但我可以应用曳光弹的这个想法，让我的代码在黑夜中发光！！
预备：我首先在网上查找相关系统函数的资料，然后写了一段递归的代码
开火：我将这段曳光弹代码的输出功能设定在简单的输出所有的文件名，然后用数据进行训练
瞄准：根据这个简单的输入和输出，我就可也直观的看出代码中间的核心逻辑部分是否存在问题根据问题指向就能轻松地对代码进行修正。
这样我就得到了一定没有错误的一段文件遍历的核心代码，之后我再这个代码的基础上增加文件读取等其他功能的时候就不会担心文件遍历这个核心逻辑的正确性。
同时就像书中所说，曳光弹代码不是用过就扔掉的代码，编写它，是为了保留它。我同样可以将这个没有问题的简单的读取文件名称的代码保存起来，等到以后有用到文件遍历的时候就在其基础上进行开发。
代码管理
在书中，作者在基本工具的建议中建议使用源码管理工具。
在第一次的个人作业中，我使用了git作为我的源码管理工具，在使用的过程中，发现了这样做的好处。我可以大胆的修改我的代码，而不用担心我的代码不能回到原来的版本。其次，我还能在branch中规范自己分支的主要目的，这样可以明确目标。在git log中可以跟踪自己的commit，跟踪自己的开发进程，同时还可以通过github进行代码同步和跨平台开发。
调试
不要慌张。就像老师在课上提到的，真正有经验的程序员会花上几个小时的时间去修复一个bug而十分的平静。
开始修复bug的最佳途径就是再现bug
跟踪，发现一个预料之外的坏变量时候，当你准备修复之前应该快速的看一下这个变量旁边的几个变量的值。
不要靠巧合编程
在书中，作者举了一个例子，说明了很多时候，当我们测试时代码没有明显的错误，但是之后出现bug很大的一个原因就是，我们根本不知道这段代码为什么可以工作
这里和老师在课上提出的意见：不要复制和粘贴代码，如果有需要，我们也应该一行一行的重新抄写，同时，理解这段代码的逻辑。
在这次的个人作业中，我就遇到了这个问题，在设计这个一个hash函数的代码中，我为了可以是字符在表中可以尽可能的散开，我在网上找到了一段有名的hash代码（针对于输入字符串）。
然后稍微看了一下后直接替代了原来的hash函数，在小的数据集中没有出现明显的错误，于是我就觉得这段代码没有什么问题，但是在应用到大的数据集的时候，就出现了大的冲突错误（我本来已经开了足够的哈希表空间）但是还是放不下。一开始，我不能很快的发现问题所在，因为我以为这个hash函数是没有问题的，在花费了大量的时间查找问题之后，才发想了这个问题出现在这个hash函数中，复制粘贴虽然节省了我几分钟的时间但是之后的debug却花费了我数百倍的时间，所以我感触极深。
不要猜想，要勇于尝试
可以编写，断言来验证我的猜想（断言式编程）
结合我第一次代码编写的经历，我在对string数据类型的还是操作时候不是很熟悉，不是很有底，在需要用的时候就会在shell里面开一个小的程序来验证我的想法，当然按照这本书的建议，我之后可能可以尝试去使用assert断言，
#include <assert.h>
void assert( int expression );
早测试，常测试，自动测试
不是很了解自动测试的概念，去网上查找了一下后，发现了几款自动测试的工具，争取下次用到个人作业或者结对作业中。
好记忆不如烂笔头
要把英语（中文）当做一种编程语言
文档分为外部文档和内部文档，内部文档包括源码注释，设计和测试文档，外部文档包括用户手册，技术文档等。
在这里，作者推荐我们学习一下标记语言，可以提高效率。
所以找时间把markdown学一下。
