愛德華日誌

三到五月間陸續寫的一點小記事。當初原本的標題是「軟體開發未來進行式」，到現在，有些已成為事實，所以就把標題改了。

• 各種應用軟體，會更傾向於以 widgets、plugins或 extensions 的方式，整合於功一較大的應用環境之中 --> 在大多時候，你不再需要開發出像 MS Office 這樣 stand-alone 的大程式
• Client 端的應用程式容器：Firefox, Eclipse, NetBeans, 以及依附於作業系統 desktop 各種 widget containers 如 Yahoo, Google desktop.
• 往後 Clinet 端應用程式，既使不見得與 Web 的應用有絕對關係，但仍會採用與 Web 相關的技術開發，如 Javascript, XUL, Java WebStarts, Flex(2) 等
• Server 端的應用程式，會採用可擴充與整合的模組式設計 --> 這裡的整合，是指像 drupal 這樣應用層級的整合，而不只是像過去的 Application Server，只是把不同功能的應用，deploy 到同一台伺服器上而已
• Server 端系統基礎架構
• • Database, Application Cluster, Web Tier, HTML/Ajax/SVG Thin Client
  • Grid Enviroment, Web Tier, HTML/Ajax/SVG Thin Client
• 分散共有的未來式架構
  
• • SOA + Web Tier (Mash-up), HTML/Ajax/SVG Thin Client
  • 大融合：SOA Web Grid
    
• Application Builder 與 Production Enviroment 的整合更良好。採用線上即時組裝與試行的方式來開發系統，針對需求直接測試解決方案。在大部分情況下，(採用UML)從頭進行系統分析與設計的開發方式，將不再需要。

與其說這是一篇對 2006 年的預測，不如說這份清單是我看到，目前正在發生的事情。不過既使不是預測，其中也充滿了個人觀點，也許你會有不同的看法，歡迎交流囉!

關於應用系統的整合與開發

SOA, SOA, SOA... 今年炒熱一整年的 SOA(服務導向架構)，明年還會繼續，而其相關的應用與資源 - ESB, JBI, SCA(Service Component Architecture), SDO(Service Data Objects)...，於2006年會更加成熟，而且實際的應用於產業中。會有許多產品宣告它是 SOA Enabled。

相較於 SOA 的炒作的熱絡與實質應用的成功，MDA(Model Driven Architecture)會遭遇理論與實質應用上的挑戰。為什麼這裡我會將 MDA 與 SOA 這兩個看似不相關的東西擺在一起，簡而言之，是他們對於所要解決的問題，有高度的相似性。只是採用的作法完全不同，這可以是另一個故事。

流程與方法學在政府及顧問公司的推波助瀾下更受重視

PMP, Project+, CMMI… 簡而言之，既然對大家都有好處(個人可以獲得專業上的認證，顧問公司及教育訓練機構可以賺到錢，公司可以改善組織流程，進入所謂的贏者圈)，這麼好的 Business Story, 還會有誰來反對? 除了錢的問題…

Ajax Application向傳統網頁應用程式進軍，有些桌面應用程式也改以類 Ajax 技術實作

今年 (2005年) 可說是 Ajax Application 大放異彩的一年，一些網路服務應用先趨已經為了 Ajax Application 作了良好的示範。而在 2006 年，將會有更多軟體開發工具、套件實質支援 Ajax。另外一些傳統的Web 應用程式，像是 CMS(內容管理系統)、Portal(以及其上的 portlet)，Report Querier … 也都會有 Ajax 應用出現。甚至一些原本的桌面應用，像是專業的資料分析、探勘程式，也都可能出現"類 Ajax"版本。

專門為 Firefox 設計的網站應用程式

以前在瀏覽網站時，常會發現某些網站是 for IE only，相信在今後也會有 for Firefox only 的網站。與過去for XXX瀏覽器網站最大的不同點是，這些for Firefox only的網站，會充份利用Firefox 所提供的Extension, XUL, Canvas功能，將網站與瀏覽器無縫整合在一起，使整個網站的瀏覽體驗，更像是在使用桌面應用程式。

VoIP 持繼發熱

網路電話持續加溫，傳統電話業務會因此而停止成長。Skype 加入NetMeeting的功能，eBay 將透過 Skype 的NetMeeting功能提供線上影音即時拍賣。

Eclipse 仍為開放工具平台的實質標準

雖然 NetBeans 越做越好，在穩定度與易用度上甚且超越 Eclipse，但仍然無法力挽狂瀾。其中一個很大的原因是，Eclipse 已成為開放工具平台的實質標準。你可以在 Eclipse 上找到 PHP, Python, Perl, C/C++… 等其他語言的 IDE plugins，這是 NetBeans 無法追趕得上的。

軟體開發廠商生存更加困難

因為有越來越多各式各樣的套裝軟體出現，代表著有越來越多的"大眾化需求"被滿足。未來新興的軟體公司，極可能會面臨沒有應用程式可寫的壓力。因為你能想到的應用程式，都被別人開發完成了。

一般軟體廠商，面對這種情勢，有三件事可以做

1. 要以專案模式，朝客製化方向前進
2. 把握特殊領域應用，開發利基市場
3. 尋找過人的創意，解決市場尚未被滿足的需求，或創造出市場需求。 有創意的廠商能迅速脫穎而出。

軟體服務化，成為廠商延伸市場觸角的法寶

接續前面所提的 Ajax Application 中的推想，有許多傳統上應該是執行於個人電腦上的桌面應用程式，會在技術成熟，以及"商業策略"的因素下轉而Web化。將傳統桌面軟體 Web化，除了可以延伸市場觸角外，還可以支援許多傳統上難以達到的商業策略。諸如提供客戶 live experience, 改變軟體計價方式，迅速收集客戶回應等。

接續前面「軟體開發廠商生存更加困難」的話題，即使傳統軟體廠商想朝向軟體服務化方向走，前方的道路依然充滿困難… 因為這方面做的最好的，依舊是現有優勢者： Google, Yahoo!及微軟三家公司霸占著大多數的線上服務市場；而IBM, Oracle 等老大哥也是策略創新的高手。想冒出頭來的新興廠商，只能在不到 10% 的市場機會中尋找生存的空隙。

Drupal 成為最受歡迎的 CMS/Protal 系統

Drupal是一套以 PHP 開發、模組化、架構簡易，功能卻強大的內容管理架站系統。在Java開發者的眼中，這樣的系統不但不物件導向（完全用callback 方法實作），甚至還不夠格稱上 3-tier system（因為 drupal 事實上就是 web-tier + DB），它的DB存取還不用DAO、Model Object的觀念呢…，可怎樣，功能就是很強，就是可以加入無限擴充的模組，要氣死物件導向派的高手了。

不可諱言的，我自然也是Java社群的一員。初次觀看drupal程式碼時，還是覺得PHP實在不是優美的語言，drupal 程式碼中更夾雜著SQL與HTML（附帶一提，drupal可能已是PHP 內容管理系統裡面程式碼寫的最優雅的了。以PHP的標準，如果說 Mambo 是金玉其外，那 drupal 則是文質彬彬）。

無論如何，在Mambo分家，而Nuke、Xoops在分支眾多的情況下，Drupal已然成為 PHP CMS 中開發社群凝聚力最強的一支隊伍。相信在2006年會有更多開發人員為 drupal 建立外掛模組，使drupal成為 Apache+MySQL+PHP 上實質的的應用軟體開發、整合平台。

OpenOffice 會吸收更多的死忠支持者，就如有一群人死忠支持 Firefox 一樣

更多政府機構會實質採用 OpenOffice, 更多學校會採用 OpenOffice 授課。

微軟會成為智慧型手機、PDA、家庭數位娛樂電器的實質贏家

這已是事實，不用多說。

應用程式繼續朝向精簡型架構設計，EJB 3.0 叫好不叫座

(雖然Jini大力推EJB 3.0)

這是一個最重視物件導向的年代，也是最不重視物件導向的年代。舉例來說吧，現在的Java應用程式框架，強調要支持POJO的觀念，可是事實上，MVC卻大行其道，MVC是物件導向嗎？有人打圓場，說這叫separation of concerns。再以前面的 drupal 實作為例，callback不算物件導向吧！可是它卻是標準的 IoC (Inversion of Control)，符合 Hollywood principle -"Don't call me, I will call you"。

"物件導向不再無限上綱"。這句話一出，怕是要引起不小的爭論了。讓我簡單的說吧! 在未來的應用系統開發，你所強調的是架構，是服務，是功能，是流程。而物件，則是堆砌這一切的基本單元。也就是說，你只有在構築"程式的基本單元"時，才會採用物件導向的思維模式。當你往上堆砌系統，或一開始即採用架構導向系統開發方法(Architecture Oriented System Development)時，比較適當的思維模式，是將系統看作一部"機器"，你考慮的應當是系統各部元件之間的連結，彼此間如何互動，最後才是各部元件各自的角色與職責。

這與傳統的物件導向方法的差異是，這樣的方法是由整個系統，由整體到部份，由外往內，由多數到單一，再由單一推進至物件裡面。而不是一開始就著重在各個功能物件上。甚至在各功能物件之間尚未完成定義前，就必須先設計整個系統的訊息交換機制。要深入探討，這又是另一個故事，就此打住。

JeffHung 在他的 Blog 裡問我有關 XPlanner 的使用心得。老實講心得都是斷斷續續的，沒經過通盤的思考，而且有些都是一些自己使用上的旁門左道，不見得是標準用法。不論如何，還是把它整理出來，供有心人參考。

XPlanner 的基本觀念

• XPlanner 是一套支援 XP(Extreme Programming; 終極製程) 的規劃及追蹤軟體
• 在 XPlanner 中，你可以建立許多的使用者與專案，每個使用者在每個專案中可以有不同的權限
• 一個專案可以視為一套產品的開發過程，當然也可以對應到與顧客合作進行的軟體客製化專案
• XPlanner 在專案層級下設有迭代 (Iteration)，基本上一個專案應該要有許多 features 或 requirements。透過迭代，你可以安排要將哪些 features 放在哪個迭代，而將另一些 feature 放在另一個迭代。開發時間越早的迭代，應該包含專案越核心的功能，或是較為重要的功能。而後面的迭代則放入選擇性的功能。
• 迭代層級裡面放置使用者故事 (user stories)。使用者故事用來代表一個使用者可了解的需求，應該是一組獨立，且不可分割的功能。使用者故事同時也用來作為工時估算的單位。決定一個迭 代裡要有哪些使用者故事、要把哪個使用者故事放在哪個迭代的過程，就是發行規劃 (release planning)
• 使用者故事層級裡放置作業項目(Tasks)。如果把使用者故事看作是需求，那作業項目就是完成某需求所需進行的工作。作業項目由開發人員撰寫，它同時也可用來較為精細的估計工時。
• 在 XPlanner 裡面你不用怕故事放錯迭代，也不同怕作業項目放錯故事，因為它們都是可以在不同的容器中移動或接續的。

使用 XPlanner 規劃及追蹤軟體開發專案

這部份有些內容參考自 XPlanner 網站：Planning and Tracking

XP (Extreme Programming; 終極製程) 是極富彈性，且還在進化中的軟體開發流程。在實務上有許多的 XP 規劃方法。我們在此說明 XPlanner 所支援的流程。規劃流程的特性及步驟包含：

由顧客及開發人員定義發行計畫 (release plan)

XPlanner 目前還沒有直接支援發行規劃 (release planning)。不過 XPlanner 倒是可以讓你定義許多迭代，並在其中放入適當的故事 (stories)。你可以把這種功能當作是發行規劃的一種方式。實務上，我們還會定義虛擬迭代 (pseudo-iterations) 來容納那些還未排入正式迭代的故事。這樣就可以讓顧各定義他們想看到的產品特性，並為接續的迭代規劃存留原始題材。

使用虛擬的迭代 (pseudo-iteration) 儲存尚未納入排程的故事 (stories)

XPlanner 目前常未直接提供未規劃故事 (unplanned story) 的容器。然而，許多團隊會建立一個稱做是 "backlog"(註: 應該是起源於 Scrum 開發方法學，用來代表 feature repository) 或 "unplanned stories" 的虛擬的迭代，並將迭代啟始時間設定為很久之後，來當作 未規劃故事的容器。將未規劃故事先放在這個虛擬迭代中，之後在概念規劃 (planning game) 時再把適當的故事移到適當的迭代中。

由顧客定義使用者故事 (user stories)

你可以在規劃某一迭代時直接建立使用者故事，或將別的迭代裡的使用者故事移到某迭代中。故事的優先權必須協同顧客敲定。

由開發人員估計實作故事的代價

XPlanner 可以在為故事定義作業項目 (tasks) 之前，就先預估工時。這對一開始時粗估是否能在時間、資源限制內，實作出顧客所要求的故事集是非常有用的。觀察員 (tracker; 追蹤者) 將會參與這個階段，來幫助顧客開發故事。觀察員通常會是故事的開發人員之一，但這並非必要。

一旦選定了一組可行的故事集之後，開發人員將會定義實作故事所需進行的作業項目 (tasks)。這個時候，由開發者為某一故事的工作項目所進行的工時估計，將會取代原始故事的工時粗估。每一個工作項目，都會有一個受理的開發人員 (acceptor)。當開發工作正式進行時，受理人將會 (或可能會) 與另一個配對程式師 (paired programmer) 一同進行開發工作。

開發者以過去迭代的指標來決定其可用預算 (budget, 這裡偏向時間上的預算，而不是指經費上的)。而預算決定了某開發人員在此迭代中可接受的工作。在 XPlanner 中，迭代中每個開發人員的所花費的工時可透過 iteration metrics 頁面呈現。一般來說，將工時除以二 (假如是採用配對程式設計方式) 就是當前迭代可用的預算。

實作故事

如果透過作業項目重新估計的工時仍然在此迭代可接受的預算之內，就可以開始進行作業項目了。

進度追蹤

作業項目開始進行後，就可以追蹤其工時。XPlanner 會在迭代、故事，以及作業項目層級的網頁，以進度列的方式來展示進度。

進度列可用來 (例如，讓相當忙碌及時間有限的顧客) 快速檢視整個團隊的進度。進度列已經過正規化 (normalized) 以減少視覺雜訊的顯示。正規化的缺點是故事的相對大小沒有顯現出來。這樣的資訊是以數值化的方式顯示在迭代表 (iteration table) 及其他頁面中。如果一個作業項目還沒有記錄任何工時，則整條進度列都會是灰色的。

而當作業項目開始進行後，進度列上會以藍色表示已進行的工時。

如果某個作業項目的實際工時已經超出了之前的估計，則 XPlanner 會強制你更新估計工時，才肯讓你儲存輸入工時。之所以這麼做的原因是，XPlanner 不可能在你超出預估工時後，還能幫你估算剩餘工時。而原本的預估並不會喪失，因此還是可以產生 "預估正確性指標 (estimation accuracy metrics)"。

迭代頁面所示的故事層級 (story-level) 進度列，則是作業項目層級進度的整合。

不曉得是幾十年前從 "歷史" 還是 "生活與倫理(現在小學還有這門課嗎?)" 唸到的，那個在現代聽起來有點八股的新生活運動。我倒不是要在此強調復興中華文化，講究禮義廉恥，四維八德。只是新生活運動所推行的：「整齊、清潔、簡單、樸素、迅速、確實」六項生活記律，倒是與近代軟體開發思潮所標舉的簡易之風不謀而合。

整齊、清潔

程式必須依照一致之風格來寫作。沒用到的變數要刪除，測試用的訊息不要當成註解留在文檔中。更進一步的說，系統的設計架構應明確，類別間的階層與引用關係應形成清晰的脈絡，若是系統關連猶如錯綜複雜的網路，在維護上就相當困難。

要做到整齊清潔的設計，除了一開始開發系統時，就要儘量依據物件導向之原則，採用適當的設計模式外，在設計過程中還要不時的對既有設計加以重構。這就好像是種植盆栽，軟體就像是種在盆裡的那顆樹。一開始時，我們會依照自己的期望來形塑，但當它開始成長，就必須讓它依照其本性生長，但成長到一定的階段，又必須適度的加以裁剪。在如此環境下長成的系統，就會自然適性，有風格卻又避免掉明顯的匠氣。

簡單、樸素

好的設計應該易於理解、易於改變、易於重用。「簡單就是美，不做過度設計，不開發系統用不到的功能；以更少，做更多」這幾乎成為 Agile Methodolodgy 的金科玉律。每個方法 (method) 應設計成只完成一件事，並避免在方法執行過程中產生與方法名稱無關的副作用。每個類別應僅代表一抽象或具象概念，當某一類別同時代表一個以上的概念，就會在重用時在引用端導入不必要的特性與關連，而降低重用性。

樸素的概念，也讓我想到 Plain Old Java Object (POJO) 的應用。Hibernate 與 Spring Framework 共有的特性之一，就是善用 POJO 既有的能力，來簡化物件模型。也因為 Hibernate 與 Spring Framework 只是簡單的讓 POJO 來代表 Model 的觀念，而不把其他的責任(如實體層的存取，使用者動作的反應) 加在模型上，讓這 POJO 得於遊走於 3-tiers 或 4-tiers 之間，讓我們見識到了樸素的能量，真是願原力與你同在!

簡單、樸素也適用於使用者界面的設計。除非你在設計遊戲軟體或多媒體動畫，除非你極具有美學概念，否則把應用程式弄成五顏六色，並綴之以五花八門的圖示(這種界面風格被稱為小丑裝)，還不如直接讓應用程式以作業系統預設的風格呈現。

迅速、確實

Small iteration, Continuous integration 以及 Build automation 所提供的，正是迅速的開發程序。而正是因為著重確實，所以才要 Unit test，才要 Test driven design，才要代碼未動，測試先行。

迅速、確實從程式的 performmance(表現，效能)上來講，則代表系統要能有效率的完成操作，又能確實的達成系統的功能。

開發速度(迅速) 與開發品質(確實) 永遠難以兼顧，若能保持簡單、樸素的原則，要做到迅速、確實，就會容易一些!

除了 Design Patterns 之外，近年來物件導向設計領域還開始講究 OO principle. 像是從前年開始流行起來的 micro kernel framework -- PicoContainer 及 Spring Framework 所講究的 dependency inversion，本身也是一種 principle。而 RMI, EJB 及 Jini 等遠端物件技術，則符合另一 principle -- Program to an interface, not an implementation. 這些 principle 之所以存在，最主要的目的就是讓我們在設計系統時，可以增加系統的擴充性與維護性。對這些 principle 有與趣者，可以到 Object Mentor 尋找相關資料。

由於昨天部門讀書會剛好討論到這個議題，我便就這個主題發表一下我的看法。像是這個讓人覺得矛盾的 Open Closed Principle， 也就是 Open for Extension, Closed for Modification，到底 Open (開放)了什麼東西，Closed (禁制)了什麼東西。用簡單的話來講，這項原則強調：

* 在設計一類別時，應保留足夠的彈性，讓採用此類別的程式，透過擴充的手法，即可新增或變更系統功能。
* 在設計一類別時，應具有適當的封閉性，避免讓採用者直接修改類別原始程式，才可達成其功能。

我想寫過稍大一點程式的朋友一定會這種經驗，當我們在程式中採用一個類別時，有時候發現該類別少了許多我們所要的特性或功能，這時候我們可能採取以下幾種作法，來達到呼叫者所要的功能：

* 你可能動手直接修改該類別某個 method 的實作
* 你可能在該類別中新增你所須要的 method
* 你可能透過建立一個該類別的子類別，再採用其子類別，來達到你所需要的功能
* 你可能將該類別的某些職責(responsibilities)，透過 composition 或 delegation，交給別的物件處理，就可以達到你所需要的功能

究竟採取何種作法，除了視採用者個人的偏好外，還與原始類別設計的好壞有關。各位可以看到，上面的這幾種方法中，越上面的方法，對你原本系統的程式修改越多，而越下面的方法，對原程式的修改越少。因此如果一個類別的設計，能讓採用者越喜好使用下面的方法來達成其功能，則原始類別的設計，就越符合 Open Closed Principle。

我再舉一個 JDK 的例子，在我們使用 JDK 裡面的 API 時，就不太可能會想要動手去修改 API 裡面的實作。例如：當你發現 JButton 少了你所需要的屬性時，你大概不會動手修改 JButton 的原始碼；反之，你可能會新建一個 JButton 的子類別，再於其中加入自己所需的屬性，這就符合了Open Closed Principle (甚至所有的 JComponent 都允許你用 putProperty 的方式，在不用新建子類別的方式之下，動態新增屬性)。還有不少 JDK API 的設計，也都符合這項原則，像是 sort 只要傳入 Comparable，JButton 有 addActionLisenter, JTable 有 TableModel... 不勝枚舉。

最進一直在思考一個問題，如何設計一個更實用、更具親合力的 Client 端應用程式使用介面。 傳統的 UI 介面設計包含以下類型：

• Panel Based：面版型使用介面。像是 ICQ、MSN、WinAmp 等，強調使用便利性的程式，便會使用這種介面。
• Dialog Based：採用對話窗作為應用程式介面。常見於極小型的工具程式，或組態設定程式。
• Explorer-Like UI：指的是長的像檔案總管一樣的使用介面。這種介面可以很容易的讓使用者從大量的文件或物件中，選擇要操作的對象。像是 mail client 也大都是這種設計。
• SDI： 單一文件視窗介面，這種介面設計常見於小程式，像是 Notepad。如果用在大一點的程式中，就必須要加上許多浮動視窗，像是 OpenOffice。這種設計的缺點是，要開啟多份文件的話，就要開啟多個視窗或應用程式。不過話說回來，也許這能讓使用者更專心於目前的文件上頭。
• MDI： 多文件視窗介面，這種設計常用於中、大型應用程式。優點是可以在同一個視窗中顯示多個子視窗，缺點是如果某個子視窗最大化，要選擇其它視窗，得靠 "視窗" 選單。如果用 Swing 的 JDesktopPane 實作，沒視窗選單可用，就得要將最大化的子視窗縮小，才能切換到其它子視窗，真是夠難用的了…。個人對 MDI 介面的另一個抱怨是，即使文件子視窗最大化之後，還是有一條很醜的子視窗標題列。
• TDI (Tabbed Document Interface)：這種設計與 MDI 一樣，具有同時開啟多份文件的能力。與 MDI 不同的是，TDI 採用頁籤切換文件。好處是在文件切換上較為簡便，缺點則是一次只能看一份文件、要比較兩份文件 (或一份文件的不同位置)，就相當麻煩了。目前我看到做的最好的 Tab 視窗介面，是新版的 NetBeans Windowing System。
• Split -Pane：分割視窗；為了解決 TDI 與 SDI 一次只能觀看一份文件的限制，有些 SDI 或 MDI 使用介面會搭配 Splitter，讓你可以把視窗一份為二。像是 Word 就具備這種功能。另外還有一些軟體、是為了特殊的使用性，才採用這種設計，像是 WinMerge(檔案比較)、FileZilla(FTP)、7-Zip等。在 MDI 中，把這種功能發揮到極致的是 Notepad++。
• MDI + TDI：MDI 與 TDI 各有優缺點，如果能把這兩種介面設計結合起來，就能達到功能互補的效果。一個著名的例子首推 UltraEdit，另一個不錯的例子是 CPad。以上這兩套應用程式，在子視窗最大化之後，都不會有那一條醜醜的子視窗標題列。
• Dockable UI：是指應用程式的視窗可以隨意拖曳、停駐在某些地方。常見於 IDE (整合開發環境) 上。Visual Studio.NET 及 Eclipse 都有強到不行的 Dockable Interface。雖說如果應用程式的整體 Layout 設計得當，那麼有沒有提供 Dockable UI 並不是那麼重要，但若是像 Eclipse 那樣，使用者可以無限制的外掛其他 plug-ins，那 Dockable UI 就相當重要了。因為原始系統開發人員、永遠無法想像，最終在使用者電腦上執行的，是怎樣的組態…

以 上就是目前我所能想到的 UI 類型了。由 UI 演進的軌跡來看，最先進的設計非 Dockable UI 模屬。但一定非得像 Eclpise 或 NetBeans 那樣 Docked Evey Where and Tabbed Evey Where 才是好的設計嗎? 我覺得不儘然。

以下面的 NetBeans 視窗為例

我 將它區分成 (a)左方的瀏覽區、 (b)下方的訊息區，以及 (c)右上方的文件內容區。當然 (a) 與 (b) 採用 Dockable Tabbed UI 是較好的設計。而 (c) 區則未必一律適合採用。原因很簡單，並不是所有的內容視窗都適合像 TDI 一樣，以最大化的方式展示。因此在 (c) 區，採用 MDI + TDI 混合式設計，可能更為合適。

做好環保，跟寫出一套好的軟體系統的道理是一樣的! 怎麼說呢?
原因很簡單，做好環保有三個R: Reduce,Reuse 與 Recycle。
這三個R，正好與我們開發軟體系統的觀念不謀而合。
如果今天要實施的是一個專案，那就要在加上兩個R--Refuse、Repair，
拒絕什麼要做的，修正發現的錯誤...

Refactoring(重構):

• 首倡者：雖然這種事我們以前都做過
• 何謂重構
• 重構目錄，說明重構的手法
• 壞味道清單，當程式碼裡面出現這些壞味道，可能就需要重構了。這裡有 Refactoring 原書所列的所有壞味道之解釋。
• 簡單而完整的重構教材
• 重構樣式，透過重構而得的樣式

Historical post

• 2003/09/08: 昨天晚上，冒著杜鵑颱風的風兩(其實沒什麼風雨)，到台北天瓏買了Refactoring 中文版。當天晚上就看完了第一章。一些感想：
  • debug 前先重構
  • 增加新功能前先重構
  • 一次重構一點點
  • 重構必需與單元測試結合
  • 透過特定的手法所進行的重構工程，可能導引出特定的設計模式(design pattern)
  • Smalltalk 語言在軟體工程的發展史上，似乎扮演著相當重要的地位，至少在 refactoring、design pattern，以及 oop 的許多觀念，都來自 smalltalk。