代码走查
代码走查复盘
代码走查的目的是什么？
首要目的自然是保证代码质量
从参与者角度分为两个目的：
代码Show；
代码指出问题或者更好的方案等，提升编码能力
聚焦在哪里？
第一层级：
* 有没有实现功能，业务逻辑的正确性，有没有实现功能（首要），如果有大量的用例作为保证，其实这些都不是问题
第二层级：
1. 编码规范
2. 算法范畴 or 业务逻辑本身
3. 编码思想
团队走查代码的痛点在哪？
1、团队代码提交代码过多，在压缩走查时间的时候，团队部分代码无法排上档期
2、代码走查的人员构成
新员工
语言层面不熟悉，只能CC层面上的
老员工
功能没参与，对详细方案不太熟悉，容易成为局外人
没有统一的标准，有些问题如何提
走查前期表述太过于粗略
部分模块不熟悉，而走查代码又基于现有模块逻辑
3、代码走查遇到争议的时候如何快速化解（代码没走查几段，讨论了半天），讨论发散或者纠缠在某个具体细节中，导致时间把控不好。
4、评审的同事对代码不熟悉，发现不了问题
5、提问题的总是那几个人，其他人都是围观群众
6、任务紧的时候走查可能受影响
其他的思考？
1、怎样的代码算过
2、复杂的逻辑用ft守护，特别的算法
3、代码评分
4、代码走查各自的收益
5、走查的代码一般都是编码者权衡利弊之后
1、走查代码主讲人
代码走查可以理解为讲故事，作为讲故事的人，要考虑如何让听众听懂你故事。
1、交代背景，讲你设计思路
如何表述设计思路，要考虑如下：
1.1、 方案评审
方案评审这一过程做的怎么样，或者方案是否比较细
1.2、 对代码进行分类
代码量的多少
代码是否比较集中
代码是否比较分散
代码是修改现有功能
代码是否一个新的模块
1.3、 走查代码的人
对涉及的模块是否熟悉
是否参与了这个方案的讨论
是否参与这个功能开发
一些技能的掌握情况
考虑这些之后，选择粒度粗的还是细的表述，来比较直观的表述设计思路。
口头上表述可能比较模糊，不够直观，可以结合图：流程图，UML图等
2、走查代码方式
magiceye和其他网元对比有不同的业务场景，例如：前端呈现配置等。
1. 涉及前端
简单的配置，或者前端的就能表述后端复杂的逻辑，这种功能相对比较容易走查，大家很容易理解思路
2. 业务逻辑不涉及前端，比较内聚的
这一种比较复杂，最好慢一点。最好讲讲如何建模的。
3. 偏向于流程的
可以快速过一下
4. 一个完整的功能
应该从设计层面来讲解
总之，关注如下几个方面：
* 有没有实现功能
* 编码规范
* 算法范畴 or 业务逻辑本身
* 编码思想
3、增加互动环节(提问)
让走查代码的人有机会表达自己想法 ;对自己走查效果的检验，提高参与度，相互督促。
4、由参与者对上述环节进行评定，结合之前的代码打分措施2020-08-07 *001 需求代码梳理评分活动
2、走查代码参与人
大家的代码风格相似，走查代码会相当轻松，错误有比较少， 走查代码的效率会比较高，发现因为粗心或者其他原因导致的问题。
走查代码前
走查代码的人平时的自我修行
走查代码中
参加走查提出问题（依据如下）
* 有没有实现功能（易用性角度）
* 编码规范：建立团队的编码规范
* 算法范畴 or 业务逻辑本身
* 编码思想
* 其他 （并发和锁、 性能问题、等）
当自己跟不上的时候，要提出疑问
@ 走查代码主讲人 的互动，来校验参与走查代码的人是否理解和跟上（上一条措施）， 形成了相互督促，避免走查代码形式化
走查完代码，看看收获是什么，结合之前的代码打分措施2020-08-07 *001 需求代码梳理评分活动
