阿里巴巴|如何提高代码质量 aone|Java

为何需要提高代码质量？以下是我认为的几点：
提升代码的可维护性，降低新人接手的成本促进交流，促进知识共享，做好backup 促进风格一致，降低团队间应用流转的难度建设写好代码、做好设计的团队氛围但有一点需要说明，我认为写代码本身是一个创造过程，能让人享受其中，如果有太多的条条框框约束，写代码就失去了创造的乐趣，所以，这里为代码质量建设立一个原则：
只提供建议，不强制遵循鼓励创造性的编码鼓励艺术性的编码如何才能拥有高质量的代码有两种途径：
第一种途径：先有好的设计---然后用优秀的编码去实现---再把优秀的编码风格延续下去第二种途径：从糟糕的代码开始---不断去重构，向优秀的设计方案和代码风格不断逼近---再延续下去代码质量建设怎么开始呢？首先得知道什么是好的代码，这就要有标准，那就是我们常常看到的各种各样的规范，但我觉得要有几个简单的原则，太多了，记不住，有几条原则简单的原则，可以时不时拿来判断，当前做得对不对。
然后就是去实践规范，这里需要一些技巧、一些工具，来帮助我们更好地遵循规范。
接着是度量，看我们对规范实践的效果，这就是我们常说也常做的Code Review ，但Code Review也需要遵循一定的规范，应用一定的技巧。
度量之后是改进， CR结果要及时跟进，这是最重要一环，否则CR就没有实际意义。
总结不可少，复盘是一种很有用的工具， CR也需要复盘，总结CR流程、过程等方面好的和不好的地方，更新规范和checklist 。
接下来我们分别聊一聊各个步骤。
规范: 先知道什么是好代码
从上边高质量代码的诞生途径我们可以看出，设计也是很重要的一环，所以我们的规范包括设计规范和编码规范，结合我们的生产实际，这里加上安全生产的规范，所以规范有3部分：设计、编码、安全生产。
设计: 先有优秀的方案
设计推荐多用图表达，图比文字有更直观的传达能力：
首先是业务流程图，它能快速构建起我们对业务的认知，带着对业务的理解再来看代码，事半功倍。
然后是用例图，清晰地表达出我们系统的职责、边界、服务对象，结合业务流程图，能快速构建起我们对系统职责的认知。
接着是架构图，从我们日常的设计需求来看，架构图是需要的。好的架构图能快速给人搭建起理解的框架，再来看系统的细节部分，就很好理解。架构图推荐 C4 规范，它是我目前接触的表达最清晰的架构图规范。
接着再用时序图、状态图、ER图等把关键和复杂部分的设计表达出来。
但日常我们的需求有大有小，方案也不需要都遵循统一的范本，为了设计而设计，就徒增加工作量了。以按需为第一原则，能把要做啥，怎么做的表达清楚即可。这里按场景推荐各个图的使用场景:
新建应用/对原有应用进行重大修改/复杂项目
业务流程图(交代业务背景) C4的系统上下文、容器、组件这3张图用例图：有多个外部参与者类图：关键模型超过5个状态图：对象状态超过3个时序图：关键流程或复杂链路的参与对象超过3个 ER图：涉及数据库变更(包含数据表结构文档) 一般项目/重大日常
业务流程图时序图(复杂功能、关键流程) 日常
按需编码: 优秀的方案需要优秀的编码
编码最重要的是可读，控制复杂度，做到自解释，能让人像读自然语言一样读自己的代码，这是最高境界，也是神仙境界。然后是可维护性和可变更性，能快速、安全地修改代码是目标。最后是对优雅实现的要求，卓越的代码会让人拍着大腿叫好，这个不稀奇，我们乱糟糟的代码里也偶尔会有闪光的片段。