3. 测试
测试很重要，设计测试用例就像开发时设计数据结构一样，也是很关键的。在设计测试用例的时候，要把当时自己设计数据结构的思路全部忘掉，或者找别人来设计测试用例，不然会不由自主地测试那些你已经考虑到了的地方。这样测试是跑通了，用户一用起来可能各种边界条件会到处出问题。
有人会推崇TDD的方法，先设计好测试用例，然后在开发过程中确保所有测试通过。我个人不喜欢这种方法，虽然承认从开发质量管理和长期维护的角度来说TDD是很有必要的，但我个人尝试的结果是，设计完测试用例后，想到开发的目标不是实现功能，而是为了跑通测试，就感到毫无乐趣可言。这一点我自己也觉得很矛盾。
写到这里我又想到大神Linus说过的另一句话：”Regression testing” What’s that If it compiles, it is good; if it boots up, it is perfect. （“回归测试”？这是什么东西？如果代码能编译就是好的，如果它启动了，那就是完美的。）
当然了，大神水平摆在那里，他有资本目空一切，咱确实没资格仿效。但是我还是觉得TDD也有TDD的问题，测试是很重要，但把它摆到驱动开发的高度，就有点本末倒置了。这个是我自己的一点看法，本人对TDD了解得不深入，如果有谬误之处，请多多指教。
4. 代码可读性
要想自己满意，代码的可读性一定要好。要做到一年后甚至几年后你拿到自己写的代码，还能很容易看明白当时的思路和实现。这就涉及到命名和注释的问题。
命名就像超市里的商品标签一样，要让看得人一目了然就知道这是个什么东西，比如你在员工类里定义了两个属性是到岗日期和离职日期，定义成date1和date2就没有多少可读性，定义成dateOnBoard和dateQuit就比较清晰一些。
注释也是很重要的，它可以用来说明一段代码的作用，算法的设计思想，或者是方法调用的参数格式要求等。有人觉得命名就是注释，代码本身就为自己代言了。我觉得这种说法用来强调命名规范的重要性是很好的，但是因此说不需要注释则有失偏颇。试想，如果Dijkstra首次发明最短路径算法的时候，他给出的代码里没有一行注释，即使所有的变量命名都定义得准确而严谨，又有几个人能看懂他的算法呢？所以，在重要或者复杂的地方，都需要详细地写一些注释，便于看代码的人清晰地了解你的思路。
最后总结一下：要想写出自己满意的代码，首先不要急于动手，要先仔细想清楚思路性的东西，尤其是数据结构，然后在实现过程中大胆尝试小心验证，设计好测试用例，确保代码的可读性，就可以在代码中表现出自己的最高水平。但毕竟各人水平是有差异的，自己满意并不等于其他人欣赏。我对此的看法是，不求尽如人意，但求无愧我心，足矣。最后再啰嗦一句，技术水平是可以慢慢提高的，但是好的编程习惯需要从一开始就养成，它会让你在前进的道路上事半功倍，受益终生。
