作为一个新的团队负责带可维护性问题的项目该怎么办？

我刚刚负责一个涉及可维护性问题的代码项目。我怎样做才能使项目稳定下来？

我发现自己在一个我们正在使用非常大型的多层.NET系统的地方，该系统缺少许多重要的东西，例如单元测试，IOC，MEF，太多的静态类，纯数据集等。只有24岁，但我已经在这里待了将近三年（此应用程序已经开发了5年），并且主要是由于时间限制，我们一直在添加更多的废话以适应其他废话。在空闲时间做完许多项目之后，我开始理解所有这些概念的重要性。同样由于员工的转移，我发现自己现在是这个项目的团队负责人，我真的很想提出一些聪明的方法来改进此应用程序。可以向管理层解释价值的方式。我对自己想做的事情有想法，但是这些想法似乎都让人不知所措，没有太多前期收获。关于人们如何或将如何处理这个问题的任何故事都将是非常有趣的读物。谢谢。

预算时间来偿还技术债务。你只是要做。首先攻击哪个部分取决于开发人员当前在哪些地方花费的时间最多，但是从入门开始，然后再着手进行理想的事情更为重要。如果您使用的是Scrum，则将特定的技术债务工作放在待办事项上，并像对待功能一样对待它们，直到您能够处理为止。

强烈建议使用旧版代码有效工作，这可能会很有用。我还没有读过它，但是它似乎有很多有关将单元测试引入遗留代码的信息，因此您可以对其进行修改并使其安全更新。

与管理类似，可以使用信用卡进行类比-您正在为所做的每件事“付出利息”，因为很难完成任何事情。如果您偿还技术债务，则将释放这些资源，并能够在将来更快地开发新功能。如果您不这样做，您的“利息”（以开发时间支付）将继续累积，并且您的团队将产生较慢的新功能。

也许开始估算每个周期中与技术债务作斗争所花费的时间，以使他们了解已经累积了多少时间。描述在可维护系统中修复或功能更改的外观，在实际系统中的外观，以及需要进行哪些更改或可能是达到此目标的良好第一步。

将技术债务归结为错误修复和其他功能。

我发现一种迭代的改进方法可以产生最佳结果。每当您触摸代码时，我的工作口号就是提高代码质量。无论是错误修复还是功能，每一项工作都始于对可以修复/重构/清理的内容的分析。我们尝试按比例（按比例）进行重构，以完成我们必须完成的工作。

在代码库中创建问题的有序列表。确保每个人都知道列表和优先顺序。每当他们完成工作时，就应该从与要处理的代码相关的列表中查找问题。

这不会解决所有问题。有些重构或修复需要大量的时间和资源。我通常会尝试将它们与其他有益的大型工作联系起来。

我可能只是在说显而易见的东西，但嘿。

编写一个小单元测试，以测试有问题的代码块，然后重构所述代码块，以确保测试仍然可以通过。移至另一段代码，您可以从刚刚构建的那一小部分坚实的基础上最轻松地到达那段代码。泡沫，冲洗，重复。

这也将帮助您更加熟悉代码库。

在做了一段时间之后，您会发现是时候进行更多的扩展重构了。找出重复的代码，违反DRY原理...您知道，这是通常的情况。届时，您将获得一个不错的代码覆盖率，这将使您可以改组方法，提取接口和所有这些便利设施。

总是离开代码库比开始入侵它之前要好一些。我很确定这是一笔很小的投资，即使是在不太长的时期内，也可以得到回报。

您可以尝试从一个起点入手，解释该项目的技术负担。您也可以尝试讨价还价，由于员工的转移，必须花一些时间来加快代码的速度，这意味着要进行一些测试以帮助确保更好的未来开发，因为这些测试可以帮助防止错误并使事情变得更容易可能有新人从事该项目。

在这种情况下，我想尝试尽可能地简化该项目。找出使它向前发展绝对必要的功能。任何已经存在很长时间的系统都可能有很长的积压。这些项目很多都是至关重要的，而很多只是“铃铛和口哨声”。

就测试而言，单元测试肯定会有所帮助，但是您可能想请一些非技术人员参与测试并将错误提交给团队成员。

祝好运。

一种选择是清除简历并开始求职。

一个好问题要问自己：这个运作不佳的项目是否预示着整个公司的运作方式。如果答案是肯定的，请询问您的薪水是否足以留在经营不善的公司中。

很多时候，如果您可以告诉高层管理人员这将是性能提升或修复了一些现有的错误，则可以推动重构。不要仅仅为了改变某些东西而进行重构，尤其是在可行的情况下。错误修复时间也可能是进行某些重构的好方法，因为您已经在那里了。要有主见，不要因为自己比编码员还年轻而看待它。从一些小事情开始，例如进行一些单元测试并从那里开始工作，您可能会暴露一些可以使管理人员为其他事情提供周期的错误。

我目前正在阅读.NET中的Brownfield应用程序开发，基本上，它是关于如何解决当前存在的问题的。到目前为止，我喜欢它所说的大部分内容（不是很全部-但这是帮助您以自己的方式思考问题的方法的书，而不是旨在完全说明性的书）。它可能有多种帮助-它表明您并不孤单；希望它会提示您如何解决某些问题。

从根本上讲，我同意大多数方法-您不能在一夜之间解决整个问题，但是可以以非常小的步骤逐步改进它。是的-技术债务是您需要使用的隐喻。

这最终取决于您的员工在该项目上的表现。如果是造成混乱的是同一组人员，那么与同一个小组一起改善它的机会就很小。分析您的员工，找出最弱的成员并更换他们（如果您有能力）。

“你不能用母猪的耳朵制成丝绸钱包”。