infoq上总是有不错的文档
就我个人的经验，作为程序员总是觉得别人的代码不好，有冲动把他重构，但是作为管理者，
则更多需要考虑投入产出的问题。
从整体架构上来说，完全重构的风险太大，局部进行重构优化是王道。
from: http://www.infoq.com/cn/news/2008/05/software-rewrite-4-architecture
由于软件应对需求变化的能力越来越差，通过更新架构进行软件重建的做法变得越来越有吸引力。这种做法是相当有风险的，因此具体策略的选择显得相当重要。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的经验，他认为为了改变语言而重写软件是不值得的。他还添加了一些关于这个问题的其它见解，比如在人力资源方面的考虑，尤其是当由于现有代码 的低质量而决定重建的时候。他更进一步地强调了重构的价值，认为重构能超越代码，还认为由团队获得的经验可用于重构，比如用户模型。