對速度、質(zhì)量和可維護性的要求，其實就是又快，又穩(wěn)，又清晰的要求。

    前言

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

    速度、質(zhì)量和可維護性

對速度、質(zhì)量和可維護性的要求，其實就是又快，又穩(wěn)，又清晰的要求。

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

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

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

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

    有限參與業(yè)務設計

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

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

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

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

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

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

    異常處理

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