對速度、質量、可維護性的要求，其實就是快速??、穩定、清晰的要求。

前言

開發者的價值體現在技術和產品上。對于App開發，除了實現業務，最重要的是開發的速度、質量和可維護性。速度決定了你能否支持企業搶占市場。質量決定了你能否站穩腳跟不被快速踢出局，可維護性決定了你前進時能否保持輕快的步伐。

速度、質量和可維護性

對速度、質量、可維護性的要求，其實就是快速??、穩定、清晰的要求。

APP開發快：快其實是更容易做，或者更容易知道能不能做。熟悉Android開發的朋友都知道，如果能夠在不受干擾的情況下梳理業務邏輯并投入開發，開發速度會非?？?，一般規模的App一到兩周就可以完成。一個

穩定性：穩定性不如快。我們可以簡單地用時間來進行實時的量化評估。穩定與否，要等大量bug出現才知道。其實Android常見的問題無非就是內存、異步、響應等，排查和解決這些問題很容易，難的是如何保證這些問題不發生。

清晰度：清晰度很難達到。牢度可以用時間來量化，穩定性可以用bug統計來量化，但是清晰度卻很難量化。代碼審查和 scalability 是主觀評價，比較落后。很多時候，往往是等到需要實現擴展，甚至是別人接手代碼的時候，代碼才變得清晰。

對于開發者來說，關于如何快速、穩定、清晰地開發應用程序，這里有一些我的想法。

有限參與商業設計

在職責分工上，業務設計是運營部門和產品經理的工作，研發確實不應該負責，但我說的是參與。研發（包括測試）應盡早參與業務設計。一方面可以提前發現問題，另一方面可以指導和建議技術路線。

研發參與設計可以避免很多問題，比如通信壓力、加載速度、延遲時間、硬件負載等移動開發特有的問題。你不能期望運營和產品像專業研發一樣全面。想想周翔。

另一方面，R&D參與設計也可以指導技術路線，比如是用native App，hybrid App還是ReactNative，用單用戶系統還是多用戶系統，用什么收費方式.

在實際操作中，你可能會發現收費形式、異常提示，甚至業務邏輯的嚴謹性等業務設計上的漏洞。

當然，參與設計難免會占用研發時間。有些人會覺得委屈，覺得這是在為產品做自己的工作。如果設計有問題，你修改代碼的投入要比修改產品文檔的投入多很多。

當然，在公司層面也要有明確的定位。設計方面的研發投入必須是有限的和引導性的。如果大量的研發投入到設計工作中，則是另一種形式的浪費。

異常處理

在實際的開發過程中，BUG清除實際上占據了相當一部分的工作量。有時候一個好的開發計劃會因為幾個奇怪的bug而耽擱半天。因此，能否盡早處理異常對開發效率有很大的影響。

免責聲明：本頁文章及圖片來源于網絡，轉載內容僅供傳遞更多信息和學習之用。轉載稿件如涉及版權等問題，請聯系管理員處理。