我上次遇到这种情况是在我第一个工单需要处理的代码部分，在初创公司X中，我们有一些代码会不必要地多次查询相同的表。我们还使用了一个高度定制化的（我认为）代码库，这个库在GitHub上的关注者相对较少，但这个库却渗透到了整个代码库中，并规定了做事的方式。我试图尽可能少地改动代码来完成我的修改，但避免最明显的低效之处。我认为我的修改是在疯狂的沙漠中的一片小绿洲。在第一次PR中，资深工程师狠狠地批评了我。结果发现存在一种“正确做法”的v2版本，我必须了解并编写符合v2的代码。v2也有它自己的问题，不过可能没有v1那么糟糕。后来，当我变得更有影响力时，我成功地向管理层倡导改变许多事情，包括剔除这个让我们的代码库独具特色的受喜爱的异国库……
源讨论大型成熟代码库中工程师常犯的错误原帖 368 条评论 · 导入时统计我同意一致性很重要——但当现有的代码库本身就不一致时又该怎么办呢？更糟糕的是，如果现有的代码库既不一致，而且“正确的方法”也没有文档记录呢？这更接近我加入有很多现有代码的公司时的经历。 在这种情况下，我发现唯一有效的方法是尽你所能，在你自己的独立代码中做到最好，并大声且频繁地解释你为什么用新的不同方式做事。编写可重用和共享的代码。为它编写文档。解释为什么这是正确的方法。向整个工程团队寻求反馈（尽管如果他们不直接参与你的工作，不要因为他们的反馈而停滞不前）。你很快会发现其他工程师是否认为你的方法更好。如果它确实更好，其他人会开始效仿你的做法。如果它不是，…
完整原文把你的经验，加入这段讨论。
这让我深有感触。特别是管理老一辈的情绪是一个令人沮丧的过程。几乎总是更容易直接跳进一个项目并对其进行批评，而不是从头开始。新的观点和更好的想法应该受到欢迎，但相反，它们可能会因为人们把事情看得太重而被扼杀。 我的（相当不幸的）结论是，当我遇到这种行为时，我会换到另一个团队以避免它。如果不可能的话，认真寻找另一份工作是值得的。
完整原文我在2018年与一家公司有过类似的经历，他们仍在所有开发工具中使用csh脚本。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。