2018
Apr
19




软体工程师开发一个功能后,常常会再被其它工程师数落,不管是能力多强的工程师写的程式,还是会被后面接手的人骂,其中很大的原因就是不同的想法,与各人知识能力不同,我们如何靠 Code Review 来解决这种问题呢。

Code Review 就是请其它工程师大家一起评论自已写的程式,把程式码公开让别人来检查 / 优化 / 补强,评论的内容会因各人专长与想法的不同,而产生很多争议,例如安全性专家会龟毛的要求修补任何有可能的小小漏洞,效能专家会尽可能的想提升程式 Performance。

透过 Code Review 可以让不同专长的工程师,一起评论一段程式码,并提出自已的看法,每个人可以从中学习到各种不同知识,渐渐的拉近每个人的能力与想法,一开始实作 Code Review 会花大量的时间,每个人都会用自已喜欢角度来看程式,当两个人的意见有冲突的时候,就会出现笔战,试图挑战对方的底线,但只要持之以恒,团队成员的默契将越来越好,最后就能把每个人的能力与想法一起提高拉平,

Code Review 最怕是那种不下任何评论,但是心中满满抱怨不配合的人,这种人无法接受其它人的意见,又不愿意跟别人沟通,每次写程式都用自已的习惯,面对别人的评论总是讲一点就修一点,没完没了,不思进步,如果团队内有这种人会严重影响 Code Review 的进行。

提升团队整体能力与拉近想法。

良好的 Code Review

要做到良好的 Code Review 并不是这么简单的,大部分的人都是心胸狭窄、度量小,尤其是男性生物,本能就是要竞争,打败身边的所有人,要让工程师接受别人的评论,承认自已写的程式不好是很难的一件事,所以 Code Review 的时候,不要让对方感受到他的程式不好。

  • 看到程式有不正确的地方时,不要直接说对方写错了,改用间接 / 询问的方式来提醒比较不伤人,例如 Code Review c 语言,发现对方忘了 initialize memory,不要直接写 "你忘了 initialize memory.",而改用 "我找不到这个变数在哪里 initialize memory? "。
  • 不要强迫作者一定要修完所有的 Comment 才 Merge 程式,有些不影响系统的 Comment 可以下一次 PR 再一起修即可,这样也能够加快 Code Review 的过程。
  • 给评论时不要攻击对方。
  • 公司内可以订定程式准则,减少 Review 的争议。
  • 下评论时内容要清楚,明确,不要顺便打几个字,这样会给人不尊重的感觉,而且会造成对方误解你的意思,拉长 Review 过程。
  • 因材施教,资深的工程师写 Comment 时,内容必须是对方能力所能了解的,或是提供线上文件当参考,顺便让新人有自我学习的机会。
  • 开一个新的 Pull Request 时,要尽可能的把为什么要改这段程式的原因与方法,写在 comments ,让 Review 者可以更快速的了解程式,以及了解你的想法,就算是很基本的知识,建议也要写出来,除非你很确定 Review 者很强,自已看得懂。
  • 重覆的问题只要写一次就好了,下评论的时候再注明请对方一并修改所有类似的问题,评论数太多会让其它 Review 者觉得程式的问题很多,观感不好,也会对作者心理有不好的影响。
  • 资深工程师要能虚心接受资浅工程师写的评论,用专业的态度来看评论。
  • 当 Review 出现两种意见,各有利弊的时候,应使用客观的角度,用理论与数据来决定采用哪个方案,拿不出数据时,我个人建议采用曾经发生过的案例。

回應 (Leave a comment)