• 代码质量检查


    Review 流程

    写完代码后,发送 diff 给指定人 review。待给出意见后,修改代码,继续提交 diff,直到 review 通过。通过 review 的代码由审阅者自动或者手工 Merge 代码到指定分支。多人协作 review 时,第一位阅读者给出粗略意见,第二位看意见是否给的恰当,再补充其他意见。多人同时 review,也可将代码用投影仪打到大屏,共同 review 一段代码。

    这里需要思考几个问题:


    阅读代码的技巧

    如何阅读别人提交的代码?首先要了解这代码的上下文和需求,不能不负责的指点江山。要充分了解需求,才能考虑如何实现,然后才能审阅别人的代码。不能因为读不懂别人的代码就拒绝别人的代码。这事开源界常发生,但公司内部最好杜绝发生。大家都是同事,低头不见抬头见,没必要关系僵化。你是能炒别人鱿鱼还是你自己要离职呢?看不懂代码可能有三种:一种使用了混淆、一种提交者写的烂、一种审查者能力不足。

    混淆代码一般都是有特殊原因的,但不会是故意刁难审阅者。比如说机密的模块、需要隐藏秘钥或算法。这部分代码讲明白意思即可,一般也不需要 review。

    如果提交者写的太烂,一般都是 i, j, k 的命名导致。审阅者更应该读懂后,指出哪些地方需要改进:比如少写了注释,改个好名字等。写的烂并不会导致你读不懂,一般是你不愿意花时间去读。如果你说事不关己,没必要看烂的代码。这种心态也不适合进行 Code Review,只适合小作坊编程。不如谦虚谨慎、虚怀若谷。

    而最后一个原因:请先提高自身的编程能力!有许多算法精妙难懂,在自己编程水平不足的时候决不能以读不懂为由拒掉。

    当你有足够的编程能力时,review 代码时请遵照下面的流程:

    粗读(知道大概写了哪些内容)

    => 抽取重点(架构/类的定义/代码结构)

    => 细读代码(简化/重构)

    => 逻辑判断 (各分支)

    => 细节优化(资源释放,线程安全、算法效率)