不久前, 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 认为影响“可学习性”的因素有时并非单纯的实现问题:
我认为我们应该通过观察代码的耦合性,内聚性,以及一个人能否根据接口和文档(而不是深入代码)了解代码的作用和使用方式来评价它的“可维护性”。
而可学习性与可维护性不同,因为领域本身的特点会影响学习难度。不过可学习性的其他一些因素也会涉及到可维护性,因此它们是有关系的。
此后,大部分人在回复中认为“代码的可维护性不应该和开发人员等外部资源有关”,因为没有人能够保证这些外部资源是永远充足的。
您的看法是什么呢?您认怎样的代码“易于维护”呢?
评论