Day 21 - Code Review

前言

进入倒数十天了，这一路走来也是不容易啊((汗

剩下来的十篇，我想要试着把焦点转移，不再是那麽「硬」拼命 coding 学习，而是试着从一些「非 coding」的事情中学习，预计可能会是从心态、观念、工具面着手。

虽说不会有那麽多硬知识与实战，但我认为，要写出「更好」的程序，这些东西其实也不可或缺。

今天，让我们来聊聊 Code Review！

Code Review 是什麽？

简单来说，就是团队成员每当有程序修改，可以先送出 pull request 或 merge request，经过几个人看过，改了哪些地方？有没有不该 commit 的东西？写法是否恰当等。

可能有人会直觉认为，这感觉就像在「检查」其他人的 code，是不是要抓 bug 啊？

但事实上是，我们不是人体编译器，没办法用肉眼扫过就知道哪里会出 bug，尤其是 Javascript 这样的弱型别语言，真的是难上加难，若真可以用看的找到 bug，那也算是功力深厚或者 bug 太明显。

蛤那不抓 bug 我到底要看什麽？

Code Review 要看什麽？

以我自己 review 的经验，以及我被 review 的经验，我会浓缩成这三点：

• 目的明确性
• 程序码合理性
• 复杂逻辑连动性

目的明确性

通常 PM 或 QA 都会用 Jira、Asana、Redmine 之类的专案管理工具，管理每一个 issue 或者 new feature，统称为 ticket。

而这张 ticket 上面就会明确写下，这次修改的范围应该到哪里。

因此，code review 应该先看的是，这张 ticket 标示的范围、目的，是否跟程序修改吻合，有没有改到范围外，不然很容易看到 QA 跟 RD 在那边吵架：

QA: 为什麽 ticket 上面只有写要改 A，但是 B 却坏掉了？
RD: 啊就 B 跟 A 很相关嘛! 不趁这次改我下次一定会忘记啊! 到时候你不是又要来找我!?
QA: 那你要先跟我讲啊!
RD: 唉唷什麽都要讲太麻烦了啦~

没错，就像上面的 Q 先生与 R 先生争吵的，其实 RD 把相关的 code 一起修改是正确有效率的，但要嘛拆第二张 ticket 来处理，要嘛告诉 QA，要嘛在任何地方标注一下，如果只是自己默默改了，那麽真的是只能 #相信 #自信 #祈祷 来说服自己没事了。

程序码合理性

注意，这里是写「合理」，也就是这个「修改」合乎这个「目的」，就这样而已。

有些功力比较深厚的，可以一眼看穿这段 code 有 bug，或者抓出比较没效率的程序码，遇到这种 reviewer 真的是上辈子有烧好香，因为被工程师挡下来，绝对比被 QA、PM 甚至客户给抓到，还要好上千百倍!

但不是大家都那麽敏锐，因此最低的要求是合理，而不是「没有 bug」，只要这次修改是针对问题点，有改到重点就可以了。

复杂逻辑连动性

程序愈写愈大，总是会有一两个地方，可能是一个模组、一个页面，里面的程序逻辑特别复杂，还牵涉到许多相关的程序。

由於程序不是只有自己在写，每个人各有自己熟悉擅长的部份，有人熟悉登入逻辑，有人熟悉交易模组，有人熟悉资安，但没有人能够全部掌握。

因此当有人修改到一个这麽重要的位置时，牵一发动全身，务必要请「全身」来好好 review 一下这个「一发」，请所有会被这次修改影响的同事都看过，确定每个环节都有被照顾到。

Code Review 有哪些好处：

• 团队一致性
• 观摩学习
• 观察团队成员的习惯(?)

团队一致性

很多时候其实我开发了一个新的元件，可以很有效处理需求，但团队成员不知道，或者听过但忘了，往往就继续用旧的元件，导致同样一个功能有许多人实作过，耗费每个人的时间精力，未来要 refactor 还要四处蒐集「失落的程序码」。

这时候 code review 能发挥团队共享的特性，也就是让资讯在整个团队中畅通对等，不会每个人都在自己造轮子(DRY)。提醒使用新的元件、规范甚至 coding style，都能够让整体沟通更有效，程序也更乾净一致。

观摩学习

code review 是一件很有趣的事情，虽然有些人会困扰着：

「蛤~我写自己的 code 都忙不过来了，还要看别人的，哪来那麽多时间？」

但我们可以试着跳脱这种从「工作」出发的视角，而改用一种「观摩」的视角。

就像学习做菜一样，做菜其实是一种创作，荷包蛋可以有一百种作法，你有自己煎荷包蛋的方式，但也可以去观摩其他人，他们是怎麽煎荷包蛋的？妈妈做的荷包蛋特别好吃，他的火侯、调味、顺序是怎麽安排的？

Coding 也是一种创作，是的，不然为什麽叫做程序「设计」呢？那如果是创作，就意味着每个人写出来的，肯定不尽相同，即便目的、功能是一样的，我们仍然可以从「观摩」的过程中，思考很多平常自己不会发现的事情：

• 他为什麽要用 Set 来储存资料？用 Array 不行吗？
• 他为什麽先做 A 再做 B？有什麽好处吗？
• 他为什麽把一个功能拆成多个 function？不拆不行吗？

当我们 code review 跳脱「为了工作」的视角，而是试着站在一个「为了观摩」的视角，就有机会可以在其他人的程序码中，发现自己没想过的新世界。

观察团队成员的习惯

这点则是比较偏向团队文化的部分，前面有说到，coding 也是一种创作，所以看别人的 code 就像在美术课看隔壁的同学画出来的画作一样，往往可以看出一些属於个人的特色。

比如有些人是很严谨的，修改变数、API 的时候，除了程序码的部分，连文件、注解都会记得一起修改，一次到位从不罗嗦。

而有些人是很奔放的，有写过的函式直接 copy 过来，注解也维持原汁原味，劈哩趴啦写下来一大串，但也因此每次交付都非常迅速。

有些人则是很为团队成员着想的，commit 讯息写好写满，注解重点摘要，TODO、FIXME 该有的绝对有，不只下一个接手的人可以很快进入状况，连帮他 code review 的人都可以很清楚知道意图。

程序团队其实也像篮球队一样，重点是放在赢球，所以每个人要尽可能站在擅长的位置上，发挥每个人的专长，才能够让团队利益最大化，那当然第一步就是要清楚团队成员的习惯罗！

结语

虽然花时间，但是 code review 无疑是快速学习，以及帮助团队成长的一条道路，而且现在花时间，总比以後帮团队成员收烂摊子，或者踩到 bug 痛不欲生好吧？搞不好最後其实是省时间呢！

你们公司有 code review 的制度吗？如果没有，你可以成为第一个！

仔细端详着
画里绚烂的风采
寂静地
写下了生命的注解

参考资料

Google 程序码审查指南