在 PHP 中，傳遞物件是很容易的事；我們只需要將物件的狀態封裝起來後，以字串的方式傳遞給另一端的程式還原執行即可。物件的傳遞用途很多，例如我們在 Gearman 中，就可以在 client 把物件當做是 job data 傳遞給 Server 。

註： Gearman 的介紹可以參考拙作：Gearman 心得。

以下我們來看看範例。

重構是什麼？這問題其實真的很難回答。

我個人覺得重構是一種讓程式保持活力的一種方法，讓它能隨著時間而不斷地進化。如果我們一直放任自己不對程式碼做適當的整理，而是靠著不求甚解的修修補補來維繫它的生命，很快地程式碼就會變得殘破不堪、臃腫肥大而難以維護。

而且有的時候，我們也想讓程式碼能隨著我們觀念的增長，以適應未來的變化；今天我們會覺得這樣的寫法很讚，但明天可能又會學到更好的寫法，重構就能給我們改變程式碼的機會。

但是這些都是很籠統的解釋，有沒有什麼方法可以讓我們更瞭解重構呢？我想，只有用實際的例子來說明是最直接的吧。但是太精簡的範例可能表達不了重構的意圖，而過於複雜的範例又會讓重構的焦點模糊，要找到一個適合的例子可能比重構本身還困難。

後來某次的改版機會下，我分析了伙伴之前所製作的功能並做了一次重構，發現這個功能的規模不算太大，而且也很容易展現出重構後的優點；因此，我便將這個功能稍微做了簡化以方便說明，希望能讓大家瞭解重構究竟是在做些什麼。

不過這個範例雖然不大，但也還是需要一番功夫來解說；因此我將會把它分成兩個部份來說明，第一篇是分析，第二篇則是實戰。

接下來就一起來看看這個例子吧。

接續前篇：重構實例介紹 - 分析篇

在上一篇中，我們分析了該功能的每段程式碼，也瞭解有哪些地方需要改進，接著我們就來進入實戰的階段。

在實戰的階段，我們要做兩件事：建立自動化測試，重構程式碼。

自從學習開發 Web 程式以來，我的工作就離不開購物車了。從模仿其他網站的購物機制開始，到接觸了物件導向後的所寫的購物車架構，每一次的經驗都讓我成長不少。

不過每次所寫出來的購物車系統，不論是在新增功能或是修改上都讓我覺得非常麻煩；只要客戶有些稍微複雜一點的需求，常讓我改程式改到想翻桌。

後來接觸設計模式、 MVC 及 UnitTest 之後，一個新的購物車架構漸漸在我腦海裡成形。一來我不想再讓商品加入購物車、更改商品數量、促銷活動或是結帳等機制散落在各個 PHP 程式中，但我也不想讓它們完全集中在一個類別裡，那麼適當的架構分離就顯得非常重要。

於是乎，集合了多年的經驗，我在某個專案裡試做了一個新的購物車架構；而經過一段時間的線上測試後，事實證明它非常容易增加功能及修改功能，也更容易讓我們釐清整個購物流程。而且如果在良好的設計安排下，它也能做到模組化的功能抽換。我心中不由得吶喊：「就是它了！」

當然，這個機制並不是最好的，也可能無法因應所有網站的需求；但是這至少是我自己在電子商務技術這個領域的經驗，以及經過多次挫敗後所得到的成果。因此在以下的投影片裡，我將單純地就這個購物車機制來做一些探討，希望能為大家在架構的設計上，帶來一些不同的想法。

另外要提醒大家，這裡所提到的購物車架構，並沒有涉及所謂的後台商品上稿或是前台商品陳列等機制；換句話說，它不是一般我們所定義的購物車模組，請大家要先瞭解這一點。

我常常問自己，台灣的業界生態真的適合開發軟體嗎？如果不適合，那麼軟體工程師們到底是為了什麼而選擇這個工作呢？

從網路上或是前輩口中所得到的大部份資訊裡，不難看出大多數的軟體工程師對於自己的職業生涯並沒有過於高深的期許；因為寫程式只不過是賺錢的手段之一，可以的話還是買買股票看能不能賺得比較飽。

以下，就我所看到的例子，來嘴炮一下大部份台灣軟體工程師的心聲吧。如有雷同，純屬巧合。

很多書上和網路的文章都提到了很 TDD 的做法，不過老實說我並沒有實際參與這些大師的 TDD 過程，其實很難把他們的方法百分之分地應用到自己的專案裡。

因此，凡事還是要自己動手做過才會明白，所以我就趁著在開發新的 Library 時，真正地去落實測試與重構。

以下就是我大致的心得，供大家參考。

前幾天， Glenn 與 Mark 分享了 Gearman 的觀念與實作，以下就是我簡單的筆記與心得。

專業技術從來就不是人天生就會的，所以我們才需要去學習它。可是有許多人在學習新技術時，常常只是把書瀏覽過一遍，然後真正要下手時卻不知所措。其實在學習技術的方法有很多，只不過並沒有哪個方法特別好，就看這個方法適不適合我們而已。

然而適合每個人學習的方式不一定相同，以下就是我個人以往的學習經驗，供大家參考看看。

為什麼要測試？

因為我們沒辦法保證程式碼是萬無一失的，所以通常我們都會需要驗證我們的程式，而測試就是其中一種方法。很多工程師都在寫完程式之後，自己手動去做測試；如果執行結果是按照自己的想法出現後，那麼他們通常就認為程式沒錯了。

可是，其實這樣的程式碼通常就會躲進很多很多的 Bug 。所以我們要讓程式碼自己告訴我們它沒問題，而不是我們自己去想像它沒問題。

在開發 PHP 的時候，最麻煩的事情之一就是處理錯誤。一個好的程式除了要將錯誤訊息呈現給使用者知道之外，也要讓該結束的部份正常結束才行。

而在 PHP5 之後，除了以往的 Error Handling 之外，還多了 Exception Handling ，使得程式變得更難去處理錯誤；所以大多數的開發者只能雙手一攤，讓這些錯誤訊息大剌剌地出現在使用者面前。

有沒有什麼好方法可以讓我們好好控制 Error 和 Exception 呢？