一个项目的质量通常分为内部质量和外部质量两种,内部质量通常指代码和设计的质量,可以通过应用设计和编程达到最佳实践,也可以通过持续一致的开发和交付流程来提高;外部质量是通过查看和使用软件(例如验收测试)来度量的。从长远的角度看,内部质量不佳最终会影响外部质量,产品会持续不断地冒出新的bug,产生技术债务,而且开发时间会由于技术债务的增加而变长。项目的内部质量很大程度上取决于代码规范和代码审查(Code Review)。
这是Code Review 的初衷,也是Code Review 最直接的价值。Reviewers 根据各自的经验,思考方式,看问题的角度给代码提出各种可能的改进意见,提升系统的可维护性,从而形成更好的代码以及产品质量。
我们知道产品问题越晚提出解决它的代价就越大,参与进去的人、要走的流程都会越来越多。Code Review 可以及早发现潜在缺陷与BUG,降低事故成本,是早期解决问题最有效的途径之一了,在Code Review 中解决掉哪怕一个小问题都可能避免后续一堆的麻烦事。做好事前控制而不是事后弥补。
有效的Code Review 最终会在团队范围内建立起统一的质量标准,并且会随着团队成员的互相学习和促进形成更高的标准。参与者会在Code Review 的过程中基于具体问题从不同角度提出改进意见,并最终做出当前最佳的选择并形成共识。随着Code Review 的有效进行,团队成员会有意识地关注代码质量,从而形成越来越高的质量标准。
其实Code Review 不应该是一个单向的过程,而应该是个双向交流的过程,Reviewer 帮助Author 提出代码改进意见的同时,也是向优秀的Author 学习的过程。我们都知道提高代码能力一个有效的途径是阅读优秀的项目代码,但是阅读项目代码有着不小的难度,这也是大部分人没有去执行的原因,而Review 资深同事的代码,我们在阅读代码的同时能够直接进行有效的沟通,这是一个快速有效的学习途径,尤其对开发经验还不算丰富的开发者而言。这样也可以促进团队内部知识共享,提高团队整体水平。
通过有效的Code Review,Author 和Reviewer 都将获得成长,在Code Review 过程中参与人就具体的问题展开深入的讨论,无论是怎么写出整洁的代码、怎么更好地更全面地思考问题、怎么最佳地解决问题,参与人都可以互相取长补短,互相提高。通过具体代码实现进行的讨论往往是最深入和有效的,Code Review 是开发者提高代码能力最重要的途径之一。这也是一种思路重构的过程,可以帮助更多的人理解系统,类似于组队编程,降低因人员流失的运营成本及风险。
没有统一的代码规范,每个人的代码可能会风格迥异,为代码的阅读、维护和扩展提高了不小的难度。
随着业务的迅速发展,大量的需求和优化问题接踵而来,导致开发工期紧凑,完成迭代任务都要加班加点,更加难以抽出时间执行Code Review。
一般情况下Code Review 都是找他人来进行Review,其实负责任的Author 在邀请他人来代码审查前也需要自己简单Review 一遍,即自我审查。在Code Review 上,Author 需要意识到:Reviewer 的时间是宝贵的。因此在正式邀请Reviewer 发起代码审查前,Author 有几项需要注意的点,这些都能提高Code Review 的效率,节省Reviewer 的时间。
自我审查的目的:
使用代码扫描工具可以检测代码规范,并提出问题说明和修改建议。此外,还可以发现一些人工不容易发现的空指针异常和IO 流未正确关闭等致命性bug,杜绝此类“零容忍”的异常在线上发生,从而减少大量人工成本和事故率。代码扫描工具比较主流的有Sonar、FindBugs、Alibaba Java Coding Guidelines、CheckStyle等。
Author
Reviewer
关于代码扫描工具,比较主流的有Sonar、FindBugs、Alibaba Java Coding Guidelines、CheckStyle。
综上所述,个人建议选择Sonar。