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

作者 赵劼 发布于 2009年8月24日 上午7时52分

社区
.NET,
Agile
主题
协作,
变更
标签
nHibernate

不久前,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认为影响“可学习性”的因素有时并非单纯的实现问题

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

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

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

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

可维护不同易维护! 发表人 Quiet Zoom 发表于 2009年8月25日 下午9时2分
代码维护我之见解 发表人 Lee Jet 发表于 2009年8月24日 上午8时43分
最小修改 发表人 David Vi 发表于 2009年8月24日 下午7时55分
Re: 最小修改 发表人 敏 朱 发表于 2009年8月24日 下午8时19分
Re: 最小修改 发表人 敏 朱 发表于 2009年8月24日 下午8时20分
可学习性,最小修改 发表人 Scott Yao 发表于 2009年8月24日 下午10时18分
我同意可维护性与可学习性等价的说法 发表人 现民 李 发表于 2009年8月24日 下午10时32分
增强可维护性依靠量化的标准和teamwork,而不是凭感觉 发表人 Jackei Chan 发表于 2009年8月24日 下午10时44分
  1. 返回顶部

    代码维护我之见解

    2009年8月24日 上午8时43分 发表人 Lee Jet

    代码的熟悉度和代码本身资料对代码维护本身都是有很大影响的,不能弃而从一定。不过,在我的经验来看,对代码的熟悉会跟容易维护代码。

  2. 返回顶部

    最小修改

    2009年8月24日 下午7时55分 发表人 David Vi

    对系统进行维护,自然要对代码,以及整个架构很熟悉,否则还谈什么维护。 易于维护在于,在修改一个bug或者追加一个功能时,是不是牵一处而动全身。

  3. 返回顶部

    Re: 最小修改

    2009年8月24日 下午8时19分 发表人 敏 朱

    Jason 说得对。判断这个问题的标准,必须跳出技术的圈子,站在组织HR的角度看。

  4. 返回顶部

    Re: 最小修改

    2009年8月24日 下午8时20分 发表人 敏 朱

    Sorry,是Patrick:)

  5. 返回顶部

    可学习性,最小修改

    2009年8月24日 下午10时18分 发表人 Scott Yao

    Jason说的对,可学习性被领域本身所影响。不过,代码本身的可学习性也是至关重要的,可以使不了解的人快速上手,进行维护。 David对最小修改的描述很好!赞同:-)

  6. 返回顶部

    我同意可维护性与可学习性等价的说法

    2009年8月24日 下午10时32分 发表人 现民 李

    我同意可维护性与可学习性等价的说法,功能可能会添加,人员可能会流动,不能指望一个人长时间的去维护同一组代码

  7. 返回顶部

    增强可维护性依靠量化的标准和teamwork,而不是凭感觉

    2009年8月24日 下午10时44分 发表人 Jackei Chan

    很多类似的问题陷入深深的讨论却始终没有结论的原因之一,就是没有量化的标准。 是否容易维护,自然要考虑到负责维护的人的知识/经验,以及相关背景,而不能是凭借感觉。例如某个团队内部可以定义一个标准:N年工作经验,对Java某些领域开发,某某框架,某某行业的业务,有怎样的熟悉程度的人,花多长时间能上手维护的代码,才算是可维护的。 当然,也可以通过过程来规范。比如要求移交代码时,必须提交经过评审的相关设计文档,并通过IDE对代码规范做一些规范化要求,增加code review的覆盖率,这些都有助于增强代码的可维护性。 总结一下,可维护性要靠 团队+个人 两个维度来解决,在工作中逐步解决导致可维护性低的问题,逐步走向规范化。

  8. 返回顶部

     回复通知

    可维护不同易维护!

    2009年8月25日 下午9时2分 发表人 Quiet Zoom

    - "可维护性"是个类似加速度的一个比值,应该是单位时间可以修订的功能数量吧! - 易维护,纯粹就是个感性的度量指标,无法有统一标准的 囧rz... 不过,我认为代码的易于维护是可以度量的,而且必须考虑外界的条件和变化!因为,一但提及维护,就代表代码必须和外部条件进行交互并对应修订了! 所以,我感觉,代码的易维护程度,取决于可以持续维护以响应工程需求变化多长时间! + 如果到最后代码演变成再也不变的标准模块,可以长久的复用下去,那么代码是易维护的,因为不用再维护了; + 如果到最后谁也忍受不了,直接抛弃,那么代码不是易维护的,虽然不用再维护了,但是已经死亡了! + 这个逐渐趋向死亡的过程,时间越长,说明代码的可维护度越高

::...
免责声明:
当前网页内容, 由 大妈 ZoomQuiet 使用工具: ScrapBook :: Firefox Extension 人工从互联网中收集并分享;
内容版权归原作者所有;
本人对内容的有效性/合法性不承担任何强制性责任.
若有不妥, 欢迎评注提醒:

或是邮件反馈可也:
askdama[AT]googlegroups.com


点击注册~> 获得 100$ 体验券: DigitalOcean Referral Badge

订阅 substack 体验古早写作:


关注公众号, 持续获得相关各种嗯哼:
zoomquiet


自怼圈/年度番新

DU22.4
关于 ~ DebugUself with DAMA ;-)
粤ICP备18025058号-1
公安备案号: 44049002000656 ...::