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

    前言

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

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

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

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

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

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

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

    有限參與業(yè)務(wù)設(shè)計(jì)

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

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

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

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

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

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

    異常處理

    在實(shí)際開發(fā)過程中，除bug其實(shí)占了相當(dāng)一部分工作量，有時(shí)候好好的開發(fā)計(jì)劃，因?yàn)閹讉€(gè)詭異的bug就得耽誤半天，所謂“碼字5分鐘，排錯(cuò)兩小時(shí)”是也。所以，能否盡早盡快處理異常，是非常影響開發(fā)效率的。