认识达内从这里开始

对于程序员来说，软件编程开发代码质量能够直接反应出一个程序员能力的高低，下面我们就一起来了解一下，在代码质量优化方面，我们需要关注哪些问题。

1. 吹毛求疵般地执行编码规范

严格执行代码编写规范，可以使一个项目乃至一个公司的代码具有完全统一的风格，就像同一个人编写的一样，而且命名良好的变量，函数，类和注释，也无疑可以提高代码的可读性.具体落实到执行层面，可以参照Google的编码规范或者java官方的编码规范，网上可以找到，关键是要严格遵守，并且在code review时，严格要求，没有按照规范的一定要指出并且要求修改.

实际情况往往是虽然大家都知道优秀的代码规范是怎样的，但在具体写代码的过程中，却执行的差强人意，很多情况是认识上不够重视，觉得一个变量或者函数的命名成哪样关系不大，所以不够推敲，注释很多也都不写，code review的时候大家也都事不关己心态，或者觉得没必要太抠细节，导致慢慢的整个code base变得越来越差.所以这里还是要强调一下，细节决定成败，提高团队对代码规范的认同及其严格的执行是关键.

2. 编写高质量的单元测试

单元测试是容易执行，且对提高代码质量见效快的方法之一还。但还是有很多公司对单元测试重视不够，包括一些大的互联网公司，不写或者随便写写。

有些工程师觉得有测试团队就够了，再写单元测试就是浪费时间。其实测试团队的测试和单元测试是在不同层面上的，测试团队的测试一般是黑盒测试，系统层面的集成测试，对于复杂系统来说，组合爆炸，测试团队无法穷举所有的测试用例。单元测试是代码层面的测试，一般是针对类的测试。既然无法从系统的整体上保证100%符合我们的预期，那单元测试起码能保证我们代码在细粒度上运行符合预期。

有些工程师认为开发任务重没时间写。这个还是没有足够重视单元测试，觉得是可有可无的部分，才会有这样的想法。写好单元测试，节省很多解决线上bug的时间，开发时间反而更充足了。

还有很多工程师虽然在写单元测试，但只对正常流程做测试。代码中的bug多数是写代码时异常情况没有考虑全面导致的，正常流程一般不会出问题。单元测试的作用就在于测试各种异常情况下代码的运行是否符合预期，所以只对正常流程测试无法发挥单元测试真正的作用。

一般情况下，单元测试代码量要比要测试的代码多，一般是1-2倍的样子，写单元测试本身没有太多的技术挑战，主要看工程师逻辑是否缜密，能够考虑各种异常情况，写起来比较枯燥，所以写高质量的单元测试的一方面要靠工程师的耐心执行，另一方面要靠团队的严格要求。当然这些都是建立在对单元测试重要性的认同之上。

3. 不流于形式的Code Review

如果说单元测试很多工程师不怎么重视，那code review就是不怎么接受.跟很多大型互联网公司的人聊过，对code review都不怎么认可，大部分反应都是，这玩意不可能很好的执行，浪费时间，是的，code review做的再流畅，也是要花时间的，关键在于我们是愿意花2天写代码花5天修bug,还是愿意花3天写代码花半天修bug.

其实，code review的好处不仅仅是能够大大提高代码质量，减少代码bug，你想想如果我们没有code review，平时写的代码“偷偷”就commit了，难免有人不自律，有了code review，直播代码，曝光dirty code，大家就会更认真些.其次来讲，code review也是一种有效技术传帮带的途径，每次code review都是一次案例的剖析，可以帮助初级的工程师培养编码规范，提高编码质量，设计能力甚至于架构能力，反过来，review别人写的好的代码，对自己也是一种学习和提高.

节选：稀土掘金

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!