繞過去，好嗎？

Jan. 31 23:07~23:58

▲逢山開路，遇水搭橋

問題

從去年開始Teddy和指導教授一起帶幾個實驗室學生做研究，目前遵循clean architecture的方法正在開發看板軟體。一個多禮拜前學生問Teddy關於Repository的介面設計，經過討論後Teddy請他們做點研究，下次開會再談。

今天回學校和學生開sprint review會議，順便請學生說明他們研究Repository的結果。學生告訴Teddy他們發現有兩種Repository的設計方法，第一種是接受由外部給定的specification當作查詢條件，可以比較有彈性的支援多種查詢條件。第二種是在Repository介面上設計常見的方法，例如findAll、findById、findChildrenById等。

學生採用第二種設計方法，聽了請他們選擇的理由後，Teddy還是覺得不滿意（forces沒有被平衡XD）。於是請學生把domain model叫出來，一起讀過一次，發現他們所採用的Repository介面設計無法支援domain model的所有物件。

***

程式可以動啊

學生寫的程式可以動，這個sprint所完成的user story還算做得不錯。但是，如果細看軟體設計，其實還有不少可精進之處。

Teddy告訴他們：

Repository的問題還沒徹底解決，雖然程式可以動，但是如果不管這個設計問題，繞過去，以後你們還是有很大的機會會再遇到它。你們是研究生，專案中遇到問題應該利用機會把問題搞懂，徹底解決。日後遇到同樣的問題，既使context不同，別人花三天，你們只要花一小時就可以解決。層次與專業就是這樣累積出來的。

這個問題，最好的解決方式就是你們搞懂後做出設計的決定，然後說服我（教我）。次一等的解決方式，就是我弄懂後教你們。最糟的方式就是不管它，反正程式可以動就好。

***

Repository Pattern

因為Google太方便，所以學生遇到問題尋找資料，大多下個查詢條件，然後看最前面的幾個連結之後就做出結論，草草結束。Teddy在〈增進學習力的三個練習〉提到，首先要知道名詞的定義。學生只知道可以套用Repository pattern，但很可能對於該pattern的定義只是一知半解。

在《Patterns of Enterprise Application Architecture》的第322頁就介紹Repository pattern。在《Domain-Driven Design: Tacking Complexity in the Heart of Software》以及《Implementing Domain-Driven Design》也都有提到，後者並且包含範例程式碼與實作細節。

***

龜毛

大家都說日本人做事很龜毛。同樣的商品，例如Toyota汽車，MIT和MIJ，相信大部分的人還是比較喜歡日本原裝進口。為什麼？因為組裝的人不一樣啊…Orz

軟體開發是一種專業，就好像醫生也是一種專業。你總不希望醫生開刀的時候遇到問題「繞過去」吧？！反正 程式可以動 人還有呼吸就好XD。 

***

友藏內心獨白：書還是要讀，不能只看網路文章。