背景
除了编码之外，开发者平时最常遇到的麻烦就是软件缺陷了，
指的是，软件在某些情况下，表现出了与预期不符的行为。
确保软件没有缺陷，是一件很难的事情，
因为一方面，预期是会变的，
另一方面，修改软件的一部分也许会不小心影响到其他部分。
那么就这样听天由命了么？
很显然这是不行的。
写出高缺陷率的代码，是不专业的表现。
只有运行起来没问题的代码，再追求清晰易懂才是有意义的。
文本就来探讨，如何写出低缺陷代码的编码技巧。
亲手测试
在讨论技巧之前，我们不妨先反思一下，
是哪些事实，让我们坚信自己写的代码肯定没有问题？
我认为只有一条，那就是我们自己测试过了。
不论是通过自动化的测试，还是手工测试，
不论是通过肉眼亲见，还是通过逻辑证明。
我们应该只相信自己测试过的代码。
不能将 ”确保代码没有问题“ 这件事委托给他人。
所以，一个负责任的开发者，绝不会交付没有经过自测的代码。
让别人找出问题再修复，肯定会耗费更多的时间。
这就是为什么有时候改一行代码，也需要很久的原因了，
因为这一行代码，可能会影响到很多其他模块，
这些受影响到的模块，都应完整的进行测试。
假设自己的写的代码没有问题，正是产生问题的根本原因。
直面需求
有的人可能要说了，某些缺陷可能并不是编码引起的，
而是因为需求变更所致。
其实不然。
真实的需求就在那里，绝大多数情况下，变更的都不是需求，
而是对需求的理解。
产品经理说这样做，就这样实现，说那样做，就那样实现，
这正是误解需求的主要原因。
为了能够真正的理解需求，开发者应该走在产品经理的前面，
不然代码写完了，发现不满足需求，不是还要修改么？
为了能让自己少改几次代码，一定得做到比任何人更懂需求才行。
完整日志
代码未写完之前，日志先行。
大部分的软件缺陷，是由输入跟预期不符造成的。
意料之外的输入参数，会导致不确定的执行结果。
所以，代码逻辑的执行日志，
不论对排查问题，还是对编写低缺陷率的代码而言，都是非常重要的。
在出现问题的时候，我们必须能一目了然的知道问题出在哪里。
经验表明，“问题排查的简易程度” 与 “代码的低缺陷率” 是正相关的。
越容易排错的代码，缺陷率越低。
因此，在写代码之前，就得先考虑清楚，
如果我写的代码得到了奇怪的结果，要怎么定位问题？
日志是行之有效的一种手段。
易于定位问题的代码，能有效避免事后很大一堆麻烦事。
也谈单测
单测，通常指的是自动化的单元测试，
它是实现单元测试的一种自动化的手段，一般是运行一个脚本来执行程序，
再检测执行结果是否跟预期相符。
与流行说法不同，我认为写单测其实并不是那么重要。
尤其是每次写完代码都要费力改好多单测的话，
那还不如不写。
上文提到过，确保代码没有缺陷的办法是自己进行完整的测试。
至于用什么办法确保，要灵活应对。
如果担心别人写的代码，影响了自己负责的功能，是可以写一点单测，
如果需要频繁的构造数据来测试某一块代码，也可以写一点单测，
除此之外，单测真的非常鸡肋。
最后，追求单测覆盖率，没有太大意义，
“覆盖率” 这个指标，只能检测是否所有代码都有用，有没有代码执行不到。
至于执行到的代码有没有错误，覆盖率不关心这些。
所以，我们完全可以写出覆盖率 100% 的问题代码。
结语
本文讨论了编写高质量（低缺陷率）代码的几个方法：
（1）亲手测试：凡需交付的代码，必完整的亲手测试过
（2）直面需求：做到比任何人更懂需求，才能确保代码跟预期相符
（3）完整日志：代码未写，日志先行，让输入输出一目了然，易于排错
还讨论了个人对 “单元测试” 以及 “单测覆盖率” 的看法。
盲目追求漂亮的数字，最终就会自缚手脚。
低缺陷率的代码，来源于专业精神，妥协于外力，最后还得自己收拾烂摊子。