CR code review策略

                       聊聊Code Review

概述
why：质量重于泰山，稳定压倒一切。研发过程的质量关注点（不积跬步无以至千里。） clean code是质量保证的一个重要环节，无规矩不成方圆。
what：CR什么，CR推动，CR目标。
how：check list，时机，方式，权衡。
不同视角聊CR
反方：
形式主义
又不是不能用
增加工作量
浪费时间
不符合艺术家特质(影响思维发展)。
正方：
质量经济学：是成本还是收益
1）效率：短期虽然需要更多的经历统一风格，但是长期效率得到了提升。
2）质量：避免一些不规范导致的一些低级错误，或者配合错误。
3）成本：铁打的营盘(项目)，流水的兵(程序员)，统一规范便于维护和交接。
"辣鸡"代码和高质量代码花费的时间是一样的，甚至更多。
4）成长：增加可读性，降低学习成本和交流成本，最大程度享受代码审查带来的好处，
延长项目的生命周期。
制定合适自己的代码规范

1）没有银弹，没有四海之内皆准的规范。
2）制定适合自己的代码规范。
3）明确公司当前的发展阶段对规范的影响，要求，寻求速度与规范的平衡。
4）当前的技术债务，如何偿还，与规范落地的节奏，与平衡。
5）员工的现状，经验不同，工作年限不同，认知不同，与当前的发展速度，制定适合当前的代码规范。
6）不断演进，迭代。一边落地规范，一边用规范影响团队成员，达成团队一致的认知。
规范落地
速度：
在多长时间内达到一个什么样的里程牌(将这个规范在团队落地，达成一致，甚至是推广到部门或者公司)
幅度：
规范的方位很广，从项目，架构，架构整洁，设计，从SOLID，KISS，DRY，YAGIN等原则，模块，类，方法，变量，等细节。
1）发展速度：速度妥协，让业务赢是首要目标。
2）技术债务：幅度妥协，避免规范过于激进而引入故障。
3）员工水平：双重妥协，成长需要时间和循序渐进。
4）公司文化：老板风格。
循环往复不断迭代：
发展速度上，逐步推进加快速度，推进提速，正向循环。
员工水平上，提高落地能力，提高速度与幅度。
公司的发展阶段对规范的影响(比较决定性关键的影响)
1）规范尽可能在早期就引入，从而产生长期的正向影响，成本低，技术债务少。
2）规范引入后，需要和团队(部门，公司)目标里程碑，发展节奏生产协调，快速迭代奔跑，逐步迭代。
3）业务压力，市场先机等背景下，适当妥协，职位业务赢，业务第一。
落地
项目诊断：
1）代码混乱，没有注释（增加一个字段，修改了27个类）逆向了解业务，从代码发现业务。扩展=copy。
2）依赖混乱，底层依赖，逐步fallback。依赖的不只是一个模块，是多个，甚至是一个项目全部依赖。
测试，无单测，无case。
3）人力，业务压力，质量要求增高。
混乱的代价：
1）破窗户理论，环境中的不良现象如果不治理，会诱导人们模仿，甚至变本加厉。
2）代码混乱会产生生产力的下将，恶性循环，逐步恶化否？
3）日积月累，重头再来一遍。推到重做，然后周而复始。
重写PK重构
两者权衡，如都不可取呢—>clean code

1）稳定性建设 ：发现问题，暴露问题，解决问题。
2）里程牌：试点推进，卡点，数据指标驱动，复盘。
3）核心模块，核心链路规范化(优先级)。
p3c，编程规约，异常处理，安全规约，工程结构，代码整洁，单元测试。cr&监督。
CR视角
研发视角：
1）信息交换，Review技术方案的设计，实现。预防意料之外的事情。
2）可读性，感官的统一。
3）共通进步成长，走的更远。（思路与习惯）
测试视角(air,first)：
1）接口测试：可以充分理解代码的设计与实现，发现代码中潜在的隐藏问题，(不仅是测试同学，也有利于他人发现自己代码的问题)。
2）研发和测试一致共同推动质量，稳定性建设。
3）有利于和测试明确代码变更，影响范围，和(相关沟通)测试边界。
CR的姿势
（什么时候看，给谁看，怎么看，一行行看，一字不落…）参与者&仪式感
参与者：讲解员(开发)，QA，架构师，影响方。
仪式感：重视，背景，思路，方案(统一)。

1. 同步：CR讲解，当面会议。
   CR讲解者(开发者)：充分讲解思路，方案，编码思考。
   评审者：实时提问，讨论，建议。（初衷，目标，优缺点，改进）。分歧当场解决。二次review。
   优点：同步沟通，效果佳。
   缺点：占用精力多，需要统一时间。
   建议：stg发布前(开发上线前)，关键性代码评审。
   适用：当前最优，大多数场景的团队，重要项目或者模块。
2. 异步：CR Review
   开发者：提交，需要在CL(commit log)中尽可能的完善思路与方案。
   评审者：抽空看，评论式的提出问题，意见建议。
   缺点：分歧成本上升，分歧需要单独讨论，或者反复的回复，完成时间不确定。
   优点：不需要全体集中时间精力，可用零碎时间，提高双方默契度。
   适用：普适性，跨地域合作模式，团队水平较高的团队，(代码写完越早越好，思路还是清晰的)可写完自测完就提交。
   要求：成员高自驱动。
3. 同步异步结合
4. CR粒度
   细小，但完整。
5. CR时机

1. 避免卡点，放大招。
2. 避免为了CR而CR，最好代码写完即可CR。
   CR思路
   
   CR目标
   目标(如)：clean code，提升质量，提升自我成长，保证进度，活得久。
   每一次CR也是一次迭代，每次需要做到底，循环往复，小而完整，逐步迭代。
   1）教育：成长
   2）保持规范：质量
   3）把关控制：质量，进度
   4）问题预防：质量保障
   有原则，有标准，有策略，清晰步骤，抓执行，数据说话。
   原则：
   1）不带入个人色彩，技术与事实说话。
   2）坚守团队代码规范，不断贡献自己的规范。
   3）尊重个人设计，也要尊重团队要求。

4. 意见与冲突。
   充分交流，加强沟通，保持积极改进心态，接受意见，自我提升，分歧有存在的客观性，
   冲突当场解决。
   标准：
   1）提高代码整体质量
   2）不过度追求完美，追求进度与质量的平衡
   3）如果做的更好，就分享出来，让作者知道可以锦上添花。
   策略：

• 事：
  业务高压线：不能触碰
  历史故障点：不在同一个地点跌倒
  必备检查项：CR list，care，哪些，剪枝
  变更分级：不同等级，不同对待策略，保证业务进度。
  内容分级：不同等级，不同对待策略，保证业务进度。
• 人：

1. 评审者
   胆大
   细心
   对事不对人
   追求好的结果
2. 被评审者
   虚心接受：心态积极，积极拖动，开发接纳。
   充分交流：发现问题，赞美。
   以人为本：性格，能力。
   持续更进：todo
   步骤：
   

数据驱动：

CkeckList建议：

小结：
定目标，追过程，拿结果。
为过程鼓掌，为结果买单。

总结：就是让业务赢。
参考书籍附录：《重构改善代码的既有设计》《阿里开发规约-嵩山版》《代码整洁之道》《google编程规范》