手機APP開發，怎樣又快又穩又清晰

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

    前言

    開發者的價值，是通過技術和產品體現的，對于App開發來說，除了實現業務之外，較重要的莫過于開發的速度、質量和可維護性，速度決定你能否支撐公司搶占市場，質量決定你們能不能站穩位置不被迅速踢走，可維護性決定你們繼續前行時能否保持輕快的步伐。

    速度、質量和可維護性

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

    快：快其實是較容易做到，或者說較容易知道能不能做到的事情，熟悉的Android開發的朋友都知道，如果能理清業務邏輯，不受干擾地投入開發，開發速度可以很快，一般普通規模的App，一到兩周就能完成。

    穩：穩不像快，可以簡單地用時間進行即時的量化評價，我們要等大量bug出現之后，才知道穩不穩，可是一般趕工速度一快起來，就很容易出現大量bug。其實Android常見問題無非是內存、異步、響應等，要排除和解決這些問題很容易，難的是怎樣確保不出現這些問題。

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

    對于開發者來說，怎樣才能又快又穩又清晰地開發App，這里梳理了我的幾點心得。

    有限參與業務設計

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

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

    另一方面，研發參與設計還可以引導技術路線，例如采用原生App、混合App還是ReactNative形式，采用單用戶體系還是多用戶體系，采用什么收費形式等。

    在實際操作中，業務設計諸如收費形式，異常提示，乃至于業務邏輯上的嚴密性，你都可能發現漏洞。

    當然，參與設計必然會占用研發時間，有人會覺得委屈，感覺這是替產品做了他們的工作，但其實研發參與設計，省下的還是自己的時間，因為無論產品如何設計，較終都需要技術來研發實現，如果設計上出了問題，你修改代碼的投入，可比產品改文檔的那點兒投入大多了。

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

    異常處理

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