App開發(fā)，怎樣又快又穩(wěn)又清晰

Android開發(fā)，能理清業(yè)務邏輯，不受外界干擾地投入開發(fā)，開發(fā)速度會很迅速，很快，普通規(guī)模的App，一到兩周即可完成。

穩(wěn)：Android常見問題有內(nèi)存、異步、響應等，排除和解決很容易，難的是怎樣確保不出現(xiàn)這些問題？可以簡單地用時間量化評價，要等大量bug出現(xiàn)之后，才知道穩(wěn)不穩(wěn)，但一般工作中會有個弊端，為了趕工速度一快起來，就很容易出現(xiàn)大量bug。

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

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

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

處理異常，軟多信息有這么幾條心得：

提前考慮異常處理，在寫正常流程的業(yè)務代碼之前，先考慮異常，“未慮勝，先慮敗”，沿著業(yè)務流程分支，先把異常情況都處理掉，例如獲取在線數(shù)據(jù)顯示一個列表，先考慮網(wǎng)絡異常、服務器報錯、數(shù)據(jù)失敗等異常情況，并依次給出相應提示，最后才處理數(shù)據(jù)正常的情況，你本來就要寫正常業(yè)務代碼和異常處理代碼，你只需要調(diào)換一下工作的先后順序，其實你投入的開發(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行)和異常原因(如空指針異常)，并記錄為本地文件以備上傳和查看

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

敏捷開發(fā)里有一個實踐原則，就是不要過度設計，開發(fā)的價值不在于寫出漂亮的代碼，在于實現(xiàn)產(chǎn)品并支撐其正常運轉(zhuǎn)，在能實現(xiàn)產(chǎn)品功能的前提下，代碼邏輯其實是越簡單越好，簡單往往就意味著高可靠性+低維護成本，如果將來需要擴展功能，可以通過修改和重構(gòu)實現(xiàn)。
當然，簡單并不意味著隨意，要把事件做復雜很容易，要做簡單卻很難。能做到邏輯清晰、線程安全、內(nèi)存安全，又容易修改和擴展的同時，還能保持代碼簡潔，其實反而更考驗功力的。

其實不僅在開發(fā)新功能時要避免過度設計，在維護和擴展舊代碼時，也要注意，能正常運行的代碼，都是好代碼，我覺得在維護舊代碼時，其實也適用開放封閉原則，對不得不改，不改就崩的舊代碼，是開放的，可以修改的；對能正常運行的代碼，哪怕你覺得再難看再手癢，那也是封閉的，是不可以修改的。

回到那句話，開發(fā)的價值不在于寫出漂亮的代碼，在于實現(xiàn)產(chǎn)品并支撐其正常運轉(zhuǎn)。

軟件開發(fā)項目管理有四個要素：時間、成本、范圍、質(zhì)量。四個要素不能兼得的，要時間，就得砍一些范圍的項目目標，降成本，就容易犧牲質(zhì)量等等，不過，建立和維護通用庫，卻能同時對四個要素都有好處：

1、加快開發(fā)速度，專注于具體業(yè)務（時間）

2、降低團隊成員熟悉項目的成本，為新業(yè)務開發(fā)提供基礎，加快開發(fā)迭* 代速度，有利于更快地發(fā)布版本

提高代碼復用率，降低開發(fā)投入（成本）

3、穩(wěn)定的公共模塊采用依賴組件庫方式，提供給各個業(yè)務線協(xié)作使用，* 減少重復開發(fā)和升級維護工作量

提升開發(fā)效率，更容易實現(xiàn)項目目標（范圍）

4、對已實現(xiàn)過的功能/業(yè)務，抽象出通用模塊，再有類似的需求，能夠 迅速實現(xiàn)，更容易實現(xiàn)項目的業(yè)務需求

提升產(chǎn)品質(zhì)量，持續(xù)改進通用功能（質(zhì)量）

頻繁使用的功能/業(yè)務模塊采用組件復用方式，更有利于暴露缺陷， 一處修改，多處受益，提高產(chǎn)品質(zhì)量

其實說起提高效率，前面的很多經(jīng)驗因為需要在實際開發(fā)中慢慢體會，難以迅速上手，反而是工具模板，真正見效快，一次安裝，終生受益 :)

就我的經(jīng)驗而言，對我開發(fā)效率幫助很大，包括代碼模板、常用配置和開發(fā)插件，以及著名的程序員在線交友網(wǎng)站Github。

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

服務、廣播等，服務和廣播因為沒有界面，容易游離在業(yè)務邏輯鏈條之外，在業(yè)務邏輯上缺少上下文，就必須有詳盡的注釋，說明其業(yè)務場景。

初始化、注入等，如果自定義了一些擴展的功能或控件，要求執(zhí)行某些初始化函數(shù)，或者要注入特定功能的，就必須寫好注釋，提示調(diào)用者進行必要的操作。

工作總要排優(yōu)先級的，有些工作暫時延后，自己記錄是沒用的，團隊開發(fā)用的還是代碼，所以一定要寫TODO，提示開發(fā)者，這里是未完成的狀態(tài)，避免不必要的誤會和延誤。

以上就是軟多信息針對每一個軟件開發(fā)項目時，總結(jié)下來的一些經(jīng)驗，由于篇幅問題有所刪減，如有沒有言說的地方，請諒解！