我曾在一个环境中工作，其中一位高级架构师可以否决我所做的一切主要改进软件结构和可维护性的努力。有一天，我对此感到非常愤怒，于是开始把代码审查分配给他——他联系了我的经理，要求我停止这样做，因为他根本不懂这个项目。从文档的角度来看，我本来很想准确地记录我做了什么以及项目的结构是什么样的——但我却刻意避免这样做。每次我的经理的上司知道我在做什么，我就快要被从高处泼屎了。数月的工作和计划在一瞬间就被抹去了——一次又一次。依赖注入？去你妈的。Spring 太重了。模块化？去你妈的。这个项目太小了。分层配置文件？去你妈的，继续用属性文件吧（带有越来越多动态生成的键）。…
源讨论构建理论以及为什么员工流动对软件公司是致命的原帖 420 条评论 · 导入时统计> 文档只能在一定程度上起作用，因为它可能会与代码的实际运行情况不同步，而且编写复杂软件的内部文档是一项罕见的技能。大多数开发者并不具备这种技能。大多数内部文档只有在开发者已经形成了对整体结构如何连接的心理模型之后才开始变得有意义。大多数代码文档在你已经在脑海中构建了理论之后才变得有用，而不是在此之前。它作为你已知内容的助记符，而不是学习工具。 这对我来说现在特别有共鸣。 我工作的组织允许代码腐化存在了很多年，以至于即使看似微小的更改也会导致越来越多的问题出现。 我们采取的“解决方案”是要求在任何时候都必须提交详细的RFC文档，当…
完整原文把你的经验，加入这段讨论。
这里有个残酷的现实，我不得不这么说，但他们可能根本没有注意到你离开了。 这就是那种地方的常态。
完整原文这不过是一份工作，不是第五大奇迹。这家公司是基于其市场地位赚钱的，软件的功能性只是次要的。如果一切崩溃了，客户也走不了。 别和管理层对抗，离开吧。
完整原文我理解你的沮丧。我能够感同身受。但这句话： > 我几乎因为争取被认可而变得自杀了 我真诚地希望这只是夸张的说法。请永远不要让任何与工作相关的事情影响到你到这种程度。你远比你的工作更重要。还有其他机会。生活远不止于软件。
完整原文好吧，不管怎样，我不得不使用你所提议的所有东西。然而我发现它们非常糟糕，如果我在工作场所有拒绝它们的权力，我肯定会毫不犹豫地拒绝。 > 我把一个难以维护的bug堆变成了稳定且可维护的系统。 我也是，只不过当时 supposedly 使用了所有最佳实践，例如Spring Boot、DI/IoC、Mock测试框架、YAML配置、极其复杂的包结构等等。唯一缺少的就是解决它所针对的业务问题的可行方案。
完整原文你的评论就是为什么每个人都应该以顾问的身份开始他们的工程经历。 作为顾问，我学到的主要一点是，你可以离开，不需要忍受管理层的轻视。你学会了与自己脱节，并且让自己变得可被替代。 这会让生活更少令人沮丧。 很遗憾发生在你身上。不要把你自己投入到别人的孩子中去。
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。