單元測試前之本質學能

我認為單元測試主要用來驗證程式設計邏輯與系統功能正常運作的技法，期望哪些情境下，確保我們的設計都有考量到，

並且滿足需求，另外再未來擴充與修改系統功能下，依然能 維持既有的測試案例(不會改東壞西)，

增加對軟體的信心度。但，再開始之前，

依照劣者的經驗，盲目進入可能會對測試產生不好的印象，也許會萌生 production code 都寫不完了，還寫什麼測試，

時間很多昵...，如同「重構」其實是設計過程中的一部分，而鮮少將「重構」納入為必要任務；當然實務上確實會遇到

先欠技術債，但有意識的還，這就不在細談範圍，有興趣可參考小風的：有效面對技術債。所以，這是勸世文，一定要先學好本質學能。

第一次接觸單元測試的時候，其實有被震撼到，在測試prod code 的時候，

不僅測試上寫的哩哩剌剌(台語)，也凸顯出對於設計原則其實沒有很熟的窘境；故，覺得應該要先針對本質學能的基礎知識要

很了解，才能不會在單元測試卡頓，並且尚失信心，更不用說期待單元測試達到的效益了...

須具備基本技能

物件導向設計

熟念物件導向設計的三大特性以及應用技法，務必學習到反射動作；過程一定要思考應用情境與實務上的差別，例如：

抽象類別可應用的情境？虛擬方法與抽象方法的差異？等等...，網路上其實也可以找到很多討論；另外，

泛型(Generic)與反射(Reflection) 也是基礎要會的，當然，針對語言特性，還有很多細節可以探討，也就不贅述...，

斯覺得這關過了，其實也就會先幫自己的production code 提升到一個檔次。

設計原則(SOLID)

延續物件導向概念，我們在設計程式的時候，可以依據哪些原則？而做到這些原則可以讓程式有可維護性與更加明顯的意圖；

五大原則看起來簡單，但實際操作確實需要一些經驗的累積，會延伸出系統分析的功力；這部分完成後，

會有一種凡事都朝「高內聚」與「低耦合」的境界走。

設計模式(Design Patterns)

若需要將檔次再次提升到另一個高度，這部分就很重要，常用的設計手法就會變成 pattern ，除了帶給我們設計上的方便，

並且溝通上這些術語可以幫忙節省時間；這邊無須強記或強背所有模式，反倒是理解各個模式應用的情境，以及可以

解決甚麼問題至關重要；畢竟，單純僅用OOP完成任務，比亂用設計模式來得強。

別想一步到位

放寬心，別想總是一步到位，需要透過刻意練習，讓肌肉記憶Flow；前兩者一定要練到很熟，

設計模式可先就創建類型的模式有一定熟悉即可，如簡單工廠...，未來有需要再回來查即可。

別走火入魔

是的，有很多人確實對程式很有熱情，學了很多技法相信都很想用上一波，但一定要分的出應用情境與取捨。

沒有放諸四海皆準的設計，只有「恰如其分」的設計，共勉之~

(別手上拿著鐵鎚，就看甚麼都是釘子)