開發(fā)者的價值，是通過技術和產品體現(xiàn)的，對于App開發(fā)來說，除了實現(xiàn)業(yè)務之外，最重要的莫過于開發(fā)的速度、質量和可維護性，速度決定你能否支撐公司搶占市場，質量決定你們能不能站穩(wěn)位置不被迅速踢走，可維護性決定你們繼續(xù)前行時能否保持輕快的步伐。

速度、質量和可維護性

對速度、質量和可維護性的要求，其實就是又快，又穩(wěn)，又清晰的要求。

快：快其實是最容易做到，或者說最容易知道能不能做到的事情，熟悉的Android開發(fā)的朋友都知道，如果能理清業(yè)務邏輯，不受干擾地投入開發(fā)，開發(fā)速度可以很快，一般普通規(guī)模的App，一到兩周就能完成。

穩(wěn)：穩(wěn)不像快，可以簡單地用時間進行即時的量化評價，我們要等大量bug出現(xiàn)之后，才知道穩(wěn)不穩(wěn)，可是一般趕工速度一快起來，就很容易出現(xiàn)大量bug。其實Android常見問題無非是內存、異步、響應等，要排除和解決這些問題很容易，難的是怎樣確保不出現(xiàn)這些問題。

清晰：清晰是最難做到的，快可以通過時間量化，穩(wěn)可以通過bug統(tǒng)計量化，但是清晰是很難量化的，代碼審查和可擴展性都是主觀評價，而且相當滯后，很多情況下，往往要等到需要實現(xiàn)擴展，甚至換人接手代碼時，才知道代碼不清晰。

對于開發(fā)者來說，怎樣才能又快又穩(wěn)又清晰地開發(fā)App，這里梳理了我的幾點心得。

有限參與業(yè)務設計

從職責分工上，業(yè)務設計是運營部門和產品經理的工作，確實不應由研發(fā)負責，但我說的是參與，研發(fā)（包括測試）應當盡早參與業(yè)務設計，一方面提前發(fā)現(xiàn)問題，另一方面可以引導和建議技術路線。

研發(fā)參與設計，可以規(guī)避很多問題，例如通信壓力、加載速度、延遲時間、硬件負載等移動開發(fā)特有問題，不能指望運營和產品能像專業(yè)的研發(fā)一樣面面俱到，考慮周翔。

另一方面，研發(fā)參與設計還可以引導技術路線，例如采用原生App、混合App還是ReactNative形式，采用單用戶體系還是多用戶體系，采用什么收費形式等。

在實際操作中，業(yè)務設計諸如收費形式，異常提示，乃至于業(yè)務邏輯上的嚴密性，你都可能發(fā)現(xiàn)漏洞。

當然，參與設計必然會占用研發(fā)時間，有人會覺得委屈，感覺這是替產品做了他們的工作，但其實研發(fā)參與設計，省下的還是自己的時間，因為無論產品如何設計，最終都需要技術來研發(fā)實現(xiàn)，如果設計上出了問題，你修改代碼的投入，可比產品改文檔的那點兒投入大多了。

當然，公司層面也應有清楚的定位，研發(fā)對設計的投入，必須是有限的指導性的，如果大量把研發(fā)投入到設計工作，就是另一種形式的浪費了。

異常處理

在實際開發(fā)過程中，除bug其實占了相當一部分工作量，有時候好好的開發(fā)計劃，因為幾個詭異的bug就得耽誤半天，所謂“碼字5分鐘，排錯兩小時”是也。所以，能否盡早盡快處理異常，是非常影響開發(fā)效率的。

處理異常，我有這么幾條心得：

提前考慮異常處理，在寫正常流程的業(yè)務代碼之前，先考慮異常，“未慮勝，先慮敗”，沿著業(yè)務流程分支，先把異常情況都處理掉，例如獲取在線數(shù)據(jù)顯示一個列表，先考慮網絡異常、服務器報錯、數(shù)據(jù)失敗等異常情況，并依次給出相應提示，最后才處理數(shù)據(jù)正常的情況，你本來就要寫正常業(yè)務代碼和異常處理代碼，你只需要調換一下工作的先后順序，其實你投入的開發(fā)時間沒有增加，但是你的效率卻大大提升了，因為一旦出現(xiàn)異常，我們可以迅速判斷異常原因，節(jié)省大量時間。

這樣做還有一個好處，在你的思維陷入復雜的業(yè)務邏輯之前，先處理相對簡單的異常分支，可以避免你被業(yè)務邏輯搞到大腦缺氧后，再回來處理異常分支時一時疏忽手滑，寫錯或者寫漏異常處理。

隔離前后臺對接的數(shù)據(jù)接口，最好不要直接使用后臺提供的數(shù)據(jù)，中間加一層映射，一方面，如果后臺數(shù)據(jù)出了問題（數(shù)據(jù)異常、變更字段等），你在映射數(shù)據(jù)時就能發(fā)現(xiàn)和定位問題；另一方面，也有利于你采用更適合App的數(shù)據(jù)形式進行數(shù)據(jù)持久化。

另外，建議做一個接口錄入與檢查工具，形式不論，但要能輕松地維護前后臺接口，最好能自動檢測接口反饋是否正常（服務器負載過大、字段變更、第三方服務過期等）。

異常信息的收集、匯總和數(shù)據(jù)持久化

如果出現(xiàn)異常，最重要的是采集到異常代碼行(如MainActivity第61行)和異常原因(如空指針異常)，并記錄為本地文件以備上傳和查看

具體見App的異常崩潰處理:

其實java的異常處理的內容還有很多，感興趣可以看一看我以前總結過的Java異常捕獲的設計原則: 

結構分層

使用框架是必須的，Model層，View層必須職責單一，至于使用MVP、MVVM還是別的什么就看個人偏好和項目需要了。個人比較偏好MVP，感興趣可以看一看MVP框架的演化,當然，Rx鏈式編程也不錯。

* 個人在結構分層上，有這么幾個經驗：

高內聚的數(shù)據(jù)層，把與數(shù)據(jù)讀寫相關的處理，網絡