第六章：当你编码时
一.靠巧合编程
这当然是不行的，作为一个开发者，需要的是深思熟虑的编程，一味地靠巧合编程，那结果必然是灾难性的。最根本的原因依靠巧合编程，一旦代码错误，我们根本不知道代码哪里错误，为什么错误，解决方法是什么。在很多时候我也是靠着巧合编程，有时候自己都没有知道这个类的基本使用方法就直接拿过来使用，导致用的时候一头雾水，不明所以。就比如说在Android中stopservice和stopself的区别，两者都是用来结束服务，但是区别在哪，何时使用前者，何时用后者，有时候stopself就是无法结束服务，为什么，简简单单来过来用就可以吗？也许即使运行成功了，下一次没有成功问题出在哪里了呢？在你不了解某个技术或是方法之前，不是去直接使用，而是去学习。磨刀不误砍柴工。
二.算法速率
老师上课的时候总是喜欢这样，先让你实现一个不算难的小程序，然后开始加大难度，降低时间复杂度，从O（n ²）降到O（n）等等，一开始是感觉老师真是挺无聊的，实现程序不就行了吗，为什么还要降低复杂度，有一次在运算查找最大连续子数组时，我才有些明白其中的道理，现在处理的文件还是比较少的，当信息的量达到几十万几百万的时候，如果算法的时间复杂度过于大，那么等待的时间真的是太长了。
三,重构
当我们发现代码不合适的时候，不要对改动犹豫不决，应该现在就做，作者给出的提示是：早重构，常重构。及时的重构防止软件不得不重构时要面对的窘境，到时，工作量也会极具的上升。在重构时，我们也需要明白，重构不应该在此之上添加新的功能，如果要，不如添加一个新的方法。
四.易于测试的代码
测试方面，我一直都没有太重视，每次都是简单的验证一下功能是否能够使用就结束了，这对于正规的测试来说显然是不够的，作者的提示是：为测试而设计。我们在测试的时候要穷尽所有的可能来测试，毕竟在现实生活中，遇到的问题甚至可能要比刁钻的测试更让人意想不到。更重要的是测试最根本的目的是完善产品，对产品进行彻底的测试，这种预先的准备可以大大降低维修费用，减少客户服务电话。作者也在最后总结：测试你的软件，否则就是你的用户就得测试。这肯定不是用户说期望的。
五.邪恶的向导
在使用编译器的时候，我们很容易就会在创建某一个文件的时候使用向导，但是我们真正的理解了向导生成的代码真正的意义吗？向导是一条“单行道”，它为你制作代码，然后就结束了，如果向导制作的代码不完全正确，或者是情形变了，需要我们改变代码，那这个时候我们就只能靠自己了。这里的向导并不是指一组库调用或者标准的操作系统服务，我们对向导的感觉是一样的，但前者显然不是，我们应该让向导的代码和我们自己的代码交织在一起，全部变成自己的代码，没有人应该制作他们不完全理解的代码。