開(kāi)發(fā)者的價(jià)值，是通過(guò)技術(shù)和產(chǎn)品體現(xiàn)的，對(duì)于App開(kāi)發(fā)來(lái)說(shuō)，除了實(shí)現(xiàn)業(yè)務(wù)之外，最重要的莫過(guò)于開(kāi)發(fā)的速度、質(zhì)量和可維護(hù)性，速度決定你能否支撐公司搶占市場(chǎng)，質(zhì)量決定你們能不能站穩(wěn)位置不被迅速踢走，可維護(hù)性決定你們繼續(xù)前行時(shí)能否保持輕快的步伐。
速度、質(zhì)量和可維護(hù)性
對(duì)速度、質(zhì)量和可維護(hù)性的要求，其實(shí)就是又快，又穩(wěn)，又清晰的要求。
快：快其實(shí)是最容易做到，或者說(shuō)最容易知道能不能做到的事情，熟悉的Android開(kāi)發(fā)的朋友都知道，如果能理清業(yè)務(wù)邏輯，不受干擾地投入開(kāi)發(fā)，開(kāi)發(fā)速度可以很快，一般普通規(guī)模的App，一到兩周就能完成。
穩(wěn)：穩(wěn)不像快，可以簡(jiǎn)單地用時(shí)間進(jìn)行即時(shí)的量化評(píng)價(jià)，我們要等大量bug出現(xiàn)之后，才知道穩(wěn)不穩(wěn)，可是一般趕工速度一快起來(lái)，就很容易出現(xiàn)大量bug。其實(shí)Android常見(jiàn)問(wèn)題無(wú)非是內(nèi)存、異步、響應(yīng)等，要排除和解決這些問(wèn)題很容易，難的是怎樣確保不出現(xiàn)這些問(wèn)題。
清晰：清晰是最難做到的，快可以通過(guò)時(shí)間量化，穩(wěn)可以通過(guò)bug統(tǒng)計(jì)量化，但是清晰是很難量化的，代碼審查和可擴(kuò)展性都是主觀評(píng)價(jià)，而且相當(dāng)滯后，很多情況下，往往要等到需要實(shí)現(xiàn)擴(kuò)展，甚至換人接手代碼時(shí)，才知道代碼不清晰。
對(duì)于開(kāi)發(fā)者來(lái)說(shuō)，怎樣才能又快又穩(wěn)又清晰地開(kāi)發(fā)App，這里梳理了我的幾點(diǎn)心得。
有限參與業(yè)務(wù)設(shè)計(jì)
從職責(zé)分工上，業(yè)務(wù)設(shè)計(jì)是運(yùn)營(yíng)部門(mén)和產(chǎn)品經(jīng)理的工作，確實(shí)不應(yīng)由研發(fā)負(fù)責(zé)，但我說(shuō)的是參與，研發(fā)（包括測(cè)試）應(yīng)當(dāng)盡早參與業(yè)務(wù)設(shè)計(jì)，一方面提前發(fā)現(xiàn)問(wèn)題，另一方面可以引導(dǎo)和建議技術(shù)路線。
研發(fā)參與設(shè)計(jì)，可以規(guī)避很多問(wèn)題，例如通信壓力、加載速度、延遲時(shí)間、硬件負(fù)載等移動(dòng)開(kāi)發(fā)特有問(wèn)題，不能指望運(yùn)營(yíng)和產(chǎn)品能像專(zhuān)業(yè)的研發(fā)一樣面面俱到，考慮周翔。
另一方面，研發(fā)參與設(shè)計(jì)還可以引導(dǎo)技術(shù)路線，例如采用原生App、混合App還是ReactNative形式，采用單用戶體系還是多用戶體系，采用什么收費(fèi)形式等。
在實(shí)際操作中，業(yè)務(wù)設(shè)計(jì)諸如收費(fèi)形式，異常提示，乃至于業(yè)務(wù)邏輯上的嚴(yán)密性，你都可能發(fā)現(xiàn)漏洞。
當(dāng)然，參與設(shè)計(jì)必然會(huì)占用研發(fā)時(shí)間，有人會(huì)覺(jué)得委屈，感覺(jué)這是替產(chǎn)品做了他們的工作，但其實(shí)研發(fā)參與設(shè)計(jì)，省下的還是自己的時(shí)間，因?yàn)闊o(wú)論產(chǎn)品如何設(shè)計(jì)，最終都需要技術(shù)來(lái)研發(fā)實(shí)現(xiàn)，如果設(shè)計(jì)上出了問(wèn)題，你修改代碼的投入，可比產(chǎn)品改文檔的那點(diǎn)兒投入大多了。
當(dāng)然，公司層面也應(yīng)有清楚的定位，研發(fā)對(duì)設(shè)計(jì)的投入，必須是有限的指導(dǎo)性的，如果大量把研發(fā)投入到設(shè)計(jì)工作，就是另一種形式的浪費(fèi)了。
異常處理
在實(shí)際開(kāi)發(fā)過(guò)程中，除bug其實(shí)占了相當(dāng)一部分工作量，有時(shí)候好好的開(kāi)發(fā)計(jì)劃，因?yàn)閹讉€(gè)詭異的bug就得耽誤半天，所謂“碼字5分鐘，排錯(cuò)兩小時(shí)”是也。所以，能否盡早盡快處理異常，是非常影響開(kāi)發(fā)效率的。
處理異常，我有這么幾條心得：
提前考慮異常處理，在寫(xiě)正常流程的業(yè)務(wù)代碼之前，先考慮異常，“未慮勝，先慮敗”，沿著業(yè)務(wù)流程分支，先把異常情況都處理掉，例如獲取在線數(shù)據(jù)顯示一個(gè)列表，先考慮網(wǎng)絡(luò)異常、服務(wù)器報(bào)錯(cuò)、數(shù)據(jù)失敗等異常情況，并依次給出相應(yīng)提示，最后才處理數(shù)據(jù)正常的情況，你本來(lái)就要寫(xiě)正常業(yè)務(wù)代碼和異常處理代碼，你只需要調(diào)換一下工作的先后順序，其實(shí)你投入的開(kāi)發(fā)時(shí)間沒(méi)有增加，但是你的效率卻大大提升了，因?yàn)橐坏┏霈F(xiàn)異常，我們可以迅速判斷異常原因，節(jié)省大量時(shí)間。
這樣做還有一個(gè)好處，在你的思維陷入復(fù)雜的業(yè)務(wù)邏輯之前，先處理相對(duì)簡(jiǎn)單的異常分支，可以避免你被業(yè)務(wù)邏輯搞到大腦缺氧后，再回來(lái)處理異常分支時(shí)一時(shí)疏忽手滑，寫(xiě)錯(cuò)或者寫(xiě)漏異常處理。
隔離前后臺(tái)對(duì)接的數(shù)據(jù)接口，最好不要直接使用后臺(tái)提供的數(shù)據(jù)，中間加一層映射，一方面，如果后臺(tái)數(shù)據(jù)出了問(wèn)題（數(shù)據(jù)異常、變更字段等），你在映射數(shù)據(jù)時(shí)就能發(fā)現(xiàn)和定位問(wèn)題；另一方面，也有利于你采用更適合App的數(shù)據(jù)形式進(jìn)行數(shù)據(jù)持久化。
另外，建議做一個(gè)接口錄入與檢查工具，形式不論，但要能輕松地維護(hù)前后臺(tái)接口，最好能自動(dòng)檢測(cè)接口反饋是否正常（服務(wù)器負(fù)載過(guò)大、字段變更、第三方服務(wù)過(guò)期等）。
異常信息的收集、匯總和數(shù)據(jù)持久化
如果出現(xiàn)異常，最重要的是采集到異常代碼行(如MainActivity第61行)和異常原因(如空指針異常)，并記錄為本地文件以備上傳和查看
具體見(jiàn)App的異常崩潰處理:
其實(shí)java的異常處理的內(nèi)容還有很多，感興趣可以看一看我以前總結(jié)過(guò)的Java異常捕獲的設(shè)計(jì)原則:
結(jié)構(gòu)分層
使用框架是必須的，Model層，View層必須職責(zé)單一，至于使用MVP、MVVM還是別的什么就看個(gè)人偏好和項(xiàng)目需要了。個(gè)人比較偏好MVP，感興趣可以看一看MVP框架的演化,當(dāng)然，Rx鏈?zhǔn)骄幊桃膊诲e(cuò)。
* 個(gè)人在結(jié)構(gòu)分層上，有這么幾個(gè)經(jīng)驗(yàn)：
高內(nèi)聚的數(shù)據(jù)層，把與數(shù)據(jù)讀寫(xiě)相關(guān)的處理，網(wǎng)絡(luò)
52010202000664