应用云平台的可用性——从新浪SAE看云平台设计
云计算平台的可用性，相比传统互联网服务而言，更加复杂和困难，也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台，以及对云计算的用户提出了建议。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
争论：是否应该避免架构重写？
作者 Sadek Drobi 译者 王丽娟 发布于 2008年5月21日
由于软件应对需求变化的能力越来越差，通过更新架构进行软件重建的做法变得越来越有吸引力。这种做法是相当有风险的，因此具体策略的选择显得相当重要。Andy Singelton最近的一篇博客就此问题进行了讨论。文章认为成本、技术复杂性、潜在的商业风险是在进行战略选择时不得不认真权衡的三个因素。对此他提出了三种解决方案，并简要分析了每种方法的优缺点：
- “原型和延展”方案，完全编写新的软件；
- “增量开发”方案，在仍然使用原有代码集的基础上，更新部分组件并进行重构；
- “购买”方案，购买能满足新需求的软件。
然而，几位博客作者却认为第一种选择——从无到有地重写软件——无论如何都应该避免。早在2000年Netscape 6发布之后，Joel Spolsky就不提倡这种方法。 他形容Netscape重写代码的决定“简直就是一个无比失误的战略性错误”，同时还举了一些犯类似“错误”的例子：dBase、Borland的 Quattro Pro、以及Microsoft的Pyramid项目。Joel认为在许多案例中做出需要重写软件的判断带有一定的主观性，其往往是由重用代码时遇到困难造成的。此外，他认为冗长的测试和缺陷修复过程在很大程度上造成了代码可读性低下：
新代码优于旧代码的观点显然是荒谬的。旧代码毕竟已经过测试并投入使用。大量缺陷已经被发现并被修复。[……]
回头再看看那个两页长的函数。是的，我知道它只完成了显示窗口这个简单功能，但是它已经增加了一些东西，没有人知道是为什么。好，我来告诉你为什么：它们是对缺陷的修复。[……]
这些缺陷的每一个都是在实际使用了数周之后才被发现的。[……]
当你扔掉代码并从零开始的时候，你就是随手扔掉了所有这些认识。这些不断收集到的对缺陷的收集和修复可都是多年编程的积累！
Joel Spolsky还强调了重写项目存在的潜在商业风险，认为其可能削弱团队应对新出现市场需求的能力。因此他认为，即使旧的代码集就架构而言真的很糟糕，也应该努力清理代码、重构、修改接口，而不是进行全面的重写。
重写软件的一个常见理由是，吸取第一次发布后的经验教训后，团队会把工作做得更好。但是，Joel Spolsky强调了开发团队极有可能会随时间而发生变化这一事实。正如最近回应了Spolsky文章的Dharmesh Shah所强调的，市场情况也很有可能发生改变。
Dharmesh Shah列出了其它一些进行软件重写的理由——比如说差的代码集，或是最初对平台或语言的错误选择——同时他也指出这个做法的局限性。他详细说明了为什么要抵制进行重写的趋势：开发过程难免要比预期的要长；不能对现有客户提出的潜在市场变化和要求做出响应，这存在很大的风险，甚至有可能会削弱软件的竞争优势；而且有不同的替代性解决办法，例如重构，重构在减少前面那些风险的同时，对清理代码也很有帮助。Dharmesh Shah认为重写只在少数几种情况下是可行的：如果最初的技术选择阻碍你的商业成功，或者技术前景有巨大的转变——比如从客户端-服务器到基于Web的计算——而你的软件又无法适应它。
然而Bob Warfield对Dharmesh Shah的帖子进行了评论， 根据其把Quattro Pro从Modula-2编译器移植到Turbo Pascal的经验，他认为为了改变语言而重写软件是不值得的。他还添加了一些关于这个问题的其它见解，比如在人力资源方面的考虑，尤其是当由于现有代码 的低质量而决定重建的时候。他更进一步地强调了重构的价值，认为重构能超越代码，还认为由团队获得的经验可用于重构，比如用户模型。
查看英文原文：Debate: Should Architecture Rewrite be Avoided?
译者 王丽娟 王丽娟，04年大学毕业后持续从事Java EE中间件产品的开发，现在主要关注Java技术及中间件产品在云计算环境中的发展趋势和应用。
重写，也许只是想起来挺美。
发表人
Xiang Ran
发表于
Re: 重写，也许只是想起来挺美。
发表人
jony hu
发表于
重构，有的时候有心无力
发表人
Huang Joe
发表于
Re: 重构，有的时候有心无力
发表人
小刀 凉粉
发表于
Re: 重构，有的时候有心无力
发表人
Faihou Che
发表于
随时重构
发表人
zhang yang
发表于
-
目前，我所做过的项目，有过完全推倒重来，有过部分模块，或者结构完全重写的。但是没有发现一个例子，是重写后带来的价值比不重写多的。唯一的可能就是让支持重写的开发人员觉得似乎代码变的顺眼的，但是，其实，过阵子再看，还是照样腐烂、发霉。。。所以，重构还是王道。。。现在一听说谁嚷嚷重写，总觉得丫不成熟。当然，我不久前也经常推倒自己的工作重来重写。但现在觉得，其实重写也真没什么好处。有这时间，基于原来的版本去重构，去解依赖，也许质量早已经提高的超乎你想象了。只不过心理上来说，拿出一张白纸去画画，总觉得能画出更好的……但其实，真指不定结果是什么。
-
有时候重构的成本不一定比重写小，当你面对十几万行已经腐烂的源代码的时候。无论选择重写还是还是重构，代价都很高
-
所以重构应该是随时进行的,不能等到最后了才重构
-
That's why we need to balance the cost and revenue
-
软件演化，要针对商业价值和技术价值来决定演化的方向。在这2个因素的二维空间里会有不同的应对策略。如果商业价值和技术价值都很低，那重写或购买现成的解决方案是最好的选择。
-
那只能说明你的能力根本就没有提高，重不重写的结果都一样，并不能说明重构就一定比重写好！当结构或者代码逻辑严重腐烂时，往往重写要比重构来的快速和安全
6 条回复
关注此讨论 回复