浅谈利用Code Review来增加自己在组内的影响力和Visibility

写在前面：写这个帖子是想要抛砖引玉，大家交流探讨一些工作中Code Review相关的流程或者小技巧，欢迎指正和补充，我也会努力给好的回答加分

我先来吐槽一下自己刚入职时的毛病：
1. 看到一个Pull Request（PR）已经有别的Senior给了Approval，自己又没有那么多时间去仔细研究这个User Story到底是要做什么的，就默默点击右上角/左上角 离开这个PR，或者闭着眼睛也给一个Approval。
2. 看到一个自己感兴趣的PR，认认真真从头读到尾，心里无数草泥马奔腾，这写的到底什么鬼。发现别的Reviewer都没说什么，甚至已经给了Approval。手足无措，我到底是给修改建议呢？还是不给修改建议？这种时候往往会避重就轻，用极其婉转的语气和方式去引导队员改写，因为语气的问题收效甚微，很多时候会被忽略，大家直接就merge了。

以上两个方式会给整个team留下很多的长期隐患。比如说：
1. Team整体代码的可读性和维护性变得越来越差，每个新功能需要队员去重新整理已有代码的思路，或者就是逻辑越写越乱。
2. Team的整个文化就变成了，code review只是走个过场，我随便怎么搞，总归能过。同时还会建立起错误的自信心，
“吾之代码棒无敌，从来没人有建议。
你若发现有问题，那是你刻意贬低。”  
肯定还有很多别的伤害，欢迎大家补充

认真做Code Review的一些好处：
1. 增加自己对组里整体代码的熟悉度，新story不管以前做没做过的部分都会更加得心应手
2. team文化的培养，组员和老板都看得到这个变化是因我而起，后面你懂的
3. 互相学习的机会，我的review不一定对，队员原本坚信的也可能是歪理，不交流那就都深埋在心底一直错下去吧。
4. 大局观：对组里在做的每一个功能都更加了解，各种时间点，有些什么可能危险都因为知道的更多了而更加容易看到。可以更愉快的和Project Manager/Owner玩耍了。

以下是我针对自己/team的问题做的一些事情
1. 和老板1对1的时候，明确提出我们的代码质量问题越来越严重，给了具体例子。告诉他我有这样的一个想法，要更加激进地做review，为的是整个team，需要的是接下来3-6个月的时间里每个user story可能会花更长的时间来保证代码质量，习惯培养出来以后将是team文化的一部分，是否可行。
2. 得到老板的支持和肯定以后，在组内通过coffee talk和晨会（standup）培养舆论，“Norman 要开始疯狂code review了，刀剑无眼，我们为的是team健康向上发展，要是砍到你了千万别介意，砍太疼了你跟我说。”
3. 认真阅读每个code review，要是读不懂代码，那就是写得不好，温柔一刀告诉他要改，github上边直接做红叉“Request Change”。具体怎么给review大家可以去读Clean Code这本书
4. 刀要砍，小红花也要贴。 私聊和standup继续培养舆论。 “谢谢XXX耐心对待我的code review，改了好多稿，棒棒哒”。这点非常重要，让大多数同事非常乐于接受建议。
5. 鼓励同事砍我的code review “我上新PR啦，谁给我最多comments我就请他吃午饭/喝咖啡/送小红花”
6. 在和老板的1对1，和同事的日常交流中主动询问自己做code review这件事情的反馈（feedback），能否继续这么做

其中碰到的一些问题
1. 有红脖子队员非常不接受，觉得我挑刺。直接手一摊说，这个user story你来做。
解决方案： 虽然内心非常不爽，但是我们不可以把自己的智商降到同一个level去和他吵啊。做了单独的1对1，我要“真诚道歉伤了你的心，我以后给你的review不直接写PR上面了，我单独跟你说好在写。帮你脸上贴金，你是大佬，你去做架构好了，到时候让我们这些小弟帮你擦屁股，千万别放在心上啊，team没了你可不行。” 怎么说呢，不出一些矛盾你真的都不知道队友几斤几两，是什么样的人，心里到底是怎么想的。这种矛盾反而能让你知道队里哪些是做技术的，哪些是拼资历的。以后自己碰到技术问题的时候能更加有的放矢，找到对的人去问。

2. 有些紧急的功能要上线，Code review影响到timeline
解决方案： 和Project Manager/Owner 谈心，先确认这个timeline是不是非要不可，然后说明白risk，“一次两次可以，一直那样整个team就毁了，希望得到你的支持。”。


Disclaimer：具体做的事情里面还是有很多省略的，毕竟当team有问题的时候，code review不会是唯一的问题。我们的story in-take，story的完成度，dev和qa交接等等都有可以提高的地方，他们都会相互牵制作用。我想把我的分享集中在code review这件事本身，欢迎大家在下面展开讨论具体问题。

本文被选为02/19/2019全站置顶文章之一。
作者获得大米奖励。谢谢你的分享

好的讨论，也会有加分的。跟今日话题一样待遇

关于code review有几个问题，抛出来跟楼主和大家讨论。
1）关于花在code review的时间和产出比：本人所在组里senior居多，所以大部分时候给他们的都是一些不疼不痒的style啊，typo这类的comments. 而且对context 了解有限，就会导致要仔细review 一个PR 会花比较久的时间。长期看势必有好处，但短期不如优先完成自己本职工作产出高。这点如何均衡？

2）PR会阶段性的密集到来，在不了解context 如何选择性的reivew 的 PR？

严谨的Code Review肯定是很重要的，但希望借Code Review提高影响力则有点本末倒置了。

如果自身资历不高不是TL不是模块Owner的话，那么需要明确一点Code Review是服务性的工作而不是指导性管理性控制性的工作 —— 我见过一些人期望通过影响他人的代码以提升自己在项目上的话语权和权威性，但往往搬起石头砸自己的脚，技术/成果上被大佬碾压而且自己真正应该完成的工作也没做好。

my 2 cents
- CR贵在真诚，也就是不为了自己的visibility提不必要的request，也不为了避免得罪人就不提自己的concern。长期这样做你的cr才有分量。为visibility而review的review一般会很容易看出来，老实说非常annoying。
- 即使出发点是组里的codequality，多从别人的角度考虑一下。比如别人急着ship的时候，如果code没有大的问题，不要非得block人家。有些代码质量的改进可以另开一个task晚几天做。为什么这么改对ta将来的productivity有好处要讲清楚。这样你的意见才容易被接受。
- cr不见得都是负面意见，别人写的好的地方可以表示“写的真好，学习了”。还有“我做这个cr主要是学习一下这块codebase，我是小白讲的不一定对”，这种学习态度对同事要直接讲，也体现在cr里。比如加入同事讲的更有道理要承认自己想错了，感谢同事教了自己，

大家都不给comments  就一个人反复给大量的 “此处应有一空行”  “这个logging phrase的不够好”

所有人都知道他工作量不饱和了

好像放错了位置。。。有没有大佬帮忙放到 找工就业 的主题？我以为是“经验总结”来着

codereview 投入小 收效大

很好的经验总结。
进一步建议，要有stand on quality 的装逼觉悟，比如，要求多加复杂的test。一次在review同事的PR的时候，要求他增加一个closed course test来验证问题得到真正解决，但这个实验同事不知道咋做，然后我帮他设计实验，现场采集数据，回头一起分析汇报老板，这样将装逼进行到底，又不得罪同事，又给老板同事留下能干的印象。

经验交流，共同进步

normanwu1990 发表于 2019-2-17 03:09
好像放错了位置。。。有没有大佬帮忙放到 找工就业 的主题？我以为是“经验总结”来着

建议放到职场达人

bearjoe 发表于 2019-2-17 11:50
很好的经验总结。
进一步建议，要有stand on quality 的装逼觉悟，比如，要求多加复杂的test。一次在revie ...

code review就是马工组里的战场，不能干的不懂得都发不了声。

没理解错的话，技术权威是通过设计系统来实现的，不是挑剔别人的代码质量。同意CR是服务。

小K 发表于 2019/02/17 21:11:05
没理解错的话，技术权威是通过设计系统来实现的，不是挑剔别人的代码质量。同意CR是服务。

我非常同意各位大神的补充见解：不应该为了博关注而去做，而应该是服务的心态。
同时挑剔别人的代码质量可以是开始讨论思考设计系统的步骤之一。比如说通过私聊：“这一部分代码我不太明白，这里的设计思路是怎么考量的” 真正有实力的技术权威会很乐于来帮助我们成长。