iT邦幫忙

2021 iThome 鐵人賽

1
Software Development

也該是時候學學 Design Pattern 了系列 第 31

完結心得

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

跟往年一樣,列出幾點個人的體悟:

花費的時間超出預期

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

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

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

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

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

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

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

產出的內容沒有達到預期

這要搭配上一點,因為時間的壓力:

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

收穫

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

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

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

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

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

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

總結

還記得剛開始工作時,朋友就提醒我:

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

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

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

我感到十分開心。

學習資源

書籍推薦(論閱讀的優先順序):

網站推薦:

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

上一篇
Day 30: 關於 Design Pattern,來點心理測驗吧
系列文
也該是時候學學 Design Pattern 了31
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

2 則留言

0
金金
iT邦新手 2 級 ‧ 2021-10-18 09:44:47

恭喜完賽!

0
lagagain
iT邦新手 2 級 ‧ 2021-10-20 21:32:21

深入淺出設計模式第二版很新呢XD
有在猶豫要不要購入收藏,自己很喜歡第一版。

大話沒看過,但是也很推四人幫原作。跟朋友討論時,很多時候反而「設計模式」感覺最好,但也最不好讀。

有時候不單單只是學習設計模式。不斷review現有程式碼、架構也收穫到很多(因爲一些需求翻了不少原始碼。還有這次主題也無意間會想到一些模式)。然後再定幾個假設情境想想要怎麼處理。
模式就在哪裏,本來就已經在用了,只是缺少阿發現。四人幫的偉大之處在於參考建築架構的方式, 整理 了軟體開發上的設計模式。有不少模式其實很難獨立使用,有時也受到語言限制。
越去理解過後,就會發現有些話真的蠻有道理的:

程式設計語言的選擇非常重要,它將影響人們理解問題的出發點 。......這個選擇實際上 决定了哪些機制可以方便地實現,而哪些則不能。

-- GoF


模式意味著“我的語言不夠用了。” ── Rich Hickey

我要留言

立即登入留言