歡迎大家來看我的文章，這次我挑戰的主題是 Android 架構，就如同我簡介中說的，關於架構方面的文章以及教學在網路上是非常豐富的，那為什麼我還要來挑戰這一個大家都快寫到爛的主題呢？因為據我所我觀察到的，大部分都是介紹某個架構中有哪些組件 （Component），像是 MVVM 就是 Model, View, View Model，VIPER 的話就是 View, Interactor, Presenter, Entity, Router。還有他們各有哪些職責，然而卻很少與實際的案例做結合，依據不同的使用情境來實作成不同的樣貌。

我這樣說並不是批評他們喔！要跟一個實際的案例做結合本身就需要花費非常大的篇幅來解釋，從需求，分析到設計還有最後的實作，每個階段都有非常多東西值得探討，而且我相信很多人都看過或聽過，架構是可以選擇的，每個架構都有他的優點與缺點，這看起來是非常合理的一個論點，但是，實際在開發上真的是這樣嗎？那為什麼大家現在都在推崇 MVVM 跟 Clean Architecture？沒有其他選擇嗎？在更深入說明之前，我想跟大家分享一下我從以前到現在的成長心路歷程。

在一開始的 Android 發展中，大家其實是沒有在很熱絡的在討論架構的，大概在七年前吧，我的第一份工作是一個接案公司，那時面試的時候面試官都會問 MVC 是什麼，然後我也只能用網路上教的定義把他背出來，但實際上怎麼用還是完全不知道。甚至到後來我也完全沒用過 MVC。到公司的第一個專案，是個檔案管理系統 App，那時有一個很資深的前輩把大致上的架構都定好了，他負責底層的部分，我跟另一個同事則是負責 UI 顯示以及串接資深同事所提供的介面，但由於我是新人，所以頂多就是解解 Bug 這樣。到後來有一次前輩介紹架構時，才知道這個 App 有分三到四個不同的層，資料從底層傳出來，我們需要使用 Callback 的方式來拿這些資料。那這是 MVC 嗎？我也不知道，只覺得前輩很厲害，程式碼都寫得很清楚讓我們一看就懂。

後來公司接了一個藍芽手錶的專案，全部讓我負責完成，這次在前輩的協助下使用了事件驅動的架構，這專案很順利的完成了，後來老闆又接了另一個案子，也是一個藍芽手錶的 App，然後在沿用上一個專案的程式碼之後，這專案在一個禮拜就完成了！值得一提的是，在這專案中，沒有使用任何的 MVX 架構模式，在顯示方面，我直接在 Activity, Fragment 做資料的串接，簡單又快速！

後來到了第二間公司首次見到了“大泥球”（The big ball of mud），一個 Activity 中竟然有一萬多行程式碼！後來雖然有嘗試著重構程式碼，但是其成效有限，因為這專案的現況不允許有長時間的重構，要嘛就放棄這專案，要嘛就是加新功能看使用者會不會喜歡。

離開了這間公司之後，開始流行了 MVP （Model-View-Presenter），Google 在那時候有提供了一個 MVP 範例，算是給大家有一個指引，給想要入門架構的人知道可以怎麼做：一個 View 的 Contract ，還有配上一個 Presenter 去使用這個 Contract。加上那時候也開始學習寫更多測試了，所以我那時候也很喜歡這個模式，因為這樣的設計，就可以讓我寫很多測試在 Presenter 上。但快樂的時光總是過的特別的快，專案越來越大後，我開始感受到 Mock 物件是一件非常令人厭煩的事，為了要驗證一個簡單的流程，我竟然還要寫十幾行的程式碼來做前置設定！然後最重要的測試程式碼呢？往往不到五行！那我驗證了什麼呢？我只驗證了一個點擊行為是不是會開啟下一個頁面，就這樣！驗證使用者的操作一定這麼複雜嗎？在那時候，這是一個很想知道的答案。

在更之後，就是大家現在正在用的 MVVM 了，那時候也是 Clean architecture 這本書原文版出版的時間，我在第一時間就買了這本書，雖然一開始不太好懂就是了（尤其是相依反轉那邊）。我從中學到了很多，後來也在 GDG Devfest 有一個公開演講，為了要準備這演講，也讓我了解的更深入。在理解了全貌之後，我越來越喜歡上它了，甚至我會想在所有的專案上都使用這個架構。也在差不多這時候，我開始觀察到了很多...架構 library 。對於這個現象，我總覺得哪裡怪怪的，為什麼需要有一個 Library 來幫我們做架構？但是也說不上來為什麼奇怪，如果有人要跟我吵我應該也沒立足點ＸＤ。在 Clean architecture 中我看到的是每一個層級的相依性，外層認識內層，內層不認識外層，但是一定要有 Entity 或是 Use case 嗎？我不確定，但是我能確定的是我不喜歡用一個 Library 來對我的專案動手腳。

在加入了 PicCollage 之後，讓我眼界大開，我曾經以為，我已經沒有東西可以學了，在架構的文獻上我能看的幾乎都看了，但是在這裡我遇到了極度複雜的專案，很多問題不是靠 Clean architecture 的知識或是任何其他我過往的知識就可以解決的了，真為過去自滿的自己感到丟臉。非常幸運的是，我剛進去的時候碰到架構的大整頓，在這裡是使用 CTO 獨創的 MDDV 架構，在幫忙完成這架構的過程中，慢慢做中學，現在事後來看，我在當時也犯了一些錯誤，也對這架構有些誤解。

又在差不多一年之後，在同事以及主管的推坑下接觸到了 DDD (Domain Driven Design)，看完之後又發現了一個新天地！這不是正是我們工作中需要的嗎？如果從 PM ，Designer ，到 iOS ，大家都能夠用共通語言溝通、維護、設計，那麼打掉重練的風險就能大大降低了不是嗎？

以上就是我從工作到現在大致上的心路歷程，接下來 30 天的內容將會分享更多我的心得，不知道讀者你的故事又是如何呢？如果你從工作到現在只碰過 MVVM ，不管你是資歷幾年的工程師，我都強烈建議你可以開始試著做一個複雜的專案，在這轉案中你會碰到很多大大小小不同的問題，而且這些問題複雜到需要把電腦暫時放到一旁，使用紙跟筆，畫出元件跟元件之間的關係以及職責。最好的情況是，這個關係圖，就算解釋給非技術人員，他也是能夠知道你在說什麼。

我在看 Clean Architecture 時很喜歡其中的一句話：The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity. 在導入架構時，整體系統的 Cost 是變高還是變低呢？對於程序員來說，產值是變高還是變低的呢？這是非常值得思考的。如果你要買房子的話，應該也不會奢望有完美格局，完美的環境，還有完美的鄰居（除非妳夠有錢）。找伴侶也是同理，找工作也是一樣，軟體架構也是如此，沒有最完美的架構，只有最適合你現在專案的架構。下一篇，就來正式開始介紹我這次的專案：線上便利貼。