Prefactoring——Introduction
听到有人说《Prefactoring》是一本好书：“能提升数十年的功力”，虽然过于夸张，但也说明这本书还是值得一读的，不然怎么会得了JOLT大奖呢？如作者所言，读本书需要一定的开发经验的积累，否则茫然不知为何，收获不大。
最近花时间看了看《Prefactoring》，把所得记录下来。
在软件开发中，我们常常谈论重构（Refactoring），它已经是一个被广泛认可的开发方法，它可以提高软件的品质；而且很多开发者在开发中也找到了可以省事的理由：“现在就这样简单处理吧，以后再进行重构”，可事实上，他可能永远都没有机会和功夫去做重构了。的确，每个项目和产品都有成本（资金和人力）和时间的限制，“重构”在很多项目中往往只是一个概念，而没有实践。
针对这样的现状，Ken Pugh提出了Prefactoring——防患于未然，在项目开始前预先进行思考，三思而后行；根据既有的经验和指导原则来避免落入软件开发中诸多的陷阱，在开始编码前就预先做出好的设计来，以降低重构的代价——这似乎并没有多少新意，因为在历史的长河中，人们向来都会以史为鉴；而诸多Design Principle/Design Pattern/XXX Driven Development都告诉我们如何使得代码能适应一定的变化，易于调整和修改。不过，作者根据自己多年丰富的经验，列出了诸多的指导原则，强调了软件开发流程的重要性，告诉我们如何在开发中应用一些原则来减少我们重构的次数，降低重构的代价，毕竟重构可能是要付出很大的代价的。本书也从侧面反映了开发团队中需要有经验丰富的开发者进行指导，人的作用不言自明，和《软件工艺》中所云暗合，Ken Pugh正是在向我们传授他的“技艺”。
预构和重构可说是关系密切：
1、 重构是在写代码之后进行的，而预构则是在写代码之前。
2、 重构中的一个重要方法是Extract Method，而预构中的“Separate Policy”则可以帮助我们少作Extract Method。
3、 预构和重构一样不强调做big design。但是预构的原则告诉我们应该花一些时间去调查软件的环境（包括业务和技术等方面）。
4、 预构不反对重构，而是致力于减少重构的次数，降低重构的代价。
5、 重构关注的是代码的code transformations，而预构则不止于此。预构还建议我们尽量利于可以利用的东西，比如一些优秀的open source的project，而不是一开始就自己写每一行代码。
预构看起来有些像关于设计的指导原则，而并没有到达方法学的高度，作者强调了设计和开发过程的重要性，尤其是设计的重要性，这点和RUP倒是有共同的地方——预先做出好的设计，好的设计能让项目大大降低技术风险。
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。