美文网首页
80 - 如何应对大型复杂项目(三)

80 - 如何应对大型复杂项目(三)

作者: 舍是境界 | 来源:发表于2021-10-19 06:32 被阅读0次

前面两篇文章,我们分别从代码编写、研发管理的角度,学习了如何应对大型复杂软件开发。在研发管理这一部分,讲到比较重要的几点,它们分别是编码规范、单元测试、持续重构和 Code Review

本文,会讲一讲为什么要进行 Code Review,Code Review 的价值在哪里,让你重视、认可 Code Review。

为什么如此强调 Code Review?

  • Code Review 中文叫代码审查。在国内绝大部分的互联网企业里面,很少有将 Code Review 执行得很好的,这其中包括 BAT 这些大厂。特别是在一些需求变动大、项目工期紧的业务开发部门,就更不可能有 Code Review 流程了。代码写完之后随手就提交上去,然后丢给测试狠命测,发现 bug 再修改。
  • 相反,一些外企非常重视 Code Review,特别是 FLAG 这些大厂,Code Review 落地执行得非常好,接下来讲一讲 Code Review 的价值:
  1. Code Review 践行“三人行必有我师”
  • 有时候你可能会觉得,团队中的资深员工或者技术 leader 的技术比较牛,写的代码很好,他们的代码就不需要 Review 了,我们重点 Review 资历浅的员工的代码就可以了。实际上,这种认识是不对的。
  • 我们都知道,Google 工程师的平均研发水平都很高,但即便如此,我们发现,不管谁提交的代码,包括 Jeff Dean 的,只要需要 Review,都会收到很多 comments(修改意见)。中国有句老话,“三人行必有我师”,我觉得用在这里非常合适。即便自己觉得写得已经很好的代码,只要经过不停地推敲,都有持续改进的空间。
  • 所以,永远不要觉得自己很厉害,写的代码就不需要别人 Review 了;永远不要觉得自己水平很一般,就没有资格给别人 Review 了;更不要觉得技术大牛让你 Review 代码只是缺少你的一个“approve”,随便看看就可以。
  1. Code Review 能摒弃“个人英雄主义”
  • 在一个成熟的公司里,所有的架构设计、实现,都应该是一个团队的产出。尽管这个过程可能会由某个人来主导,但应该是整个团队共同智慧的结晶。
  • 如果一个人默默地写代码提交,不经过团队的 Review,这样的代码蕴含的是一个人的智慧。代码的质量完全依赖于这个人的技术水平。这就会导致代码质量参差不齐。如果经过团队多人 Review、打磨,代码蕴含的是整个团队的智慧,可以保证代码按照团队中的最高水准输出。
  1. Code Review 能有效提高代码可读性
  • 在大部分情况下,代码的可读性比任何其他方面(比如扩展性等)都重要。可读性好,代表后期维护成本低,线上 bug 容易排查,新人容易熟悉代码,老人离职时代码容易接手。而且,可读性好,也说明代码足够简单,出错可能性小、bug 少。
  • 不过,自己看自己写的代码,总是会觉得很易读,但换另外一个人来读你的代码,他可能就不这么认为了。毕竟自己写的代码,其中涉及的业务、技术自己很熟悉,别人不一定会熟悉。既然自己对可读性的判断很容易出现错觉,那 Code Review 就是一种考察代码可读性的很好手段。如果代码审查者很费劲才能看懂你写的代码,那就说明代码的可读性有待提高了。
  • 还有,不知道你有没有这样的感受,写代码的时候,时间一长,改动的文件一多,就感觉晕乎乎的,脑子不清醒,逻辑不清晰?有句话讲,“旁观者清,当局者迷”,说的就是这个意思。Code Review 能有效地解决“当局者迷”的问题。在正式开始 Code Review 之前,当我们将代码提交到 Review Board(Code Review 的工具界面)之后,所有的代码改动都放到了一块,看起来一目了然、清晰可见。这个时候,还没有等其他同事 Review,我们自己就能发现很多问题。
  1. Code Review 是技术传帮带的有效途径
  • 良好的团队需要技术和业务的“传帮带”,那如何来做“传帮带”呢?当然,业务上面,我们可能通过文档或口口相传的方式,那技术呢?如何培养初级工程师的技术能力呢?Code Review 就是一种很好的途径。每次 Code Review 都是一次真实案例的讲解。通过 Code Review,在实践中将技术传递给初级工程师,比让他们自己学习、自己摸索来得更高效!
  1. Code Review 保证代码不止一个人熟悉
  • 如果一段代码只有一个人熟悉,如果这个同事休假了或离职了,代码交接起来就比较费劲。有时候,我们单纯只看代码还看不大懂,又要跟 PM、业务团队、或者其他技术团队,再重复来一轮沟通,搞的其他团队的人都很烦。而 Code Review 能保证任何代码同时都至少有两个同事熟悉,互为备份,有备无患,除非两个同事同时都离职……
  1. Code Review 能打造良好的技术氛围
  • 提交代码 Review 的人,希望自己写的代码足够优秀,毕竟被同事 Review 出很多问题,是件很丢人的事情。而做 Code review 的人,也希望自己尽可能地提出有建设性意见,展示自己的能力。所以,Code Review 还能增进技术交流,活跃技术氛围,培养大家的极客精神,以及对代码质量的追求。
  • 一个良好的技术氛围,能让团队有很强的自驱力。不用技术 leader 反复强调代码质量有多重要,团队中的成员就会自己主动去关注代码质量的问题。这比制定各种规章制度、天天督促执行要更加有效。实际上,我多说一句,好的技术氛围也能降低团队的离职率。
  1. Code Review 是一种技术沟通方式
  • Talk is cheap,show me the code。怎么“show”,通过 Code Review 工具来“show”,这样也方便别人反馈意见。特别是对于跨不同办公室、跨时区的沟通,Code Review 是一种很好的沟通方式。我今天白天写的代码,明天来上班的时候,跨时区的同事已经帮我 Review 好了,我就可以改改提交,继续写新的代码了。这样的协作效率会很高。
  1. Code Review 能提高团队的自律性
  • 在开发过程中,难免会有人不自律,存在侥幸心理:反正我写的代码也没人看,随便写写就提交了。Code Review 相当于一次代码直播,曝光 dirty code,有一定的威慑力。这样大家就不敢随便应付一下就提交代码了。

如何在团队中落地执行 Code Review?

  • 有人认为,Code Review 流程太长,太浪费时间,特别是工期紧的时候,今天改的代码,明天就要上,如果要等同事 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 Review,Code Review 的价值在哪里。总结如下:Code Review 践行“三人行必有我师”、能摒弃“个人英雄主义”、能有效提高代码可读性、是技术传帮带的有效途径、能保证代码不止一个人熟悉、能打造良好的技术氛围、是一种技术沟通方式、能提高团队的自律性。
  • 同时还对 Code Review 在落地执行过程中的一些问题,做了简单的答疑

相关文章

  • 80 - 如何应对大型复杂项目(三)

    前面两篇文章,我们分别从代码编写、研发管理的角度,学习了如何应对大型复杂软件开发。在研发管理这一部分,讲到比较重要...

  • 78 - 如何应对大型复杂项目开发(一)

    软件开发的难度无外乎两点,一是技术难,意思是说,代码量不一定多,但要解决的问题比较难,需要用到一些比较深的技术解决...

  • 79 - 如何应对大型复杂项目开发(二)

    项目越复杂、代码量越多、参与开发人员越多、开发维护时间越长,我们就越是要重视代码质量。代码质量下降会导致项目研发困...

  • 浅谈PMO的定位和组建

    怎样快速组建PMO 很多大型企业都在做“+互联网”商务电子化转型,但转型的最大挑战就是要面对复杂项目管理。应对它的...

  • 如何工程化开发大型angular2项目(上篇)

    如何工程化开发大型angular2项目(上篇) 前请提要 目前前端项目越来越复杂,管理一个前端项目需要考虑的方面越...

  • 三层架构

    引入 mvc应对小型项目是没问题的,但是对于中型,或者中大型项目就会显得很困窘,因此这里引入三层架构。 有那三层那...

  • 大型复杂项目的管理

    与一般项目相比,大型复杂项目具有周期长,规模大,目标及团队成员构成复杂等特征。 过程计划 一般项目的计划,主要关注...

  • 软考信息系统项目管理师论沟通管理范文

    一般把周期长、规模大,或具有战略意义,涉及面广的项目称为大型项目,大型项目目标构成复杂,项目干系人众多,团队构成复...

  • C++开源项目汇总

    值得学习的C/C++语言开源项目 (1)ACE 庞大、复杂,适合大型项目。开源、免费,不依赖第三方库,支持跨平台。...

  • 优秀的C/C++框架和库整理,值得收藏

    (1)ACE 庞大、复杂,适合大型项目。开源、免费,不依赖第三方库,支持跨平台。 http://www.cs.wu...

网友评论

      本文标题:80 - 如何应对大型复杂项目(三)

      本文链接:https://www.haomeiwen.com/subject/nqdvoltx.html