CategoryResourceRepost/极客时间专栏/设计模式之美/开源与项目实战:开源实战/80 | 开源实战二(下):从Unix开源开发学习应对大型复杂项目开发.md
louzefeng d3828a7aee mod
2024-07-11 05:50:32 +00:00

100 lines
13 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<audio id="audio" title="80 | 开源实战二从Unix开源开发学习应对大型复杂项目开发" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/aa/03/aadd7bc2c8b42b5390ecb5820fbd6503.mp3"></audio>
上两节课我们分别从代码编写、研发管理的角度学习了如何应对大型复杂软件开发。在研发管理这一部分我们又讲到比较重要的几点它们分别是编码规范、单元测试、持续重构和Code Review。其中前三点在专栏的理论部分都有比较详细的讲解而唯独Code Review我们还没有讲过所以今天我就借机会和你补充一下这一部分的内容。
很多年前我跟一个有十几年研发经验的某一线大厂的技术专家聊天聊天中我提起了Code Review他便对Code Review一顿否定。他说Code Review比较浪费时间往往会虎头蛇尾不可能在企业中很好地落地执行。当我又提起Code Review在Google执行得很好并且是已经习以为常的开发流程的时候他竟然说这绝对不可能。
一个技术不错可以玩转各种架构、框架、中间件的资深IT从业者居然对Code Review有如此的偏见这到底是哪里出了问题呢我觉得问题主要还是出自认知上。
所以今天我并不打算讲关于如何做Code Review的方法论我更希望充当一个Code Review布道师的角色讲一讲为什么要进行Code ReviewCode Review的价值在哪里让你重视、认可Code Review。因为我觉得只要从认知上接受了Code Review对于高智商的IT人群来说搞清楚如何做Code Review并不是件难事。而且Google也开源了它自己的Code Review最佳实践网上很容易搜到你完全可以对照着来做。
话不多说,让我们正式开始今天的内容吧!
## 我为什么如此强调Code Review
Code Review中文叫代码审查。据我了解在国内绝大部分的互联网企业里面很少有将Code Review执行得很好的这其中包括BAT这些大厂。特别是在一些需求变动大、项目工期紧的业务开发部门就更不可能有Code Review流程了。代码写完之后随手就提交上去然后丢给测试狠命测发现bug再修改。
相反一些外企非常重视Code Review特别是FLAG这些大厂Code Review落地执行得非常好。在Google工作的几年里我也切实体会到了Code Review的好处。这里我就结合我自身的真实感受讲一讲Code Review的价值试着“说服”一下你。
### 1.Code Review践行“三人行必有我师”
有时候你可能会觉得团队中的资深员工或者技术leader的技术比较牛写的代码很好他们的代码就不需要Review了我们重点Review资历浅的员工的代码就可以了。实际上这种认识是不对的。
我们都知道Google工程师的平均研发水平都很高但即便如此我们发现不管谁提交的代码包括Jeff Dean的只要需要Review都会收到很多comments修改意见。中国有句老话“三人行必有我师”我觉得用在这里非常合适。即便自己觉得写得已经很好的代码只要经过不停地推敲都有持续改进的空间。
所以永远不要觉得自己很厉害写的代码就不需要别人Review了永远不要觉得自己水平很一般就没有资格给别人Review了更不要觉得技术大牛让你Review代码只是缺少你的一个“approve”随便看看就可以。
### 2.Code Review能摒弃“个人英雄主义”
在一个成熟的公司里,所有的架构设计、实现,都应该是一个团队的产出。尽管这个过程可能会由某个人来主导,但应该是整个团队共同智慧的结晶。
如果一个人默默地写代码提交不经过团队的Review这样的代码蕴含的是一个人的智慧。代码的质量完全依赖于这个人的技术水平。这就会导致代码质量参差不齐。如果经过团队多人Review、打磨代码蕴含的是整个团队的智慧可以保证代码按照团队中的最高水准输出。
### 3.Code Review能有效提高代码可读性
前面我们反复强调在大部分情况下代码的可读性比任何其他方面比如扩展性等都重要。可读性好代表后期维护成本低线上bug容易排查新人容易熟悉代码老人离职时代码容易接手。而且可读性好也说明代码足够简单出错可能性小、bug少。
不过自己看自己写的代码总是会觉得很易读但换另外一个人来读你的代码他可能就不这么认为了。毕竟自己写的代码其中涉及的业务、技术自己很熟悉别人不一定会熟悉。既然自己对可读性的判断很容易出现错觉那Code Review就是一种考察代码可读性的很好手段。如果代码审查者很费劲才能看懂你写的代码那就说明代码的可读性有待提高了。
还有不知道你有没有这样的感受写代码的时候时间一长改动的文件一多就感觉晕乎乎的脑子不清醒逻辑不清晰有句话讲“旁观者清当局者迷”说的就是这个意思。Code Review能有效地解决“当局者迷”的问题。在正式开始Code Review之前当我们将代码提交到Review BoardCode Review的工具界面之后所有的代码改动都放到了一块看起来一目了然、清晰可见。这个时候还没有等其他同事Review我们自己就能发现很多问题。
### 4.Code Review是技术传帮带的有效途径
良好的团队需要技术和业务的“传帮带”那如何来做“传帮带”呢当然业务上面我们可能通过文档或口口相传的方式那技术呢如何培养初级工程师的技术能力呢Code Review就是一种很好的途径。每次Code Review都是一次真实案例的讲解。通过Code Review在实践中将技术传递给初级工程师比让他们自己学习、自己摸索来得更高效
### 5.Code Review保证代码不止一个人熟悉
如果一段代码只有一个人熟悉如果这个同事休假了或离职了代码交接起来就比较费劲。有时候我们单纯只看代码还看不大懂又要跟PM、业务团队、或者其他技术团队再重复来一轮沟通搞的其他团队的人都很烦。而Code Review能保证任何代码同时都至少有两个同事熟悉互为备份有备无患除非两个同事同时都离职……
### 6.Code Review能打造良好的技术氛围
提交代码Review的人希望自己写的代码足够优秀毕竟被同事Review出很多问题是件很丢人的事情。而做Code review的人也希望自己尽可能地提出有建设性意见展示自己的能力。所以Code Review还能增进技术交流活跃技术氛围培养大家的极客精神以及对代码质量的追求。
一个良好的技术氛围能让团队有很强的自驱力。不用技术leader反复强调代码质量有多重要团队中的成员就会自己主动去关注代码质量的问题。这比制定各种规章制度、天天督促执行要更加有效。实际上我多说一句好的技术氛围也能降低团队的离职率。
### 7.Code Review是一种技术沟通方式
Talk is cheapshow me the code。怎么“show”通过Code Review工具来“show”这样也方便别人反馈意见。特别是对于跨不同办公室、跨时区的沟通Code Review是一种很好的沟通方式。我今天白天写的代码明天来上班的时候跨时区的同事已经帮我Review好了我就可以改改提交继续写新的代码了。这样的协作效率会很高。
### 8.Code Review能提高团队的自律性
在开发过程中难免会有人不自律存在侥幸心理反正我写的代码也没人看随便写写就提交了。Code Review相当于一次代码直播曝光dirty code有一定的威慑力。这样大家就不敢随便应付一下就提交代码了。
## 如何在团队中落地执行Code Review
刚刚讲了这么多Code Review的好处我觉得大部分你应该都能认可但我猜你可能会说Google之所以能很好地执行Code Review一方面是因为有经验的传承起步阶段已经过去了另一方面是本身员工技术素质、水平就很高那在一个技术水平没那么强的团队在起步阶段或项目工期很紧的情况下如何落地执行Code Review呢
接下来我就很多人关于Code Review的一些疑惑谈谈我自己的看法。
**有人认为Code Review流程太长太浪费时间特别是工期紧的时候今天改的代码明天就要上如果要等同事Review同事有可能没时间这样就来不及。这个时候该怎么办呢**
我所经历的项目还没有一个因为工期紧导致没有时间Code Review的。工期都是人排的稍微排松点就行了啊。我觉得关键还是在于整个公司对Code Review的接受程度。而且Code Review熟练之后并不需要花费太长的时间。尽管开始做Code Review的时候你可能因为不熟练需要有一个checklist对照着来做。起步阶段可能会比较耗时。但当你熟练之后Code Review就像键盘盲打一样你已经忘记了哪个手指按的是哪个键了扫一遍代码就能揪出绝大部分问题。
**有人认为业务一直在变今天写的代码明天可能就要再改代码可能不会长期维护写得太好也没用。这种情况下是不是就不需要Code Review了呢**
这种现象在游戏开发、一些早期的创业公司或者项目验证阶段比较常见。项目讲求短平快先验证产品再优化技术。如果确实面对的还只是生存问题代码质量确实不是首要的特殊情况下不做Code Review是支持的
有人说团队成员技术水平不高过往也没有Code Review的经验不知道Review什么也Review不出什么。自己代码都没写明白不知道什么样的代码是好的什么样的代码是差的更不要说Review别人的代码了。在Code Review的时候团队成员大眼瞪小眼只能Review点语法形式大于效果。这种情况该怎么办
这种情况也挺常见。不过没关系团队的技术水平都是可以培养的。我们可以先让资深同事、技术好的同事或技术leader来Review其他所有人的代码。Review的过程本身就是一种“传帮带”的过程。慢慢地整个团队就知道该如何Review了。虽然这可能会有一个相当长的过程但如果真的想在团队中执行Code Review这不失为一种“曲线救国”的方法。
**还有人说刚开始Code Review的时候大家都还挺认真但时间长了大家觉得这事跟KPI无关而且我还要看别人的代码理解别人写的代码的业务多浪费时间啊。慢慢地Code Review就变得流于形式了。有人提交了代码随便抓个人Review。Review的人也不认真随便扫一眼就点“approve”。这种情况该如何应对**
我的对策是这样的。首先要明确的告诉Code Review的重要性要严格执行让大家不要懈怠适当的时候可以“杀鸡儆猴”。其次可以像Google一样将Code Review间接地跟KPI、升职等联系在一块高级工程师有义务做Code Review就像有义务做技术面试一样。再次想办法活跃团队的技术氛围把Code Review作为一种展示自己技术的机会带动起大家对Code Review的积极性提高大家对Code Review的认同感。
最后我再多说几句。Google的Code Review是做得很好的可以说是谷歌保持代码高质量最有效的手段之一了。Google的Code Review非常严格多一个空行多一个空格注释有拼错的单词变量命名得不够好都会被指出来要求修改。之所以如此吹毛求疵并非矫枉过正而是要给大家传递一个信息代码质量非常重要一点都不能马虎。
## 重点回顾
好了,今天的内容到此就讲完了。我们一块来总结回顾一下,你需要重点掌握的内容。
今天我们主要讲了为什么要做Code ReviewCode Review的价值在哪里。我的总结如下Code Review践行“三人行必有我师”、能摒弃“个人英雄主义”、能有效提高代码可读性、是技术传帮带的有效途径、能保证代码不止一个人熟悉、能打造良好的技术氛围、是一种技术沟通方式、能提高团队的自律性。
除此之外我还对Code Review在落地执行过程中的一些问题做了简单的答疑。我这里就不再重复罗列了。如果你在Code Review过程中遇到同样的问题希望我的建议对你有所帮助。
## 课堂讨论
对是否应该做Code Review你有什么看法呢你所在的公司是否有严格的Code Review呢在Code Review的过程中你又遇到了哪些问题
欢迎留言和我分享你的想法。如果有收获,也欢迎你把这篇文章分享给你的朋友。