27 | 特别放送：聊一聊代码审查

笔记 争议项 1 加班累死，代码审查脱慢进度。 2 代码审查做的事无聊。 （改改注释） 3 习惯如此。 价值观差距太大时，换团队。 合适的争论 理越辩越明。 1 个人提升最好途径。 2 团队关系建设，扩大双方影响力。 3 识别设计的缺陷，找到测试不易发现的问题。 4 设立质量标杆。性格习惯。 小技巧 量小 牛人 高于平均 新员工严格 适当委婉 过两遍。 思考题 个人小技巧 1 直接截图，贴上框架代码（为表达意图，往往删掉异常处理）或其它类似实现代码 2 个人习惯，我对一些违背开发原则的事，是和开发同学不断探讨的， 简单如 dry 好判断的，一定让开发把实现抽取出来。 srp dip 这些往往具体问题具体分析，毕竟不能创个变量就上工厂吧，场景是否适合，克制那颗过度封装的心，改为逐步迭代。 3 改完后，会引一些文章。（我一般选开发接受并修改后，一是此刻他心态更平和，二是刚折腾完，手热。这时候方便适当展开。

提出点个人的理解吧:记得池老师的专利第一季有篇文章<技术leader是否应该写代码>，其实目前技术经理大概有3成的时间在做Code Review。这块曾经和一些同行聊过：就像老师课中所说的，不做基本上上线可能就挂了。 目前Code Review应当有两张方式吧: 一种是强行做规则-违反规则就不让上线，提交不通过，这块可以用工具去实现； 一种就是人为的对比工具和审核，毕竟人写代码的人看不到自己的问题的，除非是公司或者部门这块的把关的，例如：sql代码基本上有DBA审核，DBA自己写的就只能自己反复测，自己挖了坑的话还是要自己填的，这个会做的异常谨慎。 个人觉得Code Review不仅仅重要，不做code review就是挖地雷;自己亲身经历过几次这种事情，这也是为何陈皓老师在他的专栏会去强调这块。好的code review会减少大量的不确定的坑：这个就像我们日常出门上班会确定门是否关好一样。 说个案例吧：从大公司到中小公司做DBA；CTO和我说数据库慢你优化一下，通过索引解决了出现的典型问题。生产上线前我说我把代码检查一遍，PM说我们的代码都测过没问题，我坚持检查一下-为此双休日没休息加班检查；周一我就扔出了不少所谓的慢且没问题的coding，CTO直接全部门发飙-先解决问题再上线。虽历史问题无力解决，不过常规问题减少了不少。 故而觉得不做code review基本山就是背着炸药包前进：什么时候炸了都不知道；只不过这块目前都是技术经理或者公司真正的专业人士在做而已。

开会，捋业务逻辑，大家挑刺儿，然后用阿里规范扫描命名注释等

业务和技术缺一不可，说的太对了。 之前一直都是做后端，对前端代码审查感觉有心无力。 只能硬着头皮把前端学起来，没有真正参与开发还是很难提出建设性意见。

第二次读，在一个我主推代码审查总被阻碍，最后出问题了拉我救火，哪天皮了，换团队了，换一个然自己能开心的去努力的地方。

很有帮助