知識星球作者：藍灰_q
連結：https://www.jianshu.com/p/8de61045047d
開發者的價值，是透過技術和產品體現的，對於App開發來說，除了實現業務之外，最重要的莫過於開發的速度、質量和可維護性，速度決定你能否支撐公司搶佔市場，質量決定你們能不能站穩位置不被迅速踢走，可維護性決定你們繼續前行時能否保持輕快的步伐。
速度、質量和可維護性
對速度、質量和可維護性的要求，其實就是又快，又穩，又清晰的要求。
-
快：快其實是最容易做到，或者說最容易知道能不能做到的事情，熟悉的Android開發的朋友都知道，如果能理清業務邏輯，不受幹擾地投入開發，開發速度可以很快，一般普通規模的App，一到兩周就能完成。
-
穩：穩不像快，可以簡單地用時間進行即時的量化評價，我們要等大量bug出現之後，才知道穩不穩，可是一般趕工速度一快起來，就很容易出現大量bug。其實Android常見問題無非是記憶體、非同步、響應等，要排除和解決這些問題很容易，難的是怎樣確保不出現這些問題。
-
清晰：清晰是最難做到的，快可以透過時間量化，穩可以透過bug統計量化，但是清晰是很難量化的，程式碼審查和可擴充套件性都是主觀評價，而且相當滯後，很多情況下，往往要等到需要實現擴充套件，甚至換人接手程式碼時，才知道程式碼不清晰。
對於開發者來說，怎樣才能又快又穩又清晰地開發App，這裡梳理了我的幾點心得。
有限參與業務設計
從職責分工上，業務設計是運營部門和產品經理的工作，確實不應由研發負責，但我說的是參與，研發（包括測試）應當儘早參與業務設計，一方面提前發現問題，另一方面可以引導和建議技術路線。
研發參與設計，可以規避很多問題，例如通訊壓力、載入速度、延遲時間、硬體負載等移動開發特有問題，不能指望運營和產品能像專業的研發一樣面面俱到，考慮周翔。
另一方面，研發參與設計還可以引導技術路線，例如採用原生App、混合App還是ReactNative形式，採用單使用者體系還是多使用者體系，採用什麼收費形式等。
在實際操作中，業務設計諸如收費形式，異常提示，乃至於業務邏輯上的嚴密性，你都可能發現漏洞。
當然，參與設計必然會佔用研發時間，有人會覺得委屈，感覺這是替產品做了他們的工作，但其實研發參與設計，省下的還是自己的時間，因為無論產品如何設計，最終都需要技術來研發實現，如果設計上出了問題，你修改程式碼的投入，可比產品改檔案的那點兒投入大多了。
當然，公司層面也應有清楚的定位，研發對設計的投入，必須是有限的指導性的，如果大量把研發投入到設計工作，就是另一種形式的浪費了。
異常處理
在實際開發過程中，除bug其實佔了相當一部分工作量，有時候好好的開發計劃，因為幾個詭異的bug就得耽誤半天，所謂“碼字5分鐘，排錯兩小時”是也。所以，能否儘早儘快處理異常，是非常影響開發效率的。
處理異常，我有這麼幾條心得：
-
提前考慮異常處理，在寫正常流程的業務程式碼之前，先考慮異常，“未慮勝，先慮敗”，沿著業務流程分支，先把異常情況都處理掉，例如獲取線上資料顯示一個串列，先考慮網路異常、伺服器報錯、資料失敗等異常情況，並依次給出相應提示，最後才處理資料正常的情況，你本來就要寫正常業務程式碼和異常處理程式碼，你只需要調換一下工作的先後順序，其實你投入的開發時間沒有增加，但是你的效率卻大大提升了，因為一旦出現異常，我們可以迅速判斷異常原因，節省大量時間。
這樣做還有一個好處，在你的思維陷入複雜的業務邏輯之前，先處理相對簡單的異常分支，可以避免你被業務邏輯搞到大腦缺氧後，再回來處理異常分支時一時疏忽手滑，寫錯或者寫漏異常處理。 -
隔離前後臺對接的資料介面，最好不要直接使用後臺提供的資料，中間加一層對映，一方面，如果後臺資料出了問題（資料異常、變更欄位等），你在對映資料時就能發現和定位問題；另一方面，也有利於你採用更適合App的資料形式進行資料持久化。
另外，建議做一個介面錄入與檢查工具，形式不論，但要能輕鬆地維護前後臺介面，最好能自動檢測介面反饋是否正常（伺服器負載過大、欄位變更、第三方服務過期等）。 -
異常資訊的收集、彙總和資料持久化
如果出現異常，最重要的是採集到異常程式碼行(如MainActivity第61行)和異常原因(如空指標異常)，並記錄為本地檔案以備上傳和檢視，具體見App的異常崩潰處理：https://www.jianshu.com/p/367b4d851ed4
其實java的異常處理的內容還有很多，感興趣可以看一看我以前總結過的Java異常捕獲的設計原則：https://www.jianshu.com/p/1e0199e3c34e
結構分層
使用框架是必須的，Model層，View層必須職責單一，至於使用MVP、MVVM還是別的什麼就看個人偏好和專案需要了。
個人比較偏好MVP，感興趣可以看一看MVP框架的演化：https://www.jianshu.com/p/5d8481313f00，當然，Rx鏈式程式設計也不錯。
個人在結構分層上，有這麼幾個經驗：
-
高內聚的資料層，把與資料讀寫相關的處理，網路讀寫、本地讀寫、快取資料等，包括模擬資料，都集中到資料層，透過回呼或鏈式呼叫等方式丟擲資料給業務層，透過多版本機制切換模擬資料和真實資料。
-
松耦合的Activity，介面應該是與業務相關最低的，主要提供一個顯示載體，並觸發生命週期處理，Activity應該可以很容易地被替換掉。
-
獨立且方便測試的業務層，業務層應該可以實現自動化測試，這非常重要，即使你不去實施自動化測試，把程式碼寫成可以自動化測試的，也能幫你最佳化程式碼，該抽象的抽象，該剝離的剝離。
-
必要時抽象特殊控制元件，如果控制元件需要復用，就不要讓控制元件融合進Activity，而是抽象為獨立的顯示控制元件，這樣既能解耦合，又方便復用。
要過度設計不
敏捷開發裡有一個實踐原則，就是不要過度設計，開發的價值不在於寫出漂亮的程式碼，在於實現產品並支撐其正常運轉，在能實現產品功能的前提下，程式碼邏輯其實是越簡單越好，簡單往往就意味著高可靠性+低維護成本，如果將來需要擴充套件功能，可以透過修改和重構實現。
當然，簡單並不意味著隨意，要把事件做複雜很容易，要做簡單卻很難。能做到邏輯清晰、執行緒安全、記憶體安全，又容易修改和擴充套件的同時，還能保持程式碼簡潔，其實反而更考驗功力的。
其實不僅在開發新功能時要避免過度設計，在維護和擴充套件舊程式碼時，也要註意，能正常執行的程式碼，都是好程式碼，我覺得在維護舊程式碼時，其實也適用開放封閉原則，對不得不改，不改就崩的舊程式碼，是開放的，可以修改的；對能正常執行的程式碼，哪怕你覺得再難看再手癢，那也是封閉的，是不可以修改的。
回到那句話，開發的價值不在於寫出漂亮的程式碼，在於實現產品並支撐其正常運轉。
通用庫的建立與維護
我們知道，專案管理有四個要素，時間、成本、範圍、質量，這四個要素一般是不能兼得的，要時間，就得砍一些範圍的專案標的，降成本，就容易犧牲質量，等等，不過，建立和維護通用庫，卻能同時對四個要素都有好處。
-
加快開發速度，專註於具體業務（時間）
降低團隊成員熟悉專案的成本，為新業務開發提供基礎，加快開發迭代速度，利於更快地釋出版本 -
提高程式碼復用率，降低開發投入（成本）
穩定的公共模組採用依賴元件庫方式，提供給各個業務線協作使用，減少重覆開發和升級維護工作量 -
提升開發效率，更容易實現專案標的（範圍）
對已實現過的功能/業務，抽象出通用模組，再有類似的需求，能夠迅速實現，更容易實現專案的業務需求 -
提升產品質量，持續改進通用功能（質量）
頻繁使用的功能/業務模組採用元件復用方式，更有利於暴露缺陷，一處修改，多處受益，提高產品質量
工具與模板等
其實說起提高效率，前面的很多經驗因為需要在實際開發中慢慢體會，難以迅速上手，反而是工具模板，真正見效快，一次安裝，終生受益 🙂
就我的經驗而言，對我開發效率幫助最大的，包括程式碼模板、常用配置和開發外掛，以及著名的程式員線上交友網站Github。
程式碼註釋
一般來說，程式員看自己一個月前寫的程式碼，是完全陌生的，我也一樣，基本上過一個月就沒印象了，但是如果要修改/擴充套件怎麼辦，這時候，就得看程式碼註釋了。
就個人經驗而言，有這麼幾個地方，一定要寫註釋：
-
介面，特別是MVP的Contract介面，這裡面基本定義了你的主要業務行為，誰來載入資料，誰來顯示資料，誰觸發的下一步操作，這些內容寫明白了，以後讀程式碼，只要看介面就知道主要業務是怎麼回事兒了。
-
服務、廣播等，服務和廣播因為沒有介面，容易遊離在業務邏輯鏈條之外，在業務邏輯上缺少背景關係，就必須有詳盡的註釋，說明其業務場景。
-
初始化、註入等，如果自定義了一些擴充套件的功能或控制元件，要求執行某些初始化函式，或者要註入特定功能的，就必須寫好註釋，提示呼叫者進行必要的操作。
-
TODO，工作總要排優先順序的，有些工作暫時延後，自己記錄是沒用的，團隊開發最終用的還是程式碼，所以一定要寫TODO，提示開發者，這裡是未完成的狀態，避免不必要的誤會和延誤。
●編號349，輸入編號直達本文
●輸入m獲取到文章目錄
Java程式設計
更多推薦《18個技術類公眾微信》
涵蓋：程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。
