前言

之前，我看了腾讯发布的两篇有关代码规范以及 Code Review 相关的文章，作者是  林强 大佬。

里面提到了很多有关代码相关的思考，以及一些价值观的传递，从中我也学到了很多（算是大厂内部一瞥吧）。非常推荐没看过的同学看看鹅厂是如何做 CR 的。文中的 CR 也是对 go 的，所以我看起来比较亲切。故，在这里总结一下其中对我来说意义比较大的。

之前，我看了《重构》之后也写了一下读后感，所以相同的部分我就不在本文中列举了。

《鹅厂练习13年Coding后，我悟了》

  • 01 细节即是架构：在这里更多的体现在代码的组织结构和也是一种架构。
  • 02 代码和文档在一起：有两个好处，不容易丢失，可以同时被维护。
  • 05 全局变量的危害并不仅仅是造成了耦合，在大项目中，你完全不知道以后是否会有人去修改这个变量。
  • 07 可逆性原则：我的总结是，永远不要相信产品经理跟你说 ”这个以后不会改了，现在写死就好“，回头半夜加班的还是你。
  • 11 尽早崩溃：并不是说你遇到问题就 panic，也并不是说你不能写 recover，而是不能对于出现的错误去没有任何的处理（打印日志、上报、监控等）
  • 12 pkg 也就是一下工具的互相依赖会经常会导致很多问题，特别是一些最底层工具，字符串、文件操作等等
  • 17 缄默原则：我遇到很多人会说，如果我不打这个日志怕到时候出现问题的时候不知道问题的原因。是的，打日志其实是门学问。
    • 正常 case 最多只有 debug 基本的日志，且你自己要清楚线上一定不会有的
    • 保证你的代码逻辑是非对即错，那么只有出现问题，你知道不对那么一定就不对
    • go 的问题在于通常出现 error 的时候没有堆栈和上下文的信息，所以一定一定要包装好你的错误

《腾讯工作13年之所思所想，那些优秀程序员的共性特征》

  • 01 偏执：对于 CR 来说，是的。代码怎么写大家有大家的方式，但为了维护势必要统一风格，而偏执在其中往往会让整个过程更简单。总结来说就是：”要么你说服大家你这么写的理由，要么你改“
  • 02 控制软件的熵是软件工程的重要任务之一：这里我更喜欢他在截图里面说的，这是从代码的架构设计角度出发而做的思考与实践。
  • 07 写代码要有对于“美”的追求：这里让我知道了，原来我和鹅厂的代码问题如出一辙😂 每一块砖头都被精心设计，才能构建一个漂亮的项目！
  • 11 所有细节都应该被显式处理 这个就是前面一篇提到的 尽早崩溃的补充，我叫做 “吞 error”
  • 12 合理注释一些并不“通俗”的逻辑和数值，说明一下这并不魔法数字，而是一个可以被推敲的默认值
  • 18-19 既然你准备输出日志了，那么就一定也保证当你看到这个日志的时候能知道出现了什么问题，并且能定位到出现问题的数据
  • 25 shadow error 在 go 里面很容易被忽略，处理一定要谨慎

总结

看完之后，一方面给了我信心，鹅厂 CRUD 也这样写的；一方面给了暴击，林强 大佬 Review 可真是针针见血啊。