1.2 何时重构
应该在什么时候重构呢？在清除和处理过时代码的过程中，何时才算是到了添加新特性的时机？这个问题可能有几个答案，但它们之间并不是互斥的。
重构的第一个时机出现在进行任何重新设计之前。如果你的网站碰到需要重新开发的情况，首要任务是掌控它的内容。此时重构的第一个好处显而易见，你将为新设计的实现创建更牢固的基础。良构、组织良好的页面更容易重新设计样式。
重新设计之前进行重构的第二个好处是，重构过程能帮助开发者熟悉网站。你将会了解页面位置，它们在网站层次上是如何组合起来的，以及哪些是跨页面的通用元素等。同时，还有可能对重新设计产生前所未有的新想法。别急着去实现，把想法都先记录下来（放到问题追踪系统中则更好），在重构完成之后，就可以着手实现了。重构是十分重要的工具，可以帮助网站开发者加速网站的开发。如果他们以前未参与开发这个需要重构的网站，重构的过程会帮助他们了解网站的细节。就算是为网站工作已经超过了10年，重构也能提醒他们一些已经遗忘的东西。无论是哪种情况，重构都能帮助开发者熟悉网站。
新功能可能只出现在新页面，甚至可能只出现在全新的网站上。如果跟旧网站仍有关联，你需要检查一下是否有可借鉴或可重用的东西。样式、图片、脚本和模板或许都可重用。这样确实可以帮你保持新旧网站具有一致的外观。但如果需重用的部分有问题，则应事先清理一番。基于类似的理由，在开发任何基于旧项目的新项目之前，都应该好好揣摩一下重构。比如，如果要实现“一键式购物（one-click shopping）”⑧，先要保证旧的购物车能够满足需要。如果法律部门要求在每一个页面的底部加上限制性附属细则（small print），还得看看每个页面是否都有一个固定的位置可以方便地记录这些信息。没有必要重构所有的东西，但这种改动总是有助于在网站中集成新内容。
最后，或许你会考虑半连续式重构（semicontinuous refactoring）。如果碰到难以一下子解决的问题，不要连续两周无动于衷，在这期间看看还有什么地方是可以重构的。就算是不能解决大问题，也应该马上去做些力所能及的事情来修复一些小问题。尽可能使用敏捷开发方式，编写小部分，测试小部分，重构小部分，如此反复。尽管很多项目都要基于一大堆不良和过时的代码开发，不过如果有未完工项目的话，一定要先保证不让它变成又一个烂码基。一旦看到自己在重复相同的代码，可以把它提取到外部模板或样式表中去。当发现原来的HTML编写者使用了废弃的元素，应该马上使用CSS取而代之（并利用这个机会教育一下这个编写者为何要这么做）。一连串小的但有效的变化累积起来就会带来巨大的效果。
无论做什么，都不要因追求完美而忽视小的改进（勿以善小而不为）。如果眼下的时间足够做一点儿重构，那就只做一点儿。以后有时间还可以做得更多。整体性的重新设计虽然惹人注目令人难忘，但不积跬步又何以至千里？你的目标应该是让代码每天都有新变化。这样坚持几个月，你就会拥有可以骄傲地向人夸耀的清晰代码。