前言
開發(fā)者的價(jià)值，是通過技術(shù)和產(chǎn)品體現(xiàn)的，對(duì)于App開發(fā)來說，除了實(shí)現(xiàn)業(yè)務(wù)之外，最重要的莫過于開發(fā)的速度、質(zhì)量和可維護(hù)性，速度決定你能否支撐公司搶占市場(chǎng)，質(zhì)量決定你們能不能站穩(wěn)位置不被迅速踢走，可維護(hù)性決定你們繼續(xù)前行時(shí)能否保持輕快的步伐。南寧網(wǎng)站建設(shè)
速度、質(zhì)量和可維護(hù)性
對(duì)速度、質(zhì)量和可維護(hù)性的要求，其實(shí)就是又快，又穩(wěn)，又清晰的要求。
快：快其實(shí)是最容易做到，或者說最容易知道能不能做到的事情，熟悉的Android開發(fā)的朋友都知道，如果能理清業(yè)務(wù)邏輯，不受干擾地投入開發(fā)，開發(fā)速度可以很快，一般普通規(guī)模的App，一到兩周就能完成。
穩(wěn)：穩(wěn)不像快，可以簡(jiǎn)單地用時(shí)間進(jìn)行即時(shí)的量化評(píng)價(jià)，我們要等大量bug出現(xiàn)之后，才知道穩(wěn)不穩(wěn)，可是一般趕工速度一快起來，就很容易出現(xiàn)大量bug。其實(shí)Android常見問題無非是內(nèi)存、異步、響應(yīng)等，要排除和解決這些問題很容易，難的是怎樣確保不出現(xiàn)這些問題。
清晰：清晰是最難做到的，快可以通過時(shí)間量化，穩(wěn)可以通過bug統(tǒng)計(jì)量化，但是清晰是很難量化的，代碼審查和可擴(kuò)展性都是主觀評(píng)價(jià)，而且相當(dāng)滯后，很多情況下，往往要等到需要實(shí)現(xiàn)擴(kuò)展，甚至換人接手代碼時(shí)，才知道代碼不清晰。
對(duì)于開發(fā)者來說，怎樣才能又快又穩(wěn)又清晰地開發(fā)App，這里梳理了我的幾點(diǎn)心得。
有限參與業(yè)務(wù)設(shè)計(jì)
從職責(zé)分工上，業(yè)務(wù)設(shè)計(jì)是運(yùn)營(yíng)部門和產(chǎn)品經(jīng)理的工作，確實(shí)不應(yīng)由研發(fā)負(fù)責(zé)，但我說的是參與，研發(fā)（包括測(cè)試）應(yīng)當(dāng)盡早參與業(yè)務(wù)設(shè)計(jì)，一方面提前發(fā)現(xiàn)問題，另一方面可以引導(dǎo)和建議技術(shù)路線。
研發(fā)參與設(shè)計(jì)，可以規(guī)避很多問題，例如通信壓力、加載速度、延遲時(shí)間、硬件負(fù)載等移動(dòng)開發(fā)特有問題，不能指望運(yùn)營(yíng)和產(chǎ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ì)覺得委屈，感覺這是替產(chǎn)品做了他們的工作，但其實(shí)研發(fā)參與設(shè)計(jì)，省下的還是自己的時(shí)間，因?yàn)闊o論產(chǎn)品如何設(shè)計(jì)，最終都需要技術(shù)來研發(fā)實(shí)現(xiàn)，如果設(shè)計(jì)上出了問題，你修改代碼的投入，可比產(chǎn)品改文檔的那點(diǎn)兒投入大多了。
當(dāng)然，公司層面也應(yīng)有清楚的定位，研發(fā)對(duì)設(shè)計(jì)的投入，必須是有限的指導(dǎo)性的，如果大量把研發(fā)投入到設(shè)計(jì)工作，就是另一種形式的浪費(fèi)了。
異常處理
在實(shí)際開發(fā)過程中，除bug其實(shí)占了相當(dāng)一部分工作量，有時(shí)候好好的開發(fā)計(jì)劃，因?yàn)閹讉€(gè)詭異的bug就得耽誤半天，所謂“碼字5分鐘，排錯(cuò)兩小時(shí)”是也。所以，能否盡早盡快處理異常，是非常影響開發(fā)效率的。
處理異常，我有這么幾條心得：
提前考慮異常處理，在寫正常流程的業(yè)務(wù)代碼之前，先考慮異常，“未慮勝，先慮敗”，沿著業(yè)務(wù)流程分支，先把異常情況都處理掉，例如獲取在線數(shù)據(jù)顯示一個(gè)列表，先考慮網(wǎng)絡(luò)異常、服務(wù)器報(bào)錯(cuò)、數(shù)據(jù)失敗等異常情況，并依次給出相應(yīng)提示，最后才處理數(shù)據(jù)正常的情況，你本來就要寫正常業(yè)務(wù)代碼和異常處理代碼，你只需要調(diào)換一下工作的先后順序，其實(shí)你投入的開發(fā)時(shí)間沒有增加，但是你的效率卻大大提升了，因?yàn)橐坏┏霈F(xiàn)異常，我們可以迅速判斷異常原因，節(jié)省大量時(shí)間。
這樣做還有一個(gè)好處，在你的思維陷入復(fù)雜的業(yè)務(wù)邏輯之前，先處理相對(duì)簡(jiǎn)單的異常分支，可以避免你被業(yè)務(wù)邏輯搞到大腦缺氧后，再回來處理異常分支時(shí)一時(shí)疏忽手滑，寫錯(cuò)或者寫漏異常處理。
隔離前后臺(tái)對(duì)接的數(shù)據(jù)接口，最好不要直接使用后臺(tái)提供的數(shù)據(jù)，中間加一層映射，一方面，如果后臺(tái)數(shù)據(jù)出了問題（數(shù)據(jù)異常、變更字段等），你在映射數(shù)據(jù)時(shí)就能發(fā)現(xiàn)和定位問題；另一方面，也有利于你采用更適合App的數(shù)據(jù)形式進(jìn)行數(shù)據(jù)持久化。
另外，建議做一個(gè)接口錄入與檢查工具，形式不論，但要能輕松地維護(hù)前后臺(tái)接口，最好能自動(dòng)檢測(cè)接口反饋是否正常（服務(wù)器負(fù)載過大、字段變更、第三方服務(wù)過期等）。
異常信息的收集、匯總和數(shù)據(jù)持久化
如果出現(xiàn)異常，最重要的是采集到異常代碼行(如MainActivity第61行)和異常原因(如空指針異常)，并記錄為本地文件以備上傳和查看
具體見App的異常崩潰處理:
https://www.jianshu.com/p/367b4d851ed4
其實(shí)java的異常處理的內(nèi)容還有很多，感興趣可以看一看我以前總結(jié)過的Java異常捕獲的設(shè)計(jì)原則:
https://www.jianshu.com/p/1e0199e3c34e
結(jié)構(gòu)分層
使用框架是必須的，Model層，View層必須職責(zé)單一，至于使用MVP、MVVM還是別的什么就看個(gè)人偏好和項(xiàng)目需要了。個(gè)人比較偏好MVP，感興趣可以看一看MVP框架的演化:https://www.jianshu.com/p/5d8481313f00，當(dāng)然，Rx鏈?zhǔn)骄幊桃膊诲e(cuò)。
* 個(gè)人在結(jié)構(gòu)分層上，有這么幾個(gè)經(jīng)驗(yàn)：
高內(nèi)聚的數(shù)據(jù)層，把與數(shù)據(jù)讀寫相關(guān)的處理，網(wǎng)絡(luò)讀寫、本地讀寫、緩存數(shù)據(jù)等，包括模擬數(shù)據(jù)，都集中到數(shù)據(jù)層，通過回調(diào)或鏈?zhǔn)秸{(diào)用等方式拋出數(shù)據(jù)給業(yè)務(wù)層，通過多版本機(jī)制切換模擬數(shù)據(jù)和真實(shí)數(shù)據(jù)。
松耦合的Activity，界面應(yīng)該是與業(yè)務(wù)相關(guān)最低的，主要提供一個(gè)顯示載體，并觸發(fā)生命周期處理，Activity應(yīng)該可以很容易地被替換掉。
獨(dú)立且方便測(cè)試的業(yè)務(wù)層，業(yè)務(wù)層應(yīng)該可以實(shí)現(xiàn)自動(dòng)化測(cè)試，這非常重要，即使你不去實(shí)施自動(dòng)化測(cè)試，把代碼寫成可以自動(dòng)化測(cè)試的，也能幫你優(yōu)化代碼，該抽象的抽象，該剝離的剝離。
必要時(shí)抽象特殊控件，如果控件需要復(fù)用，就不要讓控件融合進(jìn)Activity，而是抽象為獨(dú)立的顯示控件，這樣既能解耦合，又方便復(fù)用。
不要過度設(shè)計(jì)
敏捷開發(fā)里有一個(gè)實(shí)踐原則，就是不要過度設(shè)計(jì)，開發(fā)的價(jià)值不在于寫出漂亮的代碼，在于實(shí)現(xiàn)產(chǎn)品并支撐其正常運(yùn)轉(zhuǎn)，在能實(shí)現(xiàn)產(chǎn)品功能的前提下，代碼邏輯其實(shí)是越簡(jiǎn)單越好，簡(jiǎn)單往往就意味著高可靠性+低維護(hù)成本，如果將來需要擴(kuò)展功能，可以通過修改和重構(gòu)實(shí)現(xiàn)。
當(dāng)然，簡(jiǎn)單并不意味著隨意，要把事件做復(fù)雜很容易，要做簡(jiǎn)單卻很難。能做到邏輯清晰、線程安全、內(nèi)存安全，又容易修改和擴(kuò)展的同時(shí)，還能保持代碼簡(jiǎn)潔，其實(shí)反而更考驗(yàn)功力的。
其實(shí)不僅在開發(fā)新功能時(shí)要避免過度設(shè)計(jì)，在維護(hù)和擴(kuò)展舊代碼時(shí)，也要注意，能正常運(yùn)行的代碼，都是好代碼，我覺得在維護(hù)舊代碼時(shí)，其實(shí)也適用開放封閉原則，對(duì)不得不改，不改就崩的舊代碼，是開放的，可以修改的；對(duì)能正常運(yùn)行的代碼，哪怕你覺得再難看再手癢，那也是封閉的，是不可以修改的。
回到那句話，開發(fā)的價(jià)值不在于寫出漂亮的代碼，在于實(shí)現(xiàn)產(chǎn)品并支撐其正常運(yùn)轉(zhuǎn)。南寧APP開發(fā)
通用庫(kù)的建立與維護(hù)
我們知道，項(xiàng)目管理有四個(gè)要素，時(shí)間、成本、范圍、質(zhì)量，這四個(gè)要素一般是不能兼得的，要時(shí)間，就得砍一些范圍的項(xiàng)目目標(biāo)，降成本，就容易犧牲質(zhì)量，等等，不過，建立和維護(hù)通用庫(kù)，卻能同時(shí)對(duì)四個(gè)要素都有好處。
加快開發(fā)速度，專注于具體業(yè)務(wù)（時(shí)間）
降低團(tuán)隊(duì)成員熟悉項(xiàng)目的成本，為新業(yè)務(wù)開發(fā)提供基礎(chǔ)，加快開發(fā)迭* 代速度，有利于更快地發(fā)布版本
提高代碼復(fù)用率，降低開發(fā)投入（成本）
穩(wěn)定的公共模塊采用依賴組件庫(kù)方式，提供給各個(gè)業(yè)務(wù)線協(xié)作使用，* 減少重復(fù)開發(fā)和升級(jí)維護(hù)工作量
提升開發(fā)效率，更容易實(shí)現(xiàn)項(xiàng)目目標(biāo)（范圍）
對(duì)已實(shí)現(xiàn)過的功能/業(yè)務(wù)，抽象出通用模塊，再有類似的需求，能夠 迅速實(shí)現(xiàn)，更容易實(shí)現(xiàn)項(xiàng)目的業(yè)務(wù)需求
提升產(chǎn)品質(zhì)量，持續(xù)改進(jìn)通用功能（質(zhì)量）
頻繁使用的功能/業(yè)務(wù)模塊采用組件復(fù)用方式，更有利于暴露缺陷， 一處修改，多處受益，提高產(chǎn)品質(zhì)量
工具與模板等
其實(shí)說起提高效率，前面的很多經(jīng)驗(yàn)因?yàn)樾枰趯?shí)際開發(fā)中慢慢體會(huì)，難以迅速上手，反而是工具模板，真正見效快，一次安裝，終生受益 :)
就我的經(jīng)驗(yàn)而言，對(duì)我開發(fā)效率幫助最大的，包括代碼模板、常用配置和開發(fā)插件，以及著名的程序員在線交友網(wǎng)站Github。
代碼注釋
一般來說，程序員看自己一個(gè)月前寫的代碼，是完全陌生的，我也一樣，基本上過一個(gè)月就沒印象了，但是如果要修改/擴(kuò)展怎么辦，這時(shí)候，就得看代碼注釋了。就個(gè)人經(jīng)驗(yàn)而言，有這么幾個(gè)地方，一定要寫注釋：
接口，特別是MVP的Contract接口，這里面基本定義了你的主要業(yè)務(wù)行為，誰來加載數(shù)據(jù)，誰來顯示數(shù)據(jù)，誰觸發(fā)的下一步操作，這些內(nèi)容寫明白了，以后讀代碼，只要看接口就知道主要業(yè)務(wù)是怎么回事兒了。
服務(wù)、廣播等，服務(wù)和廣播因?yàn)闆]有界面，容易游離在業(yè)務(wù)邏輯鏈條之外，在業(yè)務(wù)邏輯上缺少上下文，就必須有詳盡的注釋，說明其業(yè)務(wù)場(chǎng)景。
初始化、注入等，如果自定義了一些擴(kuò)展的功能或控件，要求執(zhí)行某些初始化函數(shù)，或者要注入特定功能的，就必須寫好注釋，提示調(diào)用者進(jìn)行必要的操作。
TODO，工作總要排優(yōu)先級(jí)的，有些工作暫時(shí)延后，自己記錄是沒用的，團(tuán)隊(duì)開發(fā)最終用的還是代碼，所以一定要寫TODO，提示開發(fā)者，這里是未完成的狀態(tài)，避免不必要的誤會(huì)和延誤。
