花了半個月，總算寫到架構這個章節，
本篇章主旨是介紹Android近年來的架構轉變，
筆者認為App專案的依造大小可以分為:
需架構的小專案(不用架構)，
中等專案的使用MVP及
複雜專案的使用AAC(MVVM)，
未來會不會有其他的架構筆者不敢保證說沒有，
但目前流行是這幾套在迭代：

要如何分別專案大小呢？
如果App的需求很單純，沒有什麼複雜的功能，
就是Demo或一次性的App（例如展示如何讀取藍芽訊號並顯示在畫面上），
就不太需要架構，而需要稍微複雜的功能或是App之後有維運需求，
如會員系統，會接網路服務，就最好實作一些架構，
至少也要實作MVP架構，而如果App會有複雜的應用，
如需要大量資料的運算，或是App可以轉畫面
(Android Rotation可是跨 Activity life cycle的難題)
仍然可以持續運作的之類的，就可以試著時間實作AAC (MVVM)。

筆者以前並不覺得MVVM比較好，因為那時Google尚未正式支援，
且以往MVVM的架構都會搭配Databinding，
而Databinding，就筆者的認知，在升級的時候實在太不穩定，
很容易因為版本升級就造成Build不起來的困擾。

因此筆者以前都是抱持反對的態度去實作這個框架在應用上，
但今年重新Survey後，發現現在Google提倡的AAC 架構，
可以脫鉤Databinding，同樣透過ViewModel和LiveData，
達成MVVM的目的，因此筆者現在認為這個架構已經比MVP更具有彈性及發展性。

但如果手上的專案已經用MVP執行得很穩定了，筆者認為不用因此改用AAC，
除非有大需求，不然MVP也可以做到AAC的目的，只是沒那麼方便，
但是筆者認為MVP仍有他的優勢，你可以很清楚的知道你的每段程式的執行情況，
AAC在架構上的抽象程度較高，學習曲線比較高些。

無架構

優點：想怎麼寫就怎麼寫，容易了解實作者的想法
(除非這份程式連變數都命名的很糟糕)。

特徵：你容易在Activity或Fragment上看到邏輯跟UI的程式混雜，
可能在某個Adapter或是開發者自定義的Class裡面，
看到UI元件跟Context or Activity 共處一室，
就是俗稱的玻璃心架構[1]。（高耦合、低內聚）

缺點：無法寫測試程式，改動時程很長、增加功能時程也很長。
(不重構無法確保程式的穩定性、也無法寫測試程式、
但重構又會延遲新功能的開發時程，整包程式太龐大的時候還不如重新開發。)

筆者覺得會開發出沒有架構的程式，很多時候不會只是開發者的問題，
整個開發從需求釐清規劃到系統規劃的開發時程上，
一般來說，都會有時間去逐步規劃整個程式的架構。

但如果接手的程式已經是這種樣子了，站在開發者的立場最該做的事情，
是馬上讓這個問題的資訊被散播出去，
這樣不論是對業務端或是對管理階層都會是一個相對好的情況，
而不是悶著頭瞎幹，然後一直延遲時程，
拖到了Dead line才讓其他人知道做不出來，
這樣對團隊來說不會是比較好的事情，
提早知道可以提早做事前準備，也不會讓壓力落在自己身上。

至於怎麼溝通讓別人知道目前的程式架構跟整個程式狀態，
這又是另一個篇章，後面會再提到，
今天就講到這～謝謝各位的觀看。

本文同步刊登在Medium上，連結在此。

[1] 软件架构模式