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