重构？重写？
May 23rd, 2008
InfoQ: 争论：是否应该避免架构重写？
Joel认为在许多案例中做出需要重写软件的判断带有一定的主观性，其往往是由重用代码时遇到困难造成的。…即使旧的代码集就架构而言真的很糟糕，也应该努力清理代码、重构、修改接口，而不是进行全面的重写。
一种常见的担心是重构需要的成本不比重写来得小。第一，这是真的。基于一些真实的大规模重构得到的经验，重构遗留系统和重写需要的开发工作量基本上正好相等。不过第二，如果选择重构而不重写，可以确保原来的功能不被破坏。其实真实的担心往往并不是成本，而是效果：如果重构做到一半做不下去了再开始重写，那才是最坏的情况。所以真正解决这个问题需要切实可行的重构策略和手段，例如我在 这篇文章 里介绍的方法。
有很多这样的案例：面对着一堆遗留代码，人们说“那就既往不咎从头来过吧”。但事实证明从头设计一个优雅的架构于是软件就可以在将来的五年十年中保持良好的扩展性这样美好的愿望从来就没有实现过。因为，软件技术的发展是很快的，代码质量的腐化是很快的。良好的扩展性只有靠持续不断强力有效的质量保证才能做到。至于起点，重构还是重写，影响并不大──如果不介意重写的大风险的话。
在大型遗留系统基础上运作重构项目
April 4th, 2008
http://blog.csdn.net/gigix/archive/2008/04/04/2249120.aspx
本文以ThoughtWorks中国公司与客户合作的咨询项目为背景，为读者介绍如何在一个大型遗留系统的基础上组织和运作重构项目，从而切实有效地改善系统质量。eMAN是客户的一个核心业务平台。该产品采用了典型的C/S结构，负责处理大量请求和计算的后台部分采用C++开发，负责响应用户操作和处理业务逻辑的前台部分采用Java开发；此外该产品还计划在新版本中提供基于Web的前台，这部分也采用Java开发。
在ThoughtWorks为该产品的开发团队提供咨询时，eMAN产品已经发布了十多个版本，最新版本代码量超过40万行，其中15万行是Java代码。一次又一次的赶工给它留下了大量的“技术债”：系统缺乏测试，代码质量低劣，“copy & paste”的痕迹比比皆是，维护和新功能开发举步维艰。我们这个咨询项目的主要目标之一就是为这个产品找出重构的办法。
