Bernard (@yuemink)在工作中,我们还真的有必要认真地去review别人的代码吗? 中发帖

最近工作中遇到一些挺纠结的事情,想听听大家的看法。 
一个团队里,如果代码质量长期不好,后面一定会带来很多 bug。我们公司整体比较保守,系统也都是高度定制化的。想把项目做好,本质上还是要靠人力去仔细审代码、梳理逻辑、补测试、改结构。
但问题是,认真做这些事情,很容易得罪一批人。
因为有些人可能只是想安稳混口饭吃,并不太关心代码质量、架构设计或者长期维护成本。出了 bug 就修 bug,哪里报错就在哪里打补丁,代码拼拼凑凑,能跑就行。短期看问题解决了,长期看技术债越堆越多,后面的人越来越难维护。
更让我纠结的是,我发现团队里不少人其实都是这种心态。大家都不太愿意把问题说破,也不太愿意推动代码质量改进。毕竟一旦开始认真 review,指出历史问题,就很容易被理解成“挑刺”“否定别人工作”,甚至影响团队关系。
但我自己又确实想把项目做好,不想每天都在重复修同类 bug,也不想眼看着系统...