有什么正确的方法告诉管理层我们的代码很烂？

我们的代码是错误的。它可能并不总是被认为是坏的，但它是坏的，而且只会走下坡路。我不到一年前刚从大学毕业，我们代码中的许多内容使我感到难以置信。最初，我认为作为一个新手，我应该闭嘴，直到我对我们的代码库有所了解为止，但是我已经看到很多知道它不好的地方。

一些亮点：

• 我们仍然使用框架（尝试从查询字符串中获取内容，几乎是不可能的）
• VB脚本
• 源安全
• 我们“使用” .NET-意思是说，我们有.net包装器，它们调用COM DLL，几乎不可能轻松调试
• 一切基本上都是一项巨大的功能
• 代码不可维护。每个页面都有多个文件，每次创建新页面时都会创建这些文件。基本上，主页做了很多次Response.Write（）来呈现HTML（无法运行runat =“ server”？）。之后，客户端（VBScript）上可能会有很多逻辑，最后页面提交给自己（通常将很多东西存储在隐藏字段中），然后在页面上发布到处理页面，该页面可以执行诸如保存数据到数据库。
• 我们得到的规格是可笑的。通常，他们会要求诸如“使用字段Y或字段Z自动填充字段X”之类的内容，却没有指示何时选择字段Y或字段Z。

我确信其中部分原因是没有在软件公司工作，但我觉得编写软件的人们至少应该在乎其代码的质量。我什至无法想象，如果我提出一些建议，那么很快就会发生任何事情，因为迫在眉睫的最后期限迫在眉睫，但是我们将继续编写不良代码并使用不良做法。

我能做什么？我什至如何提出这些问题？我的团队中有75％同意我的观点，并且过去曾提出过这些问题，但没有任何改变。

确保您没有反应过度。您很新鲜，可能没有在很多其他地方工作过，因此也没有为“现实生活中的代码”做好准备。现实生活中的代码是一件可怕的事情。就像您的学校代码很好，您对项目项目的强迫性调整使他们在核反应堆的地下室发生性关系，婴儿在下水道的有毒废物中长大。这是一个可怕的突变体。

但是，假设您是对的，并且代码与您所说的一样糟糕（即比通常的错误代码更糟糕），那么您就值得关注。与您的团队交谈，确定是否其他所有人都在旁边。需要采取工作来改善这种情况-如果团队中的其他成员都知道问题所在，但不在乎，那么您就是在浪费时间。

作为一名大三学生，您可能没有领导能力。如果您自己去管理，作为一个也是初级的新员工，您的意见可能会被忽略。让您的首席开发人员或最资深的人员之一参与进来。同样，如果没有一个高层人士对此感兴趣，那么您就是在浪费时间。

假设您可以让一些高级技术人员感兴趣，那么我将努力确定问题区域和可能的解决方案。例如，如果“一切基本上都是一个巨大的功能”，那么下次您使用该“巨型功能”时，也许您应该重构一下。同样，您需要让每个人都受益。如果您解决了小部分问题并逐步改进，最终它们将变得无足轻重。每次触摸一段代码时，请考虑是否可以对其进行改进。

您不会与管理层坐下来，说“一切都不好，需要重写”。这对他们来说毫无意义-成本高昂，而且风险很大。相反，应该让他们意识到存在问题，并且有计划随着更改的进行而逐渐改进。应该对他们进行有关可维护代码的好处的教育。这应该来自他们在技术和专业上都信任的高级人士，而不是您。

完成重写？几乎总是一个坏主意。

最终，因为您是新手，所以您无能为力。如果没有人想改善事情，那么您将积累经验并移到下一个地方。

阅读Joel On Software，这是您不应该做的事情。了解他的推理，然后阅读由管理人员（而不是程序员）撰写的有关不良软件及其修复方法的其他文章。有了这些信息，您就可以提出解决问题的理由，管理者可以理解和关心。提示：优秀的管理者不会仅仅根据程序员对必须完成的事情的看法和感受来花费时间和金钱。

即使您在技术上是正确的，“这些代码都是废话，需要重写”肯定会反驳您。

“我们可以将目前的项目计划缩短数月，降低成本并提高可靠性。” 将会引起他们的关注（注意，您在他的舞台上没有提到您打算如何做。

无论您说什么，都要确保自己是正确的。如果说不好，重写必须是血腥的，如果说要花一周的时间，那么最好确定要花一周的时间，并且要好。重做的代码中的任何缺陷都会使您个人付出高昂的代价，无论您是否进行了重做都可能会发生什么。如果有人在您之前到过那里，搞砸了或超卖了改写书，就放弃了，经理们就不喜欢被人愚弄，也不会让它发生两次。出于这种原因，不要为后续的家伙搞砸，您只能对此一枪...

寻找在一段时间或多个项目中分摊成本的方法。经理讨厌风险，投机性投资和负现金流-在经理的承受能力范围内工作。从一个小的，低风险，低成本的建议开始。一旦证明是正确的，就可以去钓大鱼。

首先，除非您是在初创公司工作，而且您是创建原始goofy遗留代码的人，否则您在作为程序员工作的任何地方都会发现goofy遗留的东西。如果您打算从事编程职业，则必须能够胜任这些工作。

其次，通常需要考虑成本来改进旧系统。例如，我已经看到多家拥有10年历史的VB6和经典ASP应用程序仍在运行的公司。在某些情况下，这是因为迁移.NET的大型项目严重失败。在其他情况下，原因是“如果没有破裂，请不要修复”。但是，在其他情况下，此举的成本是合理的，因为遗留系统引起的问题大到可以忽略。

在过去发生重大故障的情况下，几乎不可能进行更改。在这种情况下，请完善简历并开始寻找新工作。如果它没有被破坏，您可能没有理由抱怨代码本身，但是您没有走上充实而不断发展的职业道路。如果它坏了，听起来像是您的情况，那就是您有机会进行更改的时候。

我见过的最好的方法不是花太多钱，而是从将产生最积极影响的渐进式变更开始。根据您的描述，更好地管理变更请求将是一个起点。一旦得到控制，您就可以开始研究创建服务框架或其他增量设计/代码改进。

我见过的最糟糕的方法是尝试直接从旧版系统飞跃到最新的最新版，例如，从工作正常但笨拙的VB6 / Classic ASP / COM +系统跳到MVC / Entity Framework系统。

“嗨，老板，在完成Big Project之后，我和团队希望有一段时间，最好是X个月来组织我们的代码。应该能够在几分钟之内完成的工作要花几个小时，因为它非常混乱。如果无法做，在大型项目结束后，我们希望制定一个切实可行的时间表。”

（部分解释自阿兹卡尔对这个问题的评论）

开始阅读关于软件的 Joel（Joel Spolsky / Stack Exchange的创始人）...

我要做的第一件事是执行Joel测试。

这将使您可以将其表示为“当我正在寻找改善开发人员的方式时……我偶然发现了有关开发环境的12个问题测试，因此出于乐趣，我回答了他们关于我在哪里工作的问题。” ...反过来，这使它成为第三方，概述了您的代码而不是您个人的问题。

当您阅读有关“ 实用实践”的更多信息时，您将在改善自己并实现诸如红色/绿色/重构之类的内容，从而使您可以清理代码库，从而使其变得可维护。（随着时间的推移）

希望有帮助！欢迎使用编程（昨天的代码通常很烂）;-)

快速提示：如果你不提出与工作的原因列表管理，为什么你应该在代码不同，包括作为参数“提高士气/对程序员的工作条件”。

要明确的是，技术团队将比目前的混乱局面更多地编写和维护干净的代码，这肯定会改善您的工作态度。可能是一个有用的论点。

• 管理层实际上决定了设计吗？如果您有大部分团队支持，什么在阻止您？积极主动并集体决定。提出逐步实施的计划。然后去做
• 管理是否规定您使用的开发工具？除非换掉时间，否则通常不关心工具管理。积极主动，并集体决定要使用哪些开发工具。如果您需要管理层的帮助，请向他们展示迁移计划和成本效益分析。然后去做
• 管理层是否规定您使用的语言？积极主动，并集体决定使用什么代替VBScript。 提出一个计划，逐步实施它并加以实现。 如果您需要管理层购买，请向他们展示计划。然后去做
• 我没有任何规格。这通常高度依赖您工作中的人员和流程。识别故障和修复流程所需的最小更改需要时间，分析和了解事物当前的工作方式以及它们应如何工作。如果您知道可以提出一个计划并尝试说服管理层。

如果提出不涉及大量专用时间，没有任何（或软性）业务价值的变更方法，您就会获得更多的变更和尊重。

从经验上来讲：这并不容易。这几乎是不可能的。管理层不在乎代码是否糟透了，而且很可能是完全无知的和/或毫无头绪的问题，或者他们很早以前就已经解决了它，而您今天就不会陷入困境。您能做的最好的事情是列出代码烂掉的原因，然后列出为什么烂掉的原因，以证明重构/重写代码的实际业务价值。

例如“代码不可维护”的示例：

当前代码由于X，Y和Z而无法维护（列出其无法维护的原因）。这使得更改请求和新功能非常困难，因为X，Y，Z（造成更改困难的原因）。由于更改很困难，因此开发团队无法轻松地对错误修复和改进做出响应。

您唯一的希望是您的老板和高级管理人员不要太愚蠢，以至于无法理解代码的后果，并愿意停止提出新的功能要求来解决这些问题，否则您的工作将徒劳无功。从过去的经验来看，很可能他们不会发现代码有什么问题，并且/或者您的同事们太精干了，无法将他们的疑虑带给管理层。

祝好运。您将需要它。

“我刚从大学毕业就开始了”-应该回答您的问题。

管理层可能知道那里的代码不是最优的。除非您雇用了Ray Gosling，Guido Van Rossum或其他真正写实且昂贵的人，否则大多数代码都是这样。

管理层还知道，只要使用适用于您公司的“工作”的任何定义即可工作（不崩溃，出售，交付报告等）。

他们希望您以最小的成本保持代码“运行”。他们不希望有一个昂贵的项目提案来重写所有内容。

商业案例几乎是不可能的，因为您的交付物是有效的软件（他们已经拥有的）而不是优雅的代码。

再加上一个事实，即在软件中，首先具有功能就进入市场存在巨大的机会成本。如果您真的考虑过，则不能保证长期投资的回报。

话虽如此，仍然是一个好的计划，以可管理的方式重构和修复小问题（例如获得良好的VSS）。归根结底，这是一个技术问题，而不是管理问题。只要做需要做的事情，同时仍然兑现您的承诺，就可以了。即使您有充分的理由，管理层也可能对代码质量的细节一无所知。

只要尽快就可以离开（也许不要因为不想像工作漏斗而离开得太早）。他们编写的代码很乱，人们一直呆在那里，这意味着您可能正在与贫穷的开发人员一起工作。任何关心他们的工作的体面的开发人员都不会为这种胡扯花很长时间。

除非您能非常清楚地证明它值得进行投资，否则重写的几率很小。

管理层不在乎代码。他们关心要出售的产品。

如果遗留系统真的非常糟糕，并且给整个团队的大多数人增加了可笑的开销（我说大多数，因为总有人会编码大块代码或全部代码，并且像后面那样知道它。他的手）然后接近他们，并说这在开发时间上花费了业务金钱，并且会对客户满意度产生影响。

但是再一次，他们仍然不在乎代码，而是在乎产品，因此尽管答案可能会让他们“同意”，但您也可以在无需经理同意的情况下整理代码。不要太过分，确保您首先与团队交谈，没有人喜欢来使用该功能，该功能花了您3个月的时间编写而成，但现在似乎已失效，因为该功能已被黑客入侵。

以这样一种方式来进行管理：表明您了解对代码进行重大更改的预算影响和不进行更改的预算影响。我喜欢Emilio的措辞。

重要的是要记住，尽管“旧”代码总是很糟糕。我的意思是，我们每个人都随着开发人员的不断成长。我们编写好的代码，然后学习稍后编写更好的代码，以前的“好的”代码似乎很糟糕。从长远来看，太多的开发人员陷入了不断努力使其变得更好并浪费更多资金的困境。这是一种平衡的行为。话虽这么说，如果您能不断改善它总是很棒的。当您修改该巨大功能时，将其拆分！最终您会到达某个地方。

不要这样

无论如何，从头开始重写大型项目通常都是一个大错误。

我从未想过要告诉经理特别是项目经理有关错误代码和重构的内容很容易。首先，他们必须信任您，即使您是高级人士，您仍然需要时间来获得信任。其次，他们根本不了解问题有多严重。如果今天是发布新版本的最后一天，并且该版本失败。他们知道它有多严重，但是他们从来不知道构建会因为很多问题而失败，例如错误的代码，测试不足等。

我已经完成了Web项目中的配置和部署任务。每次部署新版本时，通常都需要花费很多时间来解决意外问题。大多数问题是安全性和集成性（在多个Web / Windows应用程序之间）。我们的代码很烂，其他人的代码很烂，它们完全是意大利面条式的代码。

我们正在计划一个新版本，我强烈要求进行一些重构，只需将详细日志添加到经常发生错误的登录/身份验证代码中即可。经理们同意了，但是后来被列入了一个不错的清单，我不知道是否会完成，因为我们已经有了很多功能，而且时间紧迫。

经理有两种：一种是假装了解您的工作的经理，另一种是不了解的工作。那些假装了解软件的人会对您怀有敌意。那些不只是让您烦恼。

无论如何，经理都是骗子，因此他们有很强的性格去假设其他人都是。

我的意思是，如果您说软件已过时，他们只会以此为借口。他们不在乎。