应用云平台的可用性——从新浪SAE看云平台设计
云计算平台的可用性，相比传统互联网服务而言，更加复杂和困难，也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台，以及对云计算的用户提出了建议。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
讨论：怎样才算“易于维护”？
作者 赵劼 发布于 2009年8月24日
不久前，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认为影响“可学习性”的因素有时并非单纯的实现问题：
我认为我们应该通过观察代码的耦合性，内聚性，以及一个人能否根据接口和文档（而不是深入代码）了解代码的作用和使用方式来评价它的“可维护性”。
而可学习性与可维护性不同，因为领域本身的特点会影响学习难度。不过可学习性的其他一些因素也会涉及到可维护性，因此它们是有关系的。
此后，大部分人在回复中认为“代码的可维护性不应该和开发人员等外部资源有关”，因为没有人能够保证这些外部资源是永远充足的。
您的看法是什么呢？您认怎样的代码“易于维护”呢？
赵劼 网名为老赵，洋名Jeffrey Zhao，写有技术博客“老赵点滴”。关注前沿技术，并致力于开源社区与微软平台的组合优化。
代码维护我之见解
发表人
Lee Jet
发表于
最小修改
发表人
Vi David
发表于
Re: 最小修改
发表人
朱 敏
发表于
Re: 最小修改
发表人
朱 敏
发表于
可学习性，最小修改
发表人
Yao Scott
发表于
我同意可维护性与可学习性等价的说法
发表人
李 现民
发表于
增强可维护性依靠量化的标准和teamwork，而不是凭感觉
发表人
Chan Jackei
发表于
可维护不同易维护！
发表人
Zoom Quiet
发表于
易维护的标准应只针对软件的设计
发表人
郑 飞
发表于
不应将设计复杂度和业务复杂度割裂开
发表人
He Yiding
发表于
跳出技术本身谈"易于维护"
发表人
李 大山
发表于
俺认为维护是换人来处理代码
发表人
Five Babylon
发表于
现实世界的抽象决定了系统的可维护性
发表人
ghost sole
发表于
-
代码的熟悉度和代码本身资料对代码维护本身都是有很大影响的，不能弃而从一定。不过，在我的经验来看，对代码的熟悉会跟容易维护代码。
-
对系统进行维护，自然要对代码，以及整个架构很熟悉，否则还谈什么维护。
易于维护在于，在修改一个bug或者追加一个功能时，是不是牵一处而动全身。 -
Jason 说得对。判断这个问题的标准，必须跳出技术的圈子，站在组织HR的角度看。
-
Sorry,是Patrick：）
-
Jason说的对，可学习性被领域本身所影响。不过，代码本身的可学习性也是至关重要的，可以使不了解的人快速上手，进行维护。
David对最小修改的描述很好！赞同:-) -
我同意可维护性与可学习性等价的说法，功能可能会添加，人员可能会流动，不能指望一个人长时间的去维护同一组代码
-
很多类似的问题陷入深深的讨论却始终没有结论的原因之一，就是没有量化的标准。
是否容易维护，自然要考虑到负责维护的人的知识/经验，以及相关背景，而不能是凭借感觉。例如某个团队内部可以定义一个标准：N年工作经验，对Java某些领域开发，某某框架，某某行业的业务，有怎样的熟悉程度的人，花多长时间能上手维护的代码，才算是可维护的。
当然，也可以通过过程来规范。比如要求移交代码时，必须提交经过评审的相关设计文档，并通过IDE对代码规范做一些规范化要求，增加code review的覆盖率，这些都有助于增强代码的可维护性。
总结一下，可维护性要靠 团队+个人 两个维度来解决，在工作中逐步解决导致可维护性低的问题，逐步走向规范化。 -
- "可维护性"是个类似加速度的一个比值，应该是单位时间可以修订的功能数量吧！
- 易维护，纯粹就是个感性的度量指标，无法有统一标准的 囧rz...
不过，我认为代码的易于维护是可以度量的，而且必须考虑外界的条件和变化！因为，一但提及维护，就代表代码必须和外部条件进行交互并对应修订了！
所以，我感觉，代码的易维护程度，取决于可以持续维护以响应工程需求变化多长时间！
+ 如果到最后代码演变成再也不变的标准模块，可以长久的复用下去，那么代码是易维护的，因为不用再维护了；
+ 如果到最后谁也忍受不了，直接抛弃，那么代码不是易维护的，虽然不用再维护了，但是已经死亡了！
+ 这个逐渐趋向死亡的过程，时间越长，说明代码的可维护度越高 -
易维护的标准应只针对软件的设计,而熟悉度是针对开发人员而言的,对于任何代码的维护应建立在对当前代码框架的熟悉程度基础上,开发人员的层次不齐,熟悉代码结构的人员很容易就找到需要修正或变更逻辑的代码段,这是易维护性的一个前提,但不是衡量代码易维护性的标准,而是衡量人的标准,当然,软件设计架构的复杂度,也是影响熟悉程度的一个阻力,软件设计应实现低耦合,高内聚
-
一般来说，设计复杂度总是和业务复杂度成正比关系。当然不排除有的人用 EJB 写 helloworld，但是如果开发人员有意识要提高代码可维护性的话，这时候设计的复杂度就主要取决于业务的复杂度了。
-
同意Jason的说法.
易于维护对某一个项目而言在作出调整的同时是不允许牵一处而动全身的。
当然作到这点对于熟悉代码的人是很容易的,但是从开发团队的角度而言是要强调代码的耦合\内聚性的.毕竟开发团队的人员是在流动而项目本身则需要有开发人员不断的进行维护. -
如果还是原来深度参与的人来处理，不如叫修正、重构、改进，总之随便命名吧
换了人来处理才叫维护
从这个角度来说，可学习性和可维护性就是基本一致的了 -
我觉得可维护性指软件系统对现实世界的抽象程度，当然是一个合适的量度。
抽象程度太高，过度设计，学习的成本太高，维护起来未必轻松；
抽象程度太低，没有模块化、组件化，到处是散落的代码，同样难以维护。
可维护性的判断确实是一个比较难以量化的问题，甚至可以很主观。
如果想量化，需要找一个满足基本技术技能但未接触此系统的人（你不能找一个搞java的去维护c++的系统）去理解系统的业务,花多少时间和成本才能上手。当然什么叫上手，又是一个难以量化的东东。
13 条回复
关注此讨论 回复