iT邦幫忙

2021 iThome 鐵人賽

DAY 1
2
Mobile Development

Jetpack Compose X Android Architecture X Functional Reactive Programming系列 第 1

前言與自我回顧

歡迎大家來看我的文章,這次我挑戰的主題是 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 來幫我們做架構?但是也說不上來為什麼奇怪,如果有人要跟我吵我應該也沒立足點XD。在 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 是變高還是變低呢?對於程序員來說,產值是變高還是變低的呢?這是非常值得思考的。如果你要買房子的話,應該也不會奢望有完美格局,完美的環境,還有完美的鄰居(除非妳夠有錢)。找伴侶也是同理,找工作也是一樣,軟體架構也是如此,沒有最完美的架構,只有最適合你現在專案的架構。下一篇,就來正式開始介紹我這次的專案:線上便利貼。


下一篇
便利貼 App 專案介紹
系列文
Jetpack Compose X Android Architecture X Functional Reactive Programming30

尚未有邦友留言

立即登入留言