在過去的二十幾天中，我們從畫面開始到 API 呼叫，由外往內的討論了每一層，也討論單元測試與 Widget Test。在每一層中，我們討論了許多比較常見的問題，針對每個問題，也討論這樣設計會造成什麼問題。但是否我們在專案剛開始時，就開始引入狀態管理套件、使用裝飾者模式或 Interceptor 呢？

過度設計

大多時候，如果我們還沒看到問題，就想著用什麼作法，常常會導致程式過度設計。因為使用場景還沒出現，我們假設了未來會這麼用，萬一想像中未來沒有發生，那這些拆的很乾淨的程式碼除了影響閱讀之外，一無是處。每一個解法都應該對應著一個想解決的問題，只有當問題發生時，我們針對問題解決，才不會讓程式碼變得過度設計。

四眼原則

雖然我們總想著不要過度設計，但是有時就是無法避免，畢竟如果是一個人開發，再厲害的人有時也是會有盲點的。為了減緩這麼問題，我們可以透過 Pair Programming 和 Code Review，多一個人一起思考討論作法，能讓設計有機會變得更好。有人可能會覺得兩個人做同一件事情很浪費時間，但是如果仔細想想，如果常常一個人寫 Code，卻又在 Code Review 得到許多需要修改的回饋，然後轉頭再花時間修改，那不是一件更浪費時間的事情。如果多一個人同時思考討論，是不是也能降低 Bug 發生的機會，省下許多修 Bug 的時間。

精進自己

如果今天我們與其他的同事一起 pair，我們也能從 pair 的過程中學習許多自己不知道的技巧，進而提升自己的能力。或許同事的打字速度很快，快捷鍵使用的很熟練，不會因為打字太慢而中斷思考，我們也就知道學習這些技巧，能為我們帶來什麼好處。除了透過 Pair Programming 之外，閱讀大師的著作也能讓我們更全面的了解一些設計的意義，或更好的作法或架構。也有許多大師願意花時間開課傳授自己畢生的功力，例如：91 敏捷開發之路、搞笑談軟工 …等，都是能有效精進自己的設計能力的方法。

最後

唯有持續的學習，了解每個設計背後的問題，並且針對問題與當下的情境，選擇最合適的作法，才能讓程式處在易於修改又容易閱讀的狀態。在過去的二十幾天中，我們討論了許多問題，也有許多問題沒有被討論到，或許以後有機會再跟大家分享，也歡迎大家來我的 Medium，也謝謝大家三十天以來的觀看。