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

速度千所、質(zhì)量和可維護(hù)性

對速度、質(zhì)量和可維護(hù)性的要求蒜埋，其實就是又快淫痰，又穩(wěn)，又清晰的要求整份。

• 快：快其實是最容易做到待错，或者說最容易知道能不能做到的事情，熟悉的Android開發(fā)的朋友都知道烈评，如果能理清業(yè)務(wù)邏輯火俄，不受干擾地投入開發(fā)，開發(fā)速度可以很快讲冠，一般普通規(guī)模的App瓜客，一到兩周就能完成。
• 穩(wěn)：穩(wěn)不像快竿开，可以簡單地用時間進(jìn)行即時的量化評價谱仪，我們要等大量bug出現(xiàn)之后，才知道穩(wěn)不穩(wěn)否彩，可是一般趕工速度一快起來疯攒，就很容易出現(xiàn)大量bug。其實Android常見問題無非是內(nèi)存列荔、異步卸例、響應(yīng)等称杨，要排除和解決這些問題很容易，難的是怎樣確保不出現(xiàn)這些問題筷转。
• 清晰：清晰是最難做到的，快可以通過時間量化悬而，穩(wěn)可以通過bug統(tǒng)計量化呜舒，但是清晰是很難量化的，代碼審查和可擴展性都是主觀評價笨奠，而且相當(dāng)滯后袭蝗，很多情況下，往往要等到需要實現(xiàn)擴展般婆，甚至換人接手代碼時到腥，才知道代碼不清晰。

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

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

從職責(zé)分工上啤咽，業(yè)務(wù)設(shè)計是運營部門和產(chǎn)品經(jīng)理的工作晋辆，確實不應(yīng)由研發(fā)負(fù)責(zé)，但我說的是參與宇整，研發(fā)（包括測試）應(yīng)當(dāng)盡早參與業(yè)務(wù)設(shè)計瓶佳，一方面提前發(fā)現(xiàn)問題，另一方面可以引導(dǎo)和建議技術(shù)路線鳞青。
研發(fā)參與設(shè)計霸饲，可以規(guī)避很多問題，例如通信壓力臂拓、加載速度厚脉、延遲時間、硬件負(fù)載等移動開發(fā)特有問題埃儿，不能指望運營和產(chǎn)品能像專業(yè)的研發(fā)一樣面面俱到器仗，考慮周翔。
另一方面童番，研發(fā)參與設(shè)計還可以引導(dǎo)技術(shù)路線精钮，例如采用原生App、混合App還是ReactNative形式剃斧，采用單用戶體系還是多用戶體系，采用什么收費形式等幼东。
在實際操作中臂容，業(yè)務(wù)設(shè)計諸如收費形式科雳，異常提示，乃至于業(yè)務(wù)邏輯上的嚴(yán)密性脓杉，你都可能發(fā)現(xiàn)漏洞糟秘。

當(dāng)然，參與設(shè)計必然會占用研發(fā)時間球散，有人會覺得委屈尿赚，感覺這是替產(chǎn)品做了他們的工作，但其實研發(fā)參與設(shè)計蕉堰，省下的還是自己的時間凌净，因為無論產(chǎn)品如何設(shè)計，最終都需要技術(shù)來研發(fā)實現(xiàn)屋讶，如果設(shè)計上出了問題冰寻，你修改代碼的投入，可比產(chǎn)品改文檔的那點兒投入大多了皿渗。
當(dāng)然斩芭，公司層面也應(yīng)有清楚的定位，研發(fā)對設(shè)計的投入羹奉，必須是有限的指導(dǎo)性的秒旋，如果大量把研發(fā)投入到設(shè)計工作，就是另一種形式的浪費了诀拭。

異常處理

在實際開發(fā)過程中迁筛，除bug其實占了相當(dāng)一部分工作量，有時候好好的開發(fā)計劃耕挨，因為幾個詭異的bug就得耽誤半天细卧，所謂“碼字5分鐘，排錯兩小時”是也筒占。所以贪庙，能否盡早盡快處理異常，是非常影響開發(fā)效率的翰苫。
處理異常止邮，我有這么幾條心得：

• 提前考慮異常處理，在寫正常流程的業(yè)務(wù)代碼之前奏窑，先考慮異常导披，“未慮勝，先慮敗”埃唯，沿著業(yè)務(wù)流程分支撩匕，先把異常情況都處理掉，例如獲取在線數(shù)據(jù)顯示一個列表墨叛，先考慮網(wǎng)絡(luò)異常止毕、服務(wù)器報錯模蜡、數(shù)據(jù)失敗等異常情況，并依次給出相應(yīng)提示扁凛，最后才處理數(shù)據(jù)正常的情況忍疾，你本來就要寫正常業(yè)務(wù)代碼和異常處理代碼，你只需要調(diào)換一下工作的先后順序令漂，其實你投入的開發(fā)時間沒有增加膝昆，但是你的效率卻大大提升了，因為一旦出現(xiàn)異常叠必，我們可以迅速判斷異常原因，節(jié)省大量時間妹窖。
  這樣做還有一個好處纬朝，在你的思維陷入復(fù)雜的業(yè)務(wù)邏輯之前，先處理相對簡單的異常分支骄呼，可以避免你被業(yè)務(wù)邏輯搞到大腦缺氧后共苛，再回來處理異常分支時一時疏忽手滑，寫錯或者寫漏異常處理蜓萄。
• 隔離前后臺對接的數(shù)據(jù)接口隅茎，最好不要直接使用后臺提供的數(shù)據(jù)，中間加一層映射嫉沽，一方面辟犀，如果后臺數(shù)據(jù)出了問題（數(shù)據(jù)異常、變更字段等）绸硕，你在映射數(shù)據(jù)時就能發(fā)現(xiàn)和定位問題堂竟；另一方面，也有利于你采用更適合App的數(shù)據(jù)形式進(jìn)行數(shù)據(jù)持久化玻佩。
  另外出嘹，建議做一個接口錄入與檢查工具，形式不論咬崔，但要能輕松地維護(hù)前后臺接口税稼，最好能自動檢測接口反饋是否正常（服務(wù)器負(fù)載過大、字段變更垮斯、第三方服務(wù)過期等）郎仆。
• 異常信息的收集、匯總和數(shù)據(jù)持久化
  如果出現(xiàn)異常甚脉，最重要的是采集到異常代碼行(如MainActivity第61行)和異常原因(如空指針異常)丸升，并記錄為本地文件以備上傳和查看，具體見App的異常崩潰處理

其實java的異常處理的內(nèi)容還有很多牺氨，感興趣可以看一看我以前總結(jié)過的Java異常捕獲的設(shè)計原則

結(jié)構(gòu)分層

使用框架是必須的狡耻，Model層墩剖，View層必須職責(zé)單一，至于使用MVP夷狰、MVVM還是別的什么就看個人偏好和項目需要了岭皂。
個人比較偏好MVP，感興趣可以看一看MVP框架的演化沼头，當(dāng)然爷绘，Rx鏈?zhǔn)骄幊桃膊诲e。
個人在結(jié)構(gòu)分層上进倍，有這么幾個經(jīng)驗：

• 高內(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ù)層，通過多版本機制切換模擬數(shù)據(jù)和真實數(shù)據(jù)贴见。
• 松耦合的Activity烘苹，界面應(yīng)該是與業(yè)務(wù)相關(guān)最低的，主要提供一個顯示載體片部，并觸發(fā)生命周期處理镣衡，Activity應(yīng)該可以很容易地被替換掉。
• 獨立且方便測試的業(yè)務(wù)層吞琐，業(yè)務(wù)層應(yīng)該可以實現(xiàn)自動化測試捆探，這非常重要，即使你不去實施自動化測試站粟，把代碼寫成可以自動化測試的黍图，也能幫你優(yōu)化代碼，該抽象的抽象奴烙，該剝離的剝離助被。
• 必要時抽象特殊控件，如果控件需要復(fù)用切诀，就不要讓控件融合進(jìn)Activity揩环，而是抽象為獨立的顯示控件，這樣既能解耦合幅虑，又方便復(fù)用丰滑。

不要過度設(shè)計

敏捷開發(fā)里有一個實踐原則，就是不要過度設(shè)計倒庵，開發(fā)的價值不在于寫出漂亮的代碼褒墨，在于實現(xiàn)產(chǎn)品并支撐其正常運轉(zhuǎn)炫刷，在能實現(xiàn)產(chǎn)品功能的前提下，代碼邏輯其實是越簡單越好郁妈，簡單往往就意味著高可靠性+低維護(hù)成本浑玛，如果將來需要擴展功能，可以通過修改和重構(gòu)實現(xiàn)噩咪。
當(dāng)然顾彰，簡單并不意味著隨意，要把事件做復(fù)雜很容易胃碾，要做簡單卻很難涨享。能做到邏輯清晰、線程安全仆百、內(nèi)存安全灰伟，又容易修改和擴展的同時，還能保持代碼簡潔儒旬，其實反而更考驗功力的。
其實不僅在開發(fā)新功能時要避免過度設(shè)計帖族，在維護(hù)和擴展舊代碼時栈源，也要注意，能正常運行的代碼竖般，都是好代碼甚垦，我覺得在維護(hù)舊代碼時，其實也適用開放封閉原則涣雕，對不得不改艰亮，不改就崩的舊代碼，是開放的挣郭，可以修改的迄埃；對能正常運行的代碼，哪怕你覺得再難看再手癢兑障，那也是封閉的侄非，是不可以修改的。
回到那句話流译，開發(fā)的價值不在于寫出漂亮的代碼逞怨，在于實現(xiàn)產(chǎn)品并支撐其正常運轉(zhuǎn)。

通用庫的建立與維護(hù)

我們知道福澡，項目管理有四個要素叠赦，時間、成本革砸、范圍除秀、質(zhì)量糯累，這四個要素一般是不能兼得的，要時間鳞仙，就得砍一些范圍的項目目標(biāo)寇蚊，降成本，就容易犧牲質(zhì)量棍好，等等仗岸，不過，建立和維護(hù)通用庫借笙，卻能同時對四個要素都有好處扒怖。

• 加快開發(fā)速度，專注于具體業(yè)務(wù)（時間）
  降低團(tuán)隊成員熟悉項目的成本业稼，為新業(yè)務(wù)開發(fā)提供基礎(chǔ)盗痒，加快開發(fā)迭代速度，有利于更快地發(fā)布版本
• 提高代碼復(fù)用率低散，降低開發(fā)投入（成本）
  穩(wěn)定的公共模塊采用依賴組件庫方式俯邓，提供給各個業(yè)務(wù)線協(xié)作使用，減少重復(fù)開發(fā)和升級維護(hù)工作量
• 提升開發(fā)效率熔号，更容易實現(xiàn)項目目標(biāo)（范圍）
  對已實現(xiàn)過的功能/業(yè)務(wù)稽鞭，抽象出通用模塊，再有類似的需求引镊，能夠迅速實現(xiàn)朦蕴，更容易實現(xiàn)項目的業(yè)務(wù)需求
• 提升產(chǎn)品質(zhì)量，持續(xù)改進(jìn)通用功能（質(zhì)量）
  頻繁使用的功能/業(yè)務(wù)模塊采用組件復(fù)用方式弟头，更有利于暴露缺陷吩抓，一處修改，多處受益赴恨，提高產(chǎn)品質(zhì)量

工具與模板等

其實說起提高效率疹娶，前面的很多經(jīng)驗因為需要在實際開發(fā)中慢慢體會，難以迅速上手嘱支，反而是工具模板蚓胸，真正見效快，一次安裝除师，終生受益 :)
就我的經(jīng)驗而言沛膳，對我開發(fā)效率幫助最大的，包括代碼模板汛聚、常用配置和開發(fā)插件锹安，以及著名的程序員在線交友網(wǎng)站

代碼注釋

一般來說，程序員看自己一個月前寫的代碼，是完全陌生的叹哭，我也一樣忍宋，基本上過一個月就沒印象了，但是如果要修改/擴展怎么辦风罩，這時候糠排，就得看代碼注釋了。
就個人經(jīng)驗而言超升，有這么幾個地方入宦，一定要寫注釋：

• 接口，特別是MVP的Contract接口室琢，這里面基本定義了你的主要業(yè)務(wù)行為乾闰，誰來加載數(shù)據(jù)，誰來顯示數(shù)據(jù)盈滴，誰觸發(fā)的下一步操作涯肩，這些內(nèi)容寫明白了，以后讀代碼巢钓，只要看接口就知道主要業(yè)務(wù)是怎么回事兒了病苗。
• 服務(wù)、廣播等症汹，服務(wù)和廣播因為沒有界面铅乡，容易游離在業(yè)務(wù)邏輯鏈條之外，在業(yè)務(wù)邏輯上缺少上下文烈菌，就必須有詳盡的注釋，說明其業(yè)務(wù)場景花履。
• 初始化芽世、注入等，如果自定義了一些擴展的功能或控件诡壁，要求執(zhí)行某些初始化函數(shù)济瓢，或者要注入特定功能的，就必須寫好注釋妹卿，提示調(diào)用者進(jìn)行必要的操作旺矾。
• TODO，工作總要排優(yōu)先級的夺克，有些工作暫時延后箕宙，自己記錄是沒用的，團(tuán)隊開發(fā)最終用的還是代碼铺纽，所以一定要寫TODO柬帕，提示開發(fā)者，這里是未完成的狀態(tài)，避免不必要的誤會和延誤陷寝。