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