書評－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

Ken Pugh /著
O'Reilly出版
售價：29.95美元
推薦：Amazon四顆星

《作者簡介》陳宏一

交通大學資訊管理研究所碩士，現任億訊國際資深顧問。曾任職於南亞科技資訊部工程師、資迅人網路研發副理、艾群科技產品研發部經理，專精於OOAD、J2EE 相關技術、Open Source、資料庫設計、軟體開發流程及專案管理等；取得SCJP、SCWCD、SCJD、SCEA、ITIL等認證。曾經歷大型社群及電子商務網站、WAP/3G行動加值服務、CTI/CRM客服系統架構規劃設計等。