读《Software Engineering at Google》（09）

🤔☕️🤔☕️🤔

• 读《Software Engineering at Google》（09）—— Code Review

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

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

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

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

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

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

    —— By 术子米德 @2022.04.17