如何证明应用程序建立在错误的代码库上？

我目前正在审查由一些以前在我的工作中工作过的开发人员构建的系统。从用户的角度来看，该系统运行良好，但是当深入研究代码审查时，这简直是一团糟。我非常确信该应用程序的构建方式将无法承受未来的更新，更不用说使用率的高增长了。

问题是我知道情况有多严重，但我的上级却没有。我该如何向经理证明这一点，以便他真正地看到问题并可以说服他在当前代码库上进行最少的分类，并在不久的将来为该应用程序的下一版本启动新的开发线？

“但是现在就起作用”是对软件工程师的合法挫败感的标准管理回应。我要做的第一件事是编译文档（如果有的话），并用它来证明代码和文档之间的矛盾。

如果可以，请整理一整套的单元测试套件。每次更改都运行这些命令，以便可以记录可归因于现有代码库的回归。

最后，如果您可以从您信任的另一部门招募开发人员，请再看一遍代码。一位开发商说“这很烂”要容易被驳斥，而相比之下，已经有一段时间的资深开发商为他作证并说：“不，吉姆，他是对的。这是胡扯饼干上的胡扯。

当然，这完全取决于您的环境，公司规模等。

如果您还没有阅读过，我总是建议您看一下《实用程序员》。不仅需要为每个软件专业人士阅读，而且对于与不将软件工程视为技巧的管理人员，同事，用户等打交道，它也提供了一些好的建议。

从管理层的角度来看，该系统没有任何问题，您只是在抱怨，因为[您只想重写它/您不了解以前的工程师做了什么/您想使工作变得简单]。有点稻草人，但是当高层管理者看到现在一切都很好时，他们不愿意看到您这样做的危机（我敢肯定那里存在气候变化的寓言……） 。

在某种程度上，他们有一点。当发布远远超出其最初的估计值时，管理人员会发现问题，估计值对于完成的工作而言似乎太高了，“用我们现有的代码库是不可能的”，并且错误的发生率超过了QA。如果事情进展顺利，就很容易拍打你的头，告诉你要尽力而为，因为这不会影响利润。

做什么取决于您的组织和软件本身。不过，从根本上讲，我建议记录由于不良旧代码而引起的所有并发症。在估计任务时，请向管理层明确说明您为什么会花这么长时间，并详细解释旧代码库的哪些方面会增加额外的成本。在将错误引入代码时，请包括导致此错误的原因，以及旧代码库中的问题是如何引起的。

我建议以某种方式向利益相关者表述您的关注点，以表明该软件已经超出了其原始设计，现在难以继续增强。

有许多可用的工具可以进行代码覆盖和代码审查。适用于您技术的Google工具，通常是行业标准工具。我建议您使用这些工具并提供代码质量报告，并将其提交给Manager。确保您的批评是建设性的和非政治的。

选择一个易于理解的示例，其中管理将认为这是一个简单的变更请求，但是由于现有的设计，难度要大得多。

您不希望他们专注于特定的请求，但是请确保让他们知道这就是任何更改请求的内容。没有人希望被应用程序涂在角落。开发人员相信YAGNI，但管理层相信CYA。

负载测试的建议可能是一个很好的方法，但是他们可能无法确信增加的使用问题可以满足任何现实世界的增长潜力（该公司不会在一年内翻番）。

一切都是相对的。当他们有计划要花费更多时间的重要项目时，他们可能不希望将资源投入该项目。不要因为看不到全局而被贴上标签。

当您谈论证明某事时，所有科学方法都将发挥作用，而这部分意味着，如果您要接受决定真相的客观标准，则必须接受以下可能性：经过调查，发现那些令人讨厌的事实事实证明不在你身边。

就您而言，我认为有两件事需要证明。

首先，当前的代码库是“错误的”。您可能可以证明的是“几乎所有检查此代码的开发人员的专业意见都是不好的”。

其次，公司最好改写代码库。这是一个问题，因为即使第一点是正确的，第二点也可能不是。另外，您还不足以做出此决定。这是管理层的工作，如果您希望他们尊重您对第一点的专业判断，则应该尊重他们对第二点的判断。

但是如果没有您提供的信息，他们将无法确定第二点。您需要传达有关代码问题将如何影响业务的知识，以及有关重写将如何影响业务的知识。这很困难，因为两者都涉及预测具有很多不确定性的未来。

但是您可以尝试从业务角度陈述问题。在更改和回归上花费了多少额外时间？重写费用是多少？如果不重写，当前系统的成本将在多长时间内上升？如果使用量增加怎么办，如果保留当前的代码，怎么可能造成灾难？您可能真的不知道这些，但是您可以提供比其他任何人更好的猜测。给一个范围，或一些东西，以传达您认为可以预测这些东西的精确程度。

大多数开发人员不喜欢维护糟糕的代码。这就是为什么不幸的是，从开发人员的角度来看很容易重写的代码从业务角度来看可能不值得重写。

例如，即使改写最终是有利可图的，它的价值也可能比将钱花在公司其他地方的机会成本少。否则，不良的代码库可能需要更长的时间进行更改并具有更多的回归，但不足以使重写有利可图。他们可能希望在接下来的几个月内被收购，而花在重写上的钱会出现在书上，但越野车软件却不会。

尝试从业务角度考虑它，不要浪费大量的时间来获取想要的东西。从业务的角度来看，进行大笔重写几乎绝非易事。如果您想证明不可直接证明的东西，请尽力去证明它。如果您一直努力想出一种不从头开始重写的方式，但是您提出的任何建议都没有道理，那么也许是时候从头开始重写了。做出这样的努力将向您的管理层表明，您是认真代表公司的利益，而不是您自己的利益（您是代表公司的利益，不是您自己的利益，对吗？）。

我猜这取决于代码库的缺点。成为“不是我做事的方式”并不意味着它是一个不好的代码库。

实际上会使代码库变差的事情：

• 安全孔

  使服务器，应用程序和/或数据容易受到攻击的问题。尤其是那些使敏感的公司，客户或客户数据面临风险的事物。这些应该易于记录。

• 工作破裂

  之所以起作用，是因为您需要对数据进行按摩并几乎连续对应用程序进行维护以保持其正常运行。如果您要离开而没有人接过闲暇，它将不再起作用。-记录您花费多少时间进行此操作。并注意您可以节省多少。通常，这些过程对用户来说效率也不高，您也可以将其记录下来。

• 实际上不起作用

  它似乎可以工作，但是结果不正确。这通常会带来一些问题，例如数字不匹配，缺陷率高等。

什么是不错的代码库（就是不好）：

• 写在过时的不受支持的技术上。（VB6，COBOL，.net1.1等）

注意迁移到新技术的优势。尝试找到一次可以移动的迁移路径，以便可以最大程度地降低风险并建立用户和管理信心。确保逻辑与原始逻辑基本相同。

• 未记录/格式错误的代码

这是最容易修复的方法，因为通常您可以添加注释并更正格式，而实际上不会影响代码。但这不需要重写。如果您认为这与其他问题结合在一起，那么要做的第一件事就是修复此问题，以便您可以更好地评估代码的可行性。

您已经以某种方式回答了自己的问题。

说服他们在系统上花钱的方法是等待，直到对用户不起作用为止。如果您认为它无法扩展，请等待这种情况发生，或者进行负载测试以证明这一点。

这是一个简单的清洁建议，需要花费X个小时。

这是一个艰难的情况，因为从用户的角度来看，现在一切都处于可接受和稳定的位置。目前主要与非技术经理无关，但是要求重写代码库是一项巨大的决定，不应轻描淡写，尤其是在单身人士（您自己）的观点和努力下。

因此，由于技术债务压倒（您认为，我们没有任何例子，必须说服您），您正处于为改写辩护的困境中，并且处于困境中难以在此系统中维护和添加功能。

您对新功能的估计会很高，用事实证明这些数目很高，证明这些事情确实会花费大量时间。如果您不能正确地传达这一点，那么您的经理可能会认为您无能，当然您也不想这么做。当他质疑较高的估算值时，请解释为什么您感到累积的技术债务阻碍了快速廉价地向当前软件添加功能的能力。如果您的经理有两个脑细胞要摩擦在一起，他将很快开始理解。

重点是，您不应试图说服您的经理，而应通过适当（且经过精心选择）的信息引导您的经理，使他/她可以说服自己重写是可以接受的过程。您必须让经理一直认为这是他/她的主意。

首先确定代码库中累积的技术债务。然后看看这个问题和答案，在其中解释如何在进一步进行之前说服管理层偿还技术债务。

所有成熟软件看上去都一团糟的原因是：

1. 所有的混乱都在编码业务所依赖的关键逻辑。没有它，什么都行不通。解决用户问题是必不可少的。
2. 它使用的是过时的技术。当前的程序员似乎认为，如果不使用模板魔术，那就太麻烦了。这是坏视图。任何迟到更大项目的人都将在学习所有细节的同时进入这个阶段。
3. 以前很关键的要求不再那么关键。这是因为该软件已经解决了这些问题。到项目迟到，似乎没有充分的理由就使软件变得复杂-问题不再存在，但是代码的复杂性仍然存在。