讨论:怎样才算“易于维护”?

  • 赵劼

2009 年 8 月 24 日

话题:敏捷.NET语言 & 开发文化 & 方法

不久前,NHibernate的主力开发人员Oren Eini在博客上发表了一篇名为“怎样才算易于维护”的文章,许多网友围绕这个问题表达了自己的看法。

事情的起因是由于NDepend的开发人员Patrick Smacchia认为NHibernate 2.1 的代码“变得很难维护,容易牵一发而动全身”,Oren Eini 撰文予以回应并认为 NHibernate 2.1 的代码依然很容易维护。话题慢慢转移到对“易于维护”标准的讨论上,如Frans Bouma在回复中谈到

已经花费很长时间来深入代码的人自然能够顺利地修改代码,对他来说代码便是易于维护的。但是对于新接触这些代码的人来说,如果需要花费很长时间才能知道应该从哪里入手,以及更重要的:“为什么”要这样修改,这已经意味着这些代码的可维护性需要提高。

Oren 对此有不同看法,他谈到

我必须说我完全不同意这个看法。

“可维护性”对那些熟悉代码的人来说才有意义,如果这些人认为代码令人难以接受,则表明可维护性较差。如果某人对代码还缺乏必要的了解,那么他认为“难以维护”并不能说明代码本身的任何问题。

不少回复支持 Oren 的看法,如Phil Haack(微软 ASP.NET MVC 框架开发人员之一)回复到:

我完全同意你的看法。例如,如果我接触一个较大规模的 Python 程序,那么我自然难以对它进行维护。除非我学习了 Python,它的风格和约定,那么我可能就会觉得那些有经验的 Python 程序员写的代码容易维护了。

……然而,熟悉代码所需要的时间,与在了解代码的情况下,是否容易进行维护并没有直接的关系。我们还必须区分领域本身的复杂程度,以及低劣的实现方式所带来的复杂性。

不过也有人认同 Frans Bouma 的说法

如果你足够了解代码的话,就算是一堆狗食(dog-breakfast)也是容易维护的。我见过许多代码本身很有问题,但是它们的作者还是能够轻松地维护代码。

所以衡量可维护性的正确方式,应该让作者和熟悉的人回避,让其他的人来尝试着进行维护。如果难以进行,则这段代码早晚会出问题。这在我的定义中代表了较差的可维护性。

也有人认为应该区分一些概念

在我看来,可维护性是指那些已经熟悉代码的人,在修改系统时需要承担多少风险的问题。如果你有自信可惜在修改时不破坏无关的部分,那么系统就是易于维护的。

至于“可学习性(learnabiliy)”则是另一个问题了。

但是事件的“始作俑者”Patrick认为“可维护性”和“可学习性”是一回事情

我同意 Bouma 的说法。一个人不可能永远熟悉每一行他写的,或者他曾经维护过的代码。我经常遗忘两星期前写的代码。但是有了组件化,结构化,分层……我可以在遗忘之后很快地重新掌握它。

可学习性和可维护性表示的是同一类事情,它们都意味着代码必须被独立地分割,独立地开发,重构,测试,学习和增强。这是“分而治之”原则。违反这个基本原则的代码规模很难提高,对于大型 IT 组织来说,违反这个原则会是最主要的问题。

Jason 认为影响“可学习性”的因素有时并非单纯的实现问题

我认为我们应该通过观察代码的耦合性,内聚性,以及一个人能否根据接口和文档(而不是深入代码)了解代码的作用和使用方式来评价它的“可维护性”。

而可学习性与可维护性不同,因为领域本身的特点会影响学习难度。不过可学习性的其他一些因素也会涉及到可维护性,因此它们是有关系的。

此后,大部分人在回复中认为“代码的可维护性不应该和开发人员等外部资源有关”,因为没有人能够保证这些外部资源是永远充足的。

您的看法是什么呢?您认怎样的代码“易于维护”呢?

敏捷.NET语言 & 开发文化 & 方法