预构和重构
by Ken Pugh
概述：
   预构已经引发了开发者中的一些讨论。一些开发者已经基于Amazon的编辑概要形成了相关的观点。不幸的是这种概要并没有经过我的同意，充斥着不代表预构的市场炒作。希望这篇文章可以澄清这个问题。

   预构是在华盛顿特区的软件开发会议的名为“志趣相同的人”的集会中演化而来的。Martin Fowler、Ron Jeffries、我以及其他几个人讨论了软件为何需要重构以及可以减少这种需求的手法。受到那个讨论的触动，我整理了一套创建软件的准则并命名为“预构”。
   根据Martin Fowler，重构是“改善现有代码设计的一种受控的技术。”“它通过应用一系列的代码变换达到这些，每一个变换都叫重构。”代码坏味道暗示重构。
   预构准则强调你在开始编码前要想的事情。重构是在你编好代码后所进行的代码变换。
   预构准则包括一些和代码变化直接关联的，其他一些则没有。一个常用的重构是提取方法。“策略和实现分离”的预构准则建议将方法组织成实施实现（计算客户购买总额）和实施策略（根据购买总额给客户折扣）的方法。 如果你在开发代码的时候想着这准则，你可能会发现你分离了很多方法，因此就需要较少的提取方法。分离策略和实现不是一个你可以机械执行的操作。这是一些你必须特意做的事情。带着意识地编码可以使得你的代码一开始就有较少的坏味道。
   其他一些预购准则不和代码变换相关。“最容易调试的代码就是没有写的代码”的准则建议你可以用Google作为开发工具。在你写每一行代码之前，利用google看下你要实现的功能是否已经在开源或商业软件中存在了。如果有的话，就签出它。你可能不要写一行代码就可以。如果该软件不能工作，你也有机会看看别人是怎么解决的。开发软件不仅仅是编写代码；它和交付解决方案相关，而不论这些是如何创建的。
   在预构中不会有大的前期设计。“考虑全貌”的原则不和大的设计相关。它建议你可以多花点时间调查你创建软件的环境。该环境（公司基础设施、J2EE或Web服务等）可能提供很多你不需要去开发或者可以建议你调整代码以适应框架的方法服务（安全或错误处理等）。
   遵循预构准则并不意味你可以不重构代码。这些准则可以让你避免代码臭味道。但代码有臭味道时候，重构它。在你开发过程中，你可以有关于整个项目的更多知识，这可以激发更多的新思想。正如准则中提到的，在每次发布后进行一次反省就可以直接帮助新的思想形成。
   敏捷和向客户交付可工作的软件相关。迭代和递增开发和用户交流是实现交付的关键原则。你可以使用多个工具达到该目标：重构，在既有代码上进行变换就是一个工具；预构，在编码前考虑这些事情是另外一个工具。