写点什么

读《Software Engineering at Google》(09)

作者:术子米德
  • 2022 年 4 月 18 日
  • 本文字数:1052 字

    阅读完需:约 3 分钟

🤔☕️🤔☕️🤔

  • 读《Software Engineering at Google》(09)—— Code Review

  • 📖:@Google CR 的典型过程:写改动说明,自审到满意,公开评审,依建议修改,直到打上“LGTM(looks good to me)”标签,允许提交到代码仓。

    🤔:代码评审,其实吧,第一次接触到的时候,很困惑,更其实吧,到现在我依然很困惑。我写的代码,为啥要评审。因为我写得太难看?因为我写得有错误?因为我没有写验证用例?这些都是让我不舒服的因素。代码评审,能不能来点让我舒服的,顺滑的因素呢?直到关键字【作品】出现,直到意识到【代码就是我的作品】,而我找他人评审的目的,就是期望有第三方的眼睛,以超越我的视角和思路,以作品的要求去评审。既然别人帮助我打造作品,作为回报,我也要主动去帮助别人打造作品。那怎么样的代码,在我眼里是作品,在大家眼里是作品?这就产生新的歧义。作品是我自己认可的,还是别人认可的呢?这就有点像价格,到底是我开的价格,还是别人开的价格,才是最值的市场价格呢?对。作品前面加上市场,【市场作品】是怎么定义的?拿到市场的作品,首先自己要认可,达到自己认为可拿出去的水准线,其次市场认可,达到市场准入的水准线。放到实际场景里,所谓市场,就是团队或部门的代码评审规范,所谓自己认可,就是在规范之外,自己积累起来的持续演进中的最佳实践。现阶段的我,最佳实践聚焦在验证用例,即待评审的代码,对应哪些验证用例,聚焦这些用例,可以看出实现是否对应设计,哪些方面和哪些场景已经被验证,即待评审的实现代码,通过验证用例,就能够准确反映出很多信息。

  • 📖:@Google CRx3A = 某工程师(正确可理解)+ 代码所有者(认可性)+ 语言专家(可读性)。

    🤔:评审代码时,要关注可读性,这个显而易见。不过,把这个视角独立出来,专门由语言专家来评审,让我感到意外。再往下读发现,我直觉中所谓的可读性,倾向性认为外行也容易读懂,可是谷歌是要对可读性进行训练,不折不扣让我观念受冲击。细想起来,让外行读懂代码,称之为可读性,反而像个笑话。如果可读性是针对某门编程语言,经过专门训练,可读性的关注点落在编程语言和实际业务的最佳表达性,这样的可读性更具有实践和反思后的理性感。

  • 📖:能够用工具辅助评审,那就想办法编程自动化。

    🤔:需要人重复干的事情,就要想办法工具化和自动化。软件开发的产品,都在为各行各业赋能信息化和自动化,结果软件开发却还在手动泥潭里,愣是把自己整成所谓的码农。必须给自己当头棒喝,首先要革命自己开发工具的自动化,包括代码评审工具的自动化。

    —— By 术子米德 @2022.04.17

发布于: 刚刚阅读数: 2
用户头像

术子米德

关注

遇见每天的自己,莫忘初心,莫丢念头 2020.03.05 加入

喜欢有的没的,喜欢自言自语式笔记

评论

发布
暂无评论
读《Software Engineering at Google》(09)_架构师成长笔记_术子米德_InfoQ写作平台