如何有意义地衡量可维护性？

Question

上下文:我是一家全微软商店的企业开发人员。

有人能推荐一种客观地度量代码或应用程序的可维护性的好方法吗？

为什么可维护性:我厌倦了我的小组中的“质量”度量标准只围绕bug和代码覆盖的数量旋转。这两种度量都很容易处理，特别是当您没有度量可维护性时。短视和最后期限导致了大量的技术债务，而这些债务从来没有得到真正的解决。

为什么有能力客观地衡量:我在一个大企业集团工作。如果你不能客观地衡量它，你就不能让人们对它负责，或者让他们变得更好。主观测量要么没有发生，要么没有一致发生。

我在看量2010代码度量，但我想知道是否有人有其他建议。

Answer 1

度量可维护性的警告是，您正在尝试预测未来。代码覆盖率、bug计数、LOC、圈复杂度都处理当前的问题。

事实是，除非您有具体的证据证明代码是不可维护的，否则由于无法维护的代码，bug会导致N个小时的不需要时间；那么，有一条腿站立起来就会有内在的困难。在这个例子中，它可能是由这样一个事实造成的，即当一个简单得多的方法已经足够时，就会使用过于复杂的方法。踏入一个尝试测量方法、范例和最佳实践的领域变得越来越困难，而很少或根本没有长期收益。

不幸的是，走这条路是一条无路可走的路。关注于发现根本问题，这些问题有很大的优点，并且与个人对一个问题的感觉无关，比如在整个代码库中缺乏命名约定，并找到一种方法来衡量这个根本问题的成败。然后，这将允许您开始组装一组构建块，然后您就可以开始制定解决方案了。

Answer 2

好吧，我用的或者我喜欢用的方法是：

对于每个独立的、单行的、单行的或离开的it功能需求，在实现它之前对代码库进行快照。然后实现它，包括查找和修复过程中引入的任何bug。然后在代码库之前和之后运行一个diff。diff将向您显示实现更改的所有插入、删除和修改的列表。(就像插入10行连续的代码一样，这是一个改变。)有多少变化？通常，这个数字越小，代码的可维护性就越强。

我称之为源代码的冗余，因为它就像纠错代码的冗余。信息包含在一个块中，但编码为N块，所有这些块都必须一起完成，才能保持一致。

我认为这是干的背后的想法，但它有点笼统。这个计数低的原因是，如果需要N个更改来实现一个典型的需求，而作为一个易出错的程序员，您一开始只得到正确的N-1或N-2，您已经输入了1或2个bug。在O(N)编程工作的基础上，必须发现、定位和修复这些bug。这就是为什么小N是好的。

可维护性不一定意味着可读性，对于一个还不了解代码如何工作的程序员来说。优化N可能需要做一些为程序员创建学习曲线的事情。下面是一个例子。帮助的一件事是，如果程序员试图预测未来的变化，并在程序的评论中留下如何指导的话。

我认为，当N被压缩得足够远(最优是1)时，源代码读起来更像一种特定于领域的语言(DSL)。这个程序与其说是“解决”了问题，不如说是“陈述”了问题，因为理想情况下，每个需求只是作为一段代码被重声明。

不幸的是，我没有看到人们学习如何做这件事。相反，他们似乎认为心理名词应该成为类，动词应该变成方法，而他们所要做的就是把曲柄转过来。根据我的经验，这会导致N为30或更多的代码。

Answer 3

可维护性实际上并不是可测量的。这是一个基于个人经验和偏好的主观观点。

对于一个给定的代码，想出一个完美设计的想法。

然后，对于实际代码与完美代码的任何偏差，将100的值减少一些。具体取决于所选择的非完美方法的后果。

举个例子：

一段代码读取和导入某些数据格式，如果出现错误，可能会显示错误消息。

完美的解决方案(100)将错误消息保存在一个共同的地方。如果您的解决方案将它们硬编码为字符串常量直接在代码中，您可以删除，例如15关闭。因此，您的可维护性索引变为85。