讨论：怎样才算“易于维护”？
作者 赵劼 发布于 2009年8月24日 上午7时52分
不久前，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认为影响“可学习性”的因素有时并非单纯的实现问题：
我认为我们应该通过观察代码的耦合性，内聚性，以及一个人能否根据接口和文档（而不是深入代码）了解代码的作用和使用方式来评价它的“可维护性”。
而可学习性与可维护性不同，因为领域本身的特点会影响学习难度。不过可学习性的其他一些因素也会涉及到可维护性，因此它们是有关系的。
此后，大部分人在回复中认为“代码的可维护性不应该和开发人员等外部资源有关”，因为没有人能够保证这些外部资源是永远充足的。
您的看法是什么呢？您认怎样的代码“易于维护”呢？
相关厂商内容
敏捷名师讲堂之Kent Beck——响应式设计（9月10日）
敏捷宣言创始人Dave Thomas演讲：程序员修炼之道，十年之后
相关赞助商
极限编程创始人Kent Beck，敏捷宣言创始人Dave Thomas，国际敏捷权威专家Fred George、Dave Nicolette以及国内知名公司专家分享“实效敏捷”。现在报名！
-
代码的熟悉度和代码本身资料对代码维护本身都是有很大影响的，不能弃而从一定。不过，在我的经验来看，对代码的熟悉会跟容易维护代码。
-
对系统进行维护，自然要对代码，以及整个架构很熟悉，否则还谈什么维护。 易于维护在于，在修改一个bug或者追加一个功能时，是不是牵一处而动全身。
-
Jason 说得对。判断这个问题的标准，必须跳出技术的圈子，站在组织HR的角度看。
-
Sorry,是Patrick：）
-
Jason说的对，可学习性被领域本身所影响。不过，代码本身的可学习性也是至关重要的，可以使不了解的人快速上手，进行维护。 David对最小修改的描述很好！赞同:-)
-
我同意可维护性与可学习性等价的说法，功能可能会添加，人员可能会流动，不能指望一个人长时间的去维护同一组代码
-
很多类似的问题陷入深深的讨论却始终没有结论的原因之一，就是没有量化的标准。 是否容易维护，自然要考虑到负责维护的人的知识/经验，以及相关背景，而不能是凭借感觉。例如某个团队内部可以定义一个标准：N年工作经验，对Java某些领域开发，某某框架，某某行业的业务，有怎样的熟悉程度的人，花多长时间能上手维护的代码，才算是可维护的。 当然，也可以通过过程来规范。比如要求移交代码时，必须提交经过评审的相关设计文档，并通过IDE对代码规范做一些规范化要求，增加code review的覆盖率，这些都有助于增强代码的可维护性。 总结一下，可维护性要靠 团队+个人 两个维度来解决，在工作中逐步解决导致可维护性低的问题，逐步走向规范化。
-
- "可维护性"是个类似加速度的一个比值，应该是单位时间可以修订的功能数量吧！ - 易维护，纯粹就是个感性的度量指标，无法有统一标准的 囧rz... 不过，我认为代码的易于维护是可以度量的，而且必须考虑外界的条件和变化！因为，一但提及维护，就代表代码必须和外部条件进行交互并对应修订了！ 所以，我感觉，代码的易维护程度，取决于可以持续维护以响应工程需求变化多长时间！ + 如果到最后代码演变成再也不变的标准模块，可以长久的复用下去，那么代码是易维护的，因为不用再维护了； + 如果到最后谁也忍受不了，直接抛弃，那么代码不是易维护的，虽然不用再维护了，但是已经死亡了！ + 这个逐渐趋向死亡的过程，时间越长，说明代码的可维护度越高
8 条回复
关注此讨论 回复