歡迎光臨
每天分享高質量文章

App開發,怎樣又快又穩又清晰

作者:藍灰_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、資料庫、運維等。

赞(0)

分享創造快樂