前言
在開始正文之前容我先描述幾個場景，可能你也遇到過或者將要遇到，也可能你已經完美的解決了這些問題。現在我把它們拿出來跟大家討論。
場景一
同事A離職，他負責的是報表模塊，同事B是一個剛畢業的大學生。某天產品經理說報表模塊需要改動，交給B來負責。同事A走的時候沒有交接，沒寫文檔，需要B從頭理清然後修改。然後B在看的過程中發現，A的代碼命名既有拼音又有英文，還有一些毫無關聯的命名。如下：
var ischange ='false'; //查詢條件是否改變
var ssssss=[]; //保存上一次結果的笛卡爾積
var mapaddWei = new Array();//保存小分類的值並且A的一個方法包含100行到1000多行代碼不等。致使B花了大概一週多的時間才把A的代碼完全看懂。
場景二
A所在公司的App1.0版本已經上線。連續進行了4次小更新後的某天，產品經理又要求A去修改主頁面，包括UI和部分邏輯的變動。改完之後又過了不久，產品經理提出要增加一個商城模塊。這時候A發現，項目越來越臃腫，代碼越改越亂，越改越爛，甚至自己寫的類都忘記了放在哪個包下。
之後用戶反饋說Android5.0系統註冊閃退。A和同事通過查找發現問題出在網絡框架上，他們所用的網絡框架不支持5.0及以上系統。但是由於在最開始設計這款App的時候沒有再網絡框架的上層封裝一層自己的接口，導致所有用到網絡請求的地方都需要修改。
通過這兩個場景我們可以發現，一個App的可維護性和可擴展性在開發中是尤爲重要的，本文所講述的這些Tips概括的說明了如何去構建一個可維護可擴展的App。
包結構
對於包結構來說，個人覺得簡單明瞭就好，保證讓人一目瞭然，方便查找。大概有兩種分法：按主題分和按功能分。
按主題分，如下圖所示
按模塊分，如下圖
相比較來說，第二種的優勢在於如果我們要增加模塊的話，我們只需新增一個包，其他包的內容基本不需要動。而且當我們修改固定模塊的時候也更方便查找我們要修改的內容。
代碼風格
代碼風格對代碼的可讀性影響很多，基本上java入門篇必談。一段很難看懂的代碼維護起來無疑成本會變高很多。
命名規範
Android中的變量和方法的命名要能正確的體現出他們的含義，符合駝峯命名法，儘量不要用縮寫。還有一些習慣性的寫法如常量寫成public static final 然後名字全用大寫等等。
排版
同類變量放在一組聲明，不同組之間用空白行隔開。不同代碼塊之間儘量也要留一個空白行。
註釋
爲關鍵代碼添加註釋。如果你的代碼命名合理的話，那麼大部分代碼還是不用添加註釋的。
代碼層次和單一職責原則
不要試圖讓一個司機去做廚子的事。
把一段業務邏輯細分爲幾個子邏輯，每個子邏輯只關注自己的工作，讓職責變的單一。
舉個栗子。皇帝說“朕今天中午想吃滿漢全席”。這時候太監就會去通知御膳房。御膳房總管會分配採購人員去準備材料，然後吩咐御廚去給皇上做滿漢全席。這樣整個業務邏輯就比較清晰了，同時太監做了太監的事，御廚做了御廚的事，各司其職。
面向接口編程
在一個面向對象的系統中，系統的各種功能是由許許多多的不同對象協作完成的。在這種情況下，各個對象內部是如何實現自己的,對系統設計人員來講就不那麼重要了；而各個對象之間的協作關係則成爲系統設計的關鍵。小到不同類之間的通信，大到各模塊之間的交互，在系統設計之初都是要着重考慮的，這也是系統設計的主要工作內容。面向接口編程就是指按照這種思想來編程。
拿第二個場景來說，我們自己封裝一個網絡操作接口，這個接口規定了他的實現類可以實現post請求。然後我們去調用接口的post方法。這樣無論我們用xutils還是volley或者okhttp去實現post方法，修改起來對替他部分都不會有影響。
面向擴展編程
其實這個點能不能把握好，更多的是看個人經驗。如果考慮到某個模塊的邏輯到後面會做一些改動，那我們在最開始設計的時候就可以爲這個模塊留出來更改的餘地，這樣就能更好的去擴展我們的應用，同時減少因爲擴展帶來的工作量。
設計模式
設計模式包含兩部分，一部分是App的設計模式，另一部分是App內模塊的設計模式。良好並且適度的設計模式會給我們App的擴展和維護節約很大成本。
App的設計模式
Android中App的設計模式包括早期的MVC模式和最近比較流行的MVP和MVVM模式。
MVC模式大家肯定已經很熟悉了，這裏就不多說了。對於MVP模式，我和同事在上一個版本的App中做了一些嘗試。
MVP無疑是有好多有點的：1、Model與View完全分離，它們通過接口進行交互，便於維護和測試。2、可以更高效地使用Model，因爲所有對Model的操作都在Presenter內部。3、我們可以將一個Presener用於多個視圖，只需要在Presenter中爲不同的View定義View Interface即可，具體的View實現自己的View Interface，即可使用Presenter中的Model操作等。
但是它會帶來額外的代碼複雜度及學習成本。對於一個小的開發團隊來說，可能效果並不會像想象中的那麼明顯。
App內模塊的設計模式
常見的設計模式有很多，比如工廠模式，單利模式，適配器模式，觀察者模式等等，由於本篇博客只是系統的討論，就不對細節做過多說明了，大家可以研究一下《大話設計模式》和《HeadFrist設計模式》等等。
寫本篇博客權當拋磚引玉了，感興趣的朋友大家可以一起討論。
