緣由

大家好，我是維特，去年鐵人賽介紹 用 JavaScript、Java、C 刷 Leet Code 、前年介紹 VS Code 的人。

去年寫完的當下，「解脫」是第一時間的反應，事前沒有妥善規劃，導致每天的流程是：

• 一早起來閱讀新的演算法、資料結構。
• 白天思考、吸收新知識、找適合的題目。
• 晚上回到家開始刷題。
• 找出最佳解之後轉譯成其他語言。
• 將以上內容轉換成文字稿之後按下繳交鈕，完成當天的進度。
• 預覽明天的進度。

回憶起這段日子，往往覺得我幹麻整自己，過度操勞讓身體不健康一個月。

當然，事情永遠都是一體兩面，有壞處肯定也有好處。

經過這段高壓特訓後，在開發時會慎選資料結構、for 迴圈的利用，盡可能讓程式碼擁有高效率；此外，還會多多注意有沒有遺漏的變數，是不是有機會造成記憶體濫用。這些成長讓我有更多的自信在軟體開發上。

因此，參與鐵人賽宛如身處在精神時光屋，只要認真面對自己挑選的題目、努力學習以及產出相關知識的文章，便可有所進步。

這次選擇 Design Patterns 的原因在於，在資訊科學的環境內一定聽過、公司經手的專案肯定有使用特定的 Pattern，甚至學習網路開發時一定會碰到的 MVC 其實算是一種 Pattern。不論在哪種情境，Pattern 無所不在。既然每天都會接觸，哪不妨趁這三十天，好好學習、了解 Design Patterns 吧！

什麼是 Design Pattern

學習如何繪製設計藍圖，好解決不同情境下的問題，達成原先設下的目標。

這一年來，因為 LeetCode 提升撰寫最佳解的能力，一旦有機會，我會寫出效率優先但是「一長串」的程式碼，同事多次提醒我，這會增加他們的閱讀理解難度，不是每個人都能快速熟悉不是他負責專案內的程式碼。

這件事給我不小的啟發，追求最佳解是刷題時的唯真理，可是專案幾乎是團隊運作，增加討論的門檻會讓專案的進度受到拖延。因此，實務上追求效率不一定永遠是最佳解。

多次跟同事討論後，對方告訴我關鍵字：「耦合度」，從這個節點開始，慢慢找尋相關知識後了解到，Design Pattern 就是我目前缺乏的核心知識，，

我會怎麼寫

本身不是大專院校資訊相關科系出身、從網頁開發入門軟體開發，工作經手的專案接觸到 Java 與 C。

論語言的熟悉度：JavaScript > Java > C。

熟悉度是這次挑戰最棘手的，在於 Design Patterns 是建立在物件導向程式設計（OOP）之上，適合使用具有 OOP 特性的語言學習。JavaScript 基本上不太具有完整的 OOP 特性（少了 Abstract Class 與 Interface），造成在學習 Design Patterns 上多多少少感到不相容。

這次撰寫會交互使用 Java 與 JavaScript，力求把每個 Pattern 的前因後果交代清楚。

結語

回顧去年的第一篇的最後寫道：

每一年都要幫自己的職涯製作該年度的代表作。平常不怎麼寫 side project 的我，決定用今年的鐵人賽當作是年度代表作。

今年我也抱持著相同的想法，努力付出，創作出不後悔的代表作！