第三年參加鐵人賽，心態上比起前兩年穩定許多。即使如此，過程中仍然有些遺憾，可以寫得更好但沒有達成。

跟往年一樣，列出幾點個人的體悟：

花費的時間超出預期

大約今年農曆新年期間就決定今年的題目是 Design Pattern，接著陸陸續續把書籍買好（物件導向設計模式、深入淺出設計模式、大話設計模式），沒有壓力地隨意閱讀，到了開賽前兩個月開始構思要怎麼寫，開賽前完成四篇，這四篇都是前置作業，不是模式的介紹。開賽第一天，才完成第一篇模式介紹文（Simple Factory Method），同時往後二十三篇模式介紹文的格式也定義完成。

這邊提一下模式介紹文要如何準備：

1. 翻書（以大話設計模式為主）。
2. 上網看其他人怎麼解釋。
3. 試著用自己的話講出該模式的重點（目的、說明、總結）。
4. 舉一反三，製作模式的範例程式碼（UML 圖、用 Java 與 JavaScript 實作範例程式碼）。

這四點中，需要最多時間完成的絕對是最後一點，因為舉一反三等同要教導其他人如何學習，那勢必自己必須完全學會，沒有混水摸魚的空間，如果當天忽然無法理解模式的定義，那就會消耗庫存，這三十天還真的讓我遇上這件事（謝謝你，Flyweight 模式）。到了第十八天就變成彈盡糧絕的情況，必須當天寫好文章，使我的壓力開始變大，每天都想要逼自己快一點，但是越逼反而越沒有用，總是拖拖拉拉到最後三、四小時才願意開始動手寫。

剛好前陣子在閱讀專案管理的書籍，提到專案在截止日之前，需要多次的審查，好確保專案的進度在軌道上，如果沒有任何審查，到了截止日才見真章，肯定會影響專案的品質。

說來好笑，我在第二十幾天時就再問自己「怎麼不早點開始寫？」

這是一個深刻的教訓，事情（尤其是完成時間很長的計畫）的發展絕對不會如人所願。

產出的內容沒有達到預期

這要搭配上一點，因為時間的壓力：

• 放棄比較模式優缺點的段落。
• 放棄更詳盡實用的範例程式碼，只能寫出為了符合模式定義的內容。

收穫

上面兩點是個人的遺憾，而事情永遠是一體兩面，收穫肯定有。

最大的收穫莫過於熟悉「彈性」這名詞，如何讓程式碼擁有面對變動時也不會造成開發工作浩劫的能耐？經過這三十天的訓練，漸漸地能感受出「這樣寫會給未來的自己找麻煩」的想法。

具體表現在這陣子的工作上，花費更多的時間在思考，為了達到新的開發需求：

• 那採用方法 A 會有什麼好處？什麼壞處？
• 採用方法 B 呢？
• 還是我被困在現有的架構內，嘗試往更上一層來思考呢？

對於開發資歷要滿三年的我來說，引用套件、思考演算法等快速編寫程式碼的部分，已經不再是個大挑戰。因此樂見自己在動手開始寫之前，花費更多的時間思考「怎麼寫？」

能夠往架構的方向前進，對於此發展感到十分滿意。

總結

還記得剛開始工作時，朋友就提醒我：

只會聽著主管的建議，要你寫 A 就寫 A，豈不是跟機器人沒兩樣？
有機會的話，試著讓自己思考架構的層面，要擁有「繪製藍圖」的能力。
不再侷限於交代的事項，而是聚焦在更廣的事情上，如此一來，才算是一個好的開發人員。

對於菜鳥的我來說，這段話深深烙印在我的腦海中！同時，也是連續三年參加鐵人賽的動力，讓自己有更多的學習、成長。

藉由完成三十篇文章，讓自己又成長一些，擁有更多的能力。

我感到十分開心。

學習資源

書籍推薦（論閱讀的優先順序）：

• 大話設計模式
• 深入淺出設計模式
• 物件導向設計模式
  • 這本聖經內容肯定最齊全，但是缺點是不容易理解，在購入前可以去圖書館翻越，了解自己有能耐吸收。

網站推薦：

• Refactoring Guru
  • 這網站在這三十天幫助我超級多，因為大話設計模式的範例過於簡單，我一度卡在如何想複雜的範例程式碼，幸好有這網站的幫忙，藉由他們的範例程式碼，使我能夠舉一反三。