不久前，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）也是容易维护的，
管理资料
《讨论：怎样才算“易于维护”？》(https://www.unjs.com)。我见过许多代码本身很有问题，但是它们的作者还是能够轻松地维护代码。所以衡量可维护性的正确方式，应该让作者和熟悉的人回避，让其他的人来尝试着进行维护。如果难以进行，则这段代码早晚会出问题。这在我的定义中代表了较差的可维护性。
也有人认为应该区分一些概念：
在我看来，可维护性是指那些已经熟悉代码的人，在修改系统时需要承担多少风险的问题。如果你有自信可惜在修改时不破坏无关的部分，那么系统就是易于维护的。
至于“可学习性（learnabiliy）”则是另一个问题了。
但是事件的“始作俑者”Patrick认为“可维护性”和“可学习性”是一回事情：
我同意Bouma的说法。一个人不可能永远熟悉每一行他写的，或者他曾经维护过的代码。我经常遗忘两星期前写的代码。但是有了组件化，结构化，分层……我可以在遗忘之后很快地重新掌握它。
可学习性和可维护性表示的是同一类事情，它们都意味着代码必须被独立地分割，独立地开发，重构，测试，学习和增强。这是“分而治之”原则。违反这个基本原则的代码规模很难提高，对于大型IT组织来说，违反这个原则会是最主要的问题。
Jason认为影响“可学习性”的因素有时并非单纯的实现问题：
我认为我们应该通过观察代码的耦合性，内聚性，以及一个人能否根据接口和文档（而不是深入代码）了解代码的作用和使用方式来评价它的“可维护性”。
而可学习性与可维护性不同，因为领域本身的特点会影响学习难度。不过可学习性的其他一些因素也会涉及到可维护性，因此它们是有关系的。
此后，大部分人在回复中认为“代码的可维护性不应该和开发人员等外部资源有关”，因为没有人能够保证这些外部资源是永远充足的。
您的看法是什么呢？您认怎样的代码“易于维护”呢？
本文来自：http://www.infoq.com/cn/news/2009/08/what-is-maintainable