最近正在读《Prefactoring》一书，推荐一下，是这次JOLT大奖震撼大奖作品，电子版已经有下载了，迟些时候发心得上来，大家讨论下。
本书主要的观点是：根据自己或他人多年的软件开发经验，整理成开发项目时的指导方针，以利于未来项目启始时做为遵循的准则。它与重构的差别主要在于执行的时间点，Prefactoring是在项目开始前就先行思考，并非在项目执行期间才发生。 下面转有关的书评
早从1999年Martin Fowler的著作至今，重构（Refactoring）似乎已经成为提升软件质量的重要观念，但软件项目常常会因为时程压力及人力不足的现实问题，在项目执行的过程中进行Refactoring是很难被允许的。以项目管理的观念看来，这是需要花费时间与金钱的。故在架构设计及程序撰写上，这样的观念就相对地不被重视，程序开发人员也都以「只要将功能开发出来」的想法来运作。
重构的实现较易在软件产品研发上，落实在版本更新的规划中，不过产品规划的时程也不见得允许重构，因为Refactoring不会改变任何外部功能；而依客户需求量身订做的客制化软件项目，甚至涉及到系统整合的案例，则更难以将重构落实在项目中。
累积预防经验有助于日后项目发展
有鉴于Refactoring不易落实，所以一个适应性的做法－Prefactoring（预构）也许是个另类的解决方式。作者Ken Pugh提出这样的观念，根据自己或他人多年的软件开发经验，整理成开发项目时的指导方针，以利于未来项目启始时做为遵循的准则。它与重构的差别主要在于执行的时间点，Prefactoring是在项目开始前就先行思考，并非在项目执行期间才发生。
这里的指导方针有绝大部份跟一般基本的设计原则（像是OOAD的特性）相符，而其它的方针则主要围绕在分析抽象化（Extreme Abstraction），设计分离（Extreme Separation），提供可读性（Extreme Readability），以及接口设计（Interface）几个重点上。
抽象化设计其实已经是对象导件分析设计中的重要观念，强调「做什么（What）」而非「如何去做（How）」。所以在这个过程中，很难意会到实作时的细节，容易造成分析阶段到设计阶段时实现（Realization）的落差。针对这个问题，本书建议在抽象化设计时搭配雏型系统（Prototype）的使用，而在设计过程中使用与特定式语言与无关的的方式，采OOAD之标准原则（像是Class、Interface、Exception等）来进行设计。
分离设计最常见的方式，便是将操作画面的呈现与商业逻辑，以不同的组件各司其职。在日后需求变动时，不会牵一发而动全身；而为了日后维护容易，写出来的程序代码不仅是给计算机看，也要让人能轻易地看得懂。本书建议最理想的程序是连您的客户都看得懂。
预构强调软件开发流程与方法
本书的内容共分成十七个章节，作者以开发一套CD出租店系统的虚拟故事为主轴，说明在进行一项软件项目时会面临到的课题。开宗明义不免俗地简介Prefactoring的观念以及其基本方针，接下来便从与老板Sam聊起他理想中的系统应该长什么样子开始，文中不时穿插主角与客户之间的对话，活生生地如同您在与客户之间的沟通互动。
为了精确掌握使用者在想什么，首先厘清字词明确的描述（光CDTitle、CDRelease、CDDisc的定义就引起一番争论），再将相关的字词分类归纳，转化成对象的方式来设计。这里头像是一些常见对象设计原则就会被讨论到，像是多形（Polymorphism）、抽象化数据型态（Abstract Data Type）等等，甚至直接用一个雏型系统（Prototype）来与使用者确认需求内容的正确性。
虽然设计必须奉行理论，但还是有无法被落实的状况发生。起因可能是与使用者想法的不一致，对事物解读的误解。但这些软件开发的准则并不是标准答案，就像是开车一样，每个人都有自己的风格，重要的是让自己面临类似问题时能快速且有效地解决。而且每个准则都有适用的使用时机，而非一条鞭式地适用于任何状况。
就本书的内容看来，还是在强调软件开发流程与方法的重要性。在每个章节中作者以座右铭的方式提醒需要强调的重点，并在书末的附录中整理了所有的原则。如果了解对象导向分析设计的重要，同时亦希望用省时省钱的方法来进行项目，本书也许可以提供一些想法，虽然无法保证从此不需要Refactoring，但次数的减少是可以肯定的。
本书主要的观点是：根据自己或他人多年的软件开发经验，整理成开发项目时的指导方针，以利于未来项目启始时做为遵循的准则。它与重构的差别主要在于执行的时间点，Prefactoring是在项目开始前就先行思考，并非在项目执行期间才发生。 下面转有关的书评
早从1999年Martin Fowler的著作至今，重构（Refactoring）似乎已经成为提升软件质量的重要观念，但软件项目常常会因为时程压力及人力不足的现实问题，在项目执行的过程中进行Refactoring是很难被允许的。以项目管理的观念看来，这是需要花费时间与金钱的。故在架构设计及程序撰写上，这样的观念就相对地不被重视，程序开发人员也都以「只要将功能开发出来」的想法来运作。
重构的实现较易在软件产品研发上，落实在版本更新的规划中，不过产品规划的时程也不见得允许重构，因为Refactoring不会改变任何外部功能；而依客户需求量身订做的客制化软件项目，甚至涉及到系统整合的案例，则更难以将重构落实在项目中。
累积预防经验有助于日后项目发展
有鉴于Refactoring不易落实，所以一个适应性的做法－Prefactoring（预构）也许是个另类的解决方式。作者Ken Pugh提出这样的观念，根据自己或他人多年的软件开发经验，整理成开发项目时的指导方针，以利于未来项目启始时做为遵循的准则。它与重构的差别主要在于执行的时间点，Prefactoring是在项目开始前就先行思考，并非在项目执行期间才发生。
这里的指导方针有绝大部份跟一般基本的设计原则（像是OOAD的特性）相符，而其它的方针则主要围绕在分析抽象化（Extreme Abstraction），设计分离（Extreme Separation），提供可读性（Extreme Readability），以及接口设计（Interface）几个重点上。
抽象化设计其实已经是对象导件分析设计中的重要观念，强调「做什么（What）」而非「如何去做（How）」。所以在这个过程中，很难意会到实作时的细节，容易造成分析阶段到设计阶段时实现（Realization）的落差。针对这个问题，本书建议在抽象化设计时搭配雏型系统（Prototype）的使用，而在设计过程中使用与特定式语言与无关的的方式，采OOAD之标准原则（像是Class、Interface、Exception等）来进行设计。
分离设计最常见的方式，便是将操作画面的呈现与商业逻辑，以不同的组件各司其职。在日后需求变动时，不会牵一发而动全身；而为了日后维护容易，写出来的程序代码不仅是给计算机看，也要让人能轻易地看得懂。本书建议最理想的程序是连您的客户都看得懂。
预构强调软件开发流程与方法
本书的内容共分成十七个章节，作者以开发一套CD出租店系统的虚拟故事为主轴，说明在进行一项软件项目时会面临到的课题。开宗明义不免俗地简介Prefactoring的观念以及其基本方针，接下来便从与老板Sam聊起他理想中的系统应该长什么样子开始，文中不时穿插主角与客户之间的对话，活生生地如同您在与客户之间的沟通互动。
为了精确掌握使用者在想什么，首先厘清字词明确的描述（光CDTitle、CDRelease、CDDisc的定义就引起一番争论），再将相关的字词分类归纳，转化成对象的方式来设计。这里头像是一些常见对象设计原则就会被讨论到，像是多形（Polymorphism）、抽象化数据型态（Abstract Data Type）等等，甚至直接用一个雏型系统（Prototype）来与使用者确认需求内容的正确性。
虽然设计必须奉行理论，但还是有无法被落实的状况发生。起因可能是与使用者想法的不一致，对事物解读的误解。但这些软件开发的准则并不是标准答案，就像是开车一样，每个人都有自己的风格，重要的是让自己面临类似问题时能快速且有效地解决。而且每个准则都有适用的使用时机，而非一条鞭式地适用于任何状况。
就本书的内容看来，还是在强调软件开发流程与方法的重要性。在每个章节中作者以座右铭的方式提醒需要强调的重点，并在书末的附录中整理了所有的原则。如果了解对象导向分析设计的重要，同时亦希望用省时省钱的方法来进行项目，本书也许可以提供一些想法，虽然无法保证从此不需要Refactoring，但次数的减少是可以肯定的。
