现在的位置: 首页 > 综合 > 正文

正在读《Prefactoring》一书,推荐下

2014年01月23日 ⁄ 综合 ⁄ 共 1834字 ⁄ 字号 评论关闭

最近正在读《Prefactoring》一书,推荐一下,是这次JOLT大奖震撼大奖作品,电子版已经有下载了,迟些时候发心得上来,大家讨论下。
本书主要的观点是:根据自己或他人多年的软件开发经验,整理成开发项目时的指导方针,以利于未来项目启始时做为遵循的准则。它与重构的差别主要在于执行的时间点,Prefactoring是在项目开始前就先行思考,并非在项目执行期间才发生。 下面转有关的书评
   
早从1999Martin Fowler的著作至今,重构(Refactoring)似乎已经成为提升软件质量的重要观念,但软件项目常常会因为时程压力及人力不足的现实问题,在项目执行的过程中进行Refactoring是很难被允许的。以项目管理的观念看来,这是需要花费时间与金钱的。故在架构设计及程序撰写上,这样的观念就相对地不被重视,程序开发人员也都以「只要将功能开发出来」的想法来运作。

重构的实现较易在软件产品研发上,落实在版本更新的规划中,不过产品规划的时程也不见得允许重构,因为Refactoring不会改变任何外部功能;而依客户需求量身订做的客制化软件项目,甚至涉及到系统整合的案例,则更难以将重构落实在项目中。

累积预防经验有助于日后项目发展

有鉴于Refactoring不易落实,所以一个适应性的做法-Prefactoring(预构)也许是个另类的解决方式。作者Ken Pugh提出这样的观念,根据自己或他人多年的软件开发经验,整理成开发项目时的指导方针,以利于未来项目启始时做为遵循的准则。它与重构的差别主要在于执行的时间点,Prefactoring是在项目开始前就先行思考,并非在项目执行期间才发生。

这里的指导方针有绝大部份跟一般基本的设计原则(像是OOAD的特性)相符,而其它的方针则主要围绕在分析抽象化(Extreme Abstraction),设计分离(Extreme Separation),提供可读性(Extreme Readability),以及接口设计(Interface)几个重点上。

抽象化设计其实已经是对象导件分析设计中的重要观念,强调「做什么(What)」而非「如何去做(How)」。所以在这个过程中,很难意会到实作时的细节,容易造成分析阶段到设计阶段时实现(Realization)的落差。针对这个问题,本书建议在抽象化设计时搭配雏型系统(Prototype)的使用,而在设计过程中使用与特定式语言与无关的的方式,采OOAD之标准原则(像是ClassInterfaceException等)来进行设计。

分离设计最常见的方式,便是将操作画面的呈现与商业逻辑,以不同的组件各司其职。在日后需求变动时,不会牵一发而动全身;而为了日后维护容易,写出来的程序代码不仅是给计算机看,也要让人能轻易地看得懂。本书建议最理想的程序是连您的客户都看得懂。

预构强调软件开发流程与方法

本书的内容共分成十七个章节,作者以开发一套CD出租店系统的虚拟故事为主轴,说明在进行一项软件项目时会面临到的课题。开宗明义不免俗地简介Prefactoring的观念以及其基本方针,接下来便从与老板Sam聊起他理想中的系统应该长什么样子开始,文中不时穿插主角与客户之间的对话,活生生地如同您在与客户之间的沟通互动。

为了精确掌握使用者在想什么,首先厘清字词明确的描述(光CDTitleCDReleaseCDDisc的定义就引起一番争论),再将相关的字词分类归纳,转化成对象的方式来设计。这里头像是一些常见对象设计原则就会被讨论到,像是多形(Polymorphism)、抽象化数据型态(Abstract Data Type)等等,甚至直接用一个雏型系统(Prototype)来与使用者确认需求内容的正确性。

虽然设计必须奉行理论,但还是有无法被落实的状况发生。起因可能是与使用者想法的不一致,对事物解读的误解。但这些软件开发的准则并不是标准答案,就像是开车一样,每个人都有自己的风格,重要的是让自己面临类似问题时能快速且有效地解决。而且每个准则都有适用的使用时机,而非一条鞭式地适用于任何状况。

就本书的内容看来,还是在强调软件开发流程与方法的重要性。在每个章节中作者以座右铭的方式提醒需要强调的重点,并在书末的附录中整理了所有的原则。如果了解对象导向分析设计的重要,同时亦希望用省时省钱的方法来进行项目,本书也许可以提供一些想法,虽然无法保证从此不需要Refactoring,但次数的减少是可以肯定的。

抱歉!评论已关闭.