如何保证高质量代码？
有时候程序员会很苦恼，为什么自己这么多bug；有时候测试人员更苦恼，为什么这么简单的case都有bug。是的，对于资深测试人员来说，他们更愿意去发现深层次的bug，而不是总是被一些小小的，显而易见的bug给困恼。要知道，反复测试这种bug，对自身来说，也是毫无意义的。
我的身份之一就是程序员，而我敢写这篇文章，证明我在保证高质量代码方面还是有些经验可分享的。废话不多说，下面就“如何保证高质量代码”这个话题进行详细的说明。
背景说明
我现在所在项目是一个年代久远的项目，有成熟的框架，代码量已经积累很多，页面风格固定，时不时会来些大大小小的需求。
方法论
一、拿来主义
如果你的项目背景跟我的项目背景是差不多的，那么拿来主义是非常受用的。项目中已经积累了大量的代码，很多难点都有“先人”的代码作为参考，而且“先人”的代码是经过测试的，所以是经得起推敲的。与其自己新写一套方法，还不如站在巨人的肩膀上，拿来并学习来得更容易。当然，这并不是说直接拿过来就行了，要结合自己的情况，修修补补，也可以想想，自己是否有更好的方法或者有补充的地方。站在别人的肩膀上的意义就在于，不需要从头到尾另辟一条路出来，只需要根据别人开辟出来的路来鉴定是否能到达自己的目的地。
所以一拿到需求，分析下阻碍你的难点，再分析下该难点是否在项目中有类似的做法，有则选择参考。不要一味地陷入自己的思维里。现在项目组就有一个成员，很多问题明明就有参考答案，却硬是要自己作答，还答得并不比参考答案好。
二、经验总结，总结分享
只要写代码，可以说大大小小的难题肯定是遇到过。此次的难题会不会成为你下次的难题，这就要看你愿不愿意总结了。每次遇到难题，都把它记录下来，这样形成自己的一个知识簿，随时都可以翻阅。在编码过程中，很多解决方案可能当初或问同事，或查阅资料，或自己百般尝试才得出来的。很长一段时间过后，可能只是觉得自己曾经解决过这个问题，但是具体方案已经很模糊了。如果不想再次从头开始，那就好好总结并记录吧。
分享总结，更能提升你的成就感，加深对问题的印象，更能帮助项目成员少走弯路。总结分享给他人，记录他人的总结，让开发代码既有效率又有质量。
三、逻辑思考
大的需求下来之后是要分成好几个人开发的。分到自己手上，可能已经不是一个完整的故事，只是当中一个情节。那么我们是不是应该只关心自己的这一个情节呢。有人会说，当然只关注自己这块啊，分工合作不就是这样嘛。是的，每个人关注那么一点点，是叫分工。把一点点硬生生的合在一块，那就不一定叫合作了。
我们做开发的时候，不是照着别人的设计写就行了。我们还必须关注设计是否合理，关注case是否覆盖到，关注边界值，关注故事的合理性，关注故事是不是一个完整的故事，等等。很多人写代码，都是一种事不关己的态度，觉得我只负责把设计写成代码，而且只把属于自己这块的设计写成代码。这不是合作。设计人员就算再细心，再厉害，也会有考虑不周的时候。如果开发愿意去发现设计的不周全，愿意真正以合作的态度去做好一个需求，那么开发的质量是不会差到哪里去的。
四、整理思路
很多人一拿到需求就迫不及待的写代码，这样做很可能造成代码的反攻，整个结构的重组。拿到需求的时候，还是要分析并整理下代码的思路，就算是稍微在脑子里把整个思路过一遍也好。对于复杂的逻辑，就需要在本子上写写思路，写写伪代码。只要思路出来了，写代码还是很快的。所以不要急着去堆代码，一不小心会让代码砸了脑袋。
五、深入测试
开发要保证代码质量，必不可少的就是测试。谁人能保证自己新鲜出炉的代码没问题。开发过程中，可能很多case，很多细节不会去细想；也可能一不小心造成笔误。那么如何去发现这些隐藏的bug？测试，测试，再测试。代码的每个分支都要测一测。不要想当然觉得某块代码没问题，千万不要对未经过测试的代码表现出如此的自信。随着测试的case越多，你代码的bug就越少。
没有bug的代码都是经过反复测试，反复修改的。我从不对自己的代码表示自信，除非它经过了我不断的测试。
希望对大家有帮助，共同进步，共同学习。
