敏捷实践之代码审查code review

本文是个人总结摘记，部分文字摘自其他大神博文等，如有雷同，未列参考文献，请见谅；

定义

• 代码评审通常的目的是查找系统缺陷，保证软件总体质量和提高开发者自身水平。 CR应该是处在研发流程中，提前发现系统缺陷，进而提前解决，并且是轻量级代码的check和沟通，一是代码review量，二是代码结构足够轻量，流程正确，它可以起到更加积极的效果；

目的

• 提升代码质量；一是可读性，二是缺陷情况；
• 有利于团队对业务的理解加深；保证项目组人员的良好沟通（业务/技术），提高队友互补性
• 提升团队凝聚力，一致性；团队代码风格的统一，更容易pair，帮助新同学快速融入团队；
• 技术与业务知识共享，共同进步，Code Review可以打造良好的技术氛围，培养技术情怀;
• 促进人才成长，激励代码提交者，review是一种沟通方式，表达沟通能力的增强，让每个同学得到锻炼；

总的来说：CR能够提升代码质量、促进人才成长、培养技术情怀，CR同样应该被当做一种文化去培养，更像是一种软性的力量，去开发者联系在一起的感情系带；

要点

• 哪些代码需要引入CR：核心链路业务代码，系统底层框架核心代码；哪些代码是不需要引入CR：业务直译式代码
• review前：
  • 每天进行7点review，每次review的集中注意力时间为一个小时，项目的整体review除外；
  • 团队心智达成一致，心态上的准备，按照java开发规约以及团队形成的代码规约沉淀；
  • 代码提交按照commit维度，保证每一次提交可被review的，和早会、ipm卡强关联；
  • 自己要先review代码，不耽误大家时间，review时风格符合规范、逻辑清晰
• review中：
  • CR开始，先检查昨天的Action；
  • 先讲一下背景和解决思路，增加大家大家代入感，有个准备的提醒，组织者需要好好准备；
  • 日常review（专项除外）不要出现大面积的讨论，cr不是技术/需求评审：
  • 三方面review：业务review，技术讨论，问题反馈；
  • 细节：统一代码风格，处理Bad Smells，检查代码实现的性能、安全、模型设计等，检查测试，同步项目中的业务逻辑变更、技术选型调整等；
  • 遇到分歧点，尽快确认问题点，记录action； 允许讨论，限制3分钟，超时请线下；
• review后：
  • actions落实，修复每一个todo项；