什么损害了可维护性？

Question

对于那些还没有多少实际经验的人来说，可维护代码的概念有点模糊，尽管它遵循的是典型的良好实践规则。直觉上，我可以看出，代码可以编写得很好，但如果它是硬连接信息，需要不断更改，那么代码是无法维护的，但我仍然很难查看代码，并决定它是否可维护。

所以问题是:什么损害了可维护性？我该找什么？

Answer 1

维护性有很多方面，但最重要的是松耦合和高内聚力。本质上，当您使用好的代码时，您可以在不需要将整个代码基保存在头脑中的情况下，到处进行小的更改。对于糟糕的代码，您必须考虑更多的事情:修复这里，它会在其他地方崩溃。

当您面前有代码的100+ kLOC时，这是至关重要的。所谓的“良好实践”规则，如代码格式化、注释、变量命名等，与耦合/衔接问题相比都是肤浅的。

耦合/内聚的问题是不容易快速测量或看到。有一些学术上的尝试，也许是一些静态的代码分析工具，但我所知道的任何东西都不会立即给出一个可靠的估计，你将有多困难的时间与代码。

Answer 2

重复代码：

当涉及到程序的维护成本时，复制粘贴很可能是最昂贵的操作。

为什么要把这段代码移到一个普通的组件上，我会把它复制过来，然后完成它--是的.程序员这样做可能节省了一小时的工作时间。但是后来出现了一个窃听器.是的，当然，它只在运行代码的一半中被修复。这意味着以后还会记录一个回归，从而导致同一件事情的另一个修复。

这听起来很明显，但在大计划中，它是阴险的。程序员看起来不错，因为他们做的更多。开发团队经理看上去不错，因为他们准时交货。由于问题是在很久之后才发现的，所以罪魁祸首永远不会落在真正的罪魁祸首身上。

由于这样的“回归”，我失去了一天的时间去跟踪一个已经完成的修复程序，重新修复了它，并把新的构建推到了死胡同。所以是的，六个月前一个开发项目的一小时时间(大约40美元)刚刚计算了一个高级开发人员一天的费用+一个初级开发人员的半天时间+一个初级开发人员的半天时间+一个已经很晚的项目的整整一天的延迟时间。

你算算..。

所以下一个我发誓他最好跑得快一点，我马上就在他后面！

Answer 3

虽然代码破坏了其他答案中的规则，但维护起来肯定更糟，所有代码都很难维护。，因此是你拥有的越少越好。缺陷与代码、所以代码越多，bug就越多.的数量密切相关。一旦代码超过了一定的大小，您就无法保持你的整个设计在你的脑海里，而且事情变得更加困难。最后，更多的代码最终意味着更多的工程师，这意味着更多的成本，更多的通信问题和更多的管理问题。

尽管要记住，不应该编写更复杂的代码，而应该编写更短的代码。最容易维护的代码很简单，并且不包含任何冗余，以使其尽可能短。只要API调用足够简单，将任务委托给其他程序或API也是可行的解决方案。

所以简单地说，任何多余的代码都是一个可维护的问题。