最近工作中遇到一些挺纠结的事情，想听听大家的看法。
一个团队里，如果代码质量长期不好，后面一定会带来很多 bug。我们公司整体比较保守，系统也都是高度定制化的。想把项目做好，本质上还是要靠人力去仔细审代码、梳理逻辑、补测试、改结构。
但问题是，认真做这些事情，很容易得罪一批人。
因为有些人可能只是想安稳混口饭吃，并不太关心代码质量、架构设计或者长期维护成本。出了 bug 就修 bug，哪里报错就在哪里打补丁，代码拼拼凑凑，能跑就行。短期看问题解决了，长期看技术债越堆越多，后面的人越来越难维护。
更让我纠结的是，我发现团队里不少人其实都是这种心态。大家都不太愿意把问题说破，也不太愿意推动代码质量改进。毕竟一旦开始认真 review，指出历史问题，就很容易被理解成“挑刺”“否定别人工作”，甚至影响团队关系。
但我自己又确实想把项目做好，不想每天都在重复修同类 bug，也不想眼看着系统越来越难维护。尤其我还是外包身份，很多时候话语权有限，说重了容易得罪人，说轻了又没什么效果。
所以现在很矛盾：
一方面，我知道代码质量、测试、review、重构这些事情是有必要的；
另一方面，在一个不太鼓励这些事情的环境里，太认真反而可能把自己推到一个很尴尬的位置。
目前我能想到的做法是，不搞“大规模代码审判”，而是尽量从具体 bug 和具体风险入手。比如某个地方反复出问题，就顺手加一点边界处理、补一点测试、加一些日志，或者把明显重复的逻辑稍微收敛一下。尽量不评价人，只讨论风险、返工成本和线上稳定性。
但说实话，还是会觉得累。因为你想把事情做好，可环境不一定支持你这样做。
不知道大家有没有遇到过类似情况？在一个整体比较保守、代码质量意识不强的团队里，怎么推动改进才不至于把自己搞得太孤立？尤其是在外包身份下，应该坚持到什么程度，边界又该放在哪里？
知道AI一定要把我们这一批人全部取代了。其实我讨论的上面的话题其实是没有太大意义的，但是就是得罪了同事。
5 个帖子 - 5 位参与者