app開發，這(zhè)樣做(zuò)既快(kuài)由又穩還(hái)清晰！

　　開發者的(de)價值，是通(tōng)過技術和(hé)産品體現的(de)，對(duì)于App開發來(lái)說，除了(le)實現業務之外，最重要的(de)莫過于開發的(de)速度、質量和(hé)可(kě)維護性，速度決定你能否支撐公司搶占市場(chǎng)，質量決定你們能不能站穩位置不被迅速踢走，可(kě)維護性決定你們繼續前行時(shí)能否保持輕快(kuài)的(de)步伐。

　　速度、質量和(hé)可(kě)維護性

　　對(duì)速度、質量和(hé)可(kě)維護性的(de)要求，其實就是又快(kuài)，又穩，又清晰的(de)要求。

　　快(kuài)：快(kuài)其實是最容易做(zuò)到，或者說最容易知道能不能做(zuò)到的(de)事情，熟悉的(de)Android開發的(de)朋友都知道，如果能理(lǐ)清業務邏輯，不受幹擾地投入開發，開發速度可(kě)以很快(kuài)，一般普通(tōng)規模的(de)App，一到兩周就能完成。

　　穩：穩不像快(kuài)，可(kě)以簡單地用(yòng)時(shí)間進行即時(shí)的(de)量化(huà)評價，我們要等大(dà)量bug出現之後，才知道穩不穩，可(kě)是一般趕工速度一快(kuài)起來(lái)，就很容易出現大(dà)量bug。其實Android常見問題無非是内存、異步、響應等，要排除和(hé)解決這(zhè)些問題很容易，難的(de)是怎樣确保不出現這(zhè)些問題。

　　清晰：清晰是最難做(zuò)到的(de)，快(kuài)可(kě)以通(tōng)過時(shí)間量化(huà)，穩可(kě)以通(tōng)過bug統計量化(huà)，但是清晰是很難量化(huà)的(de)，代碼審查和(hé)可(kě)擴展性都是主觀評價，而且相當滞後，很多(duō)情況下(xià)，往往要等到需要實現擴展，甚至換人(rén)接手代碼時(shí)，才知道代碼不清晰。

　　對(duì)于開發者來(lái)說，怎樣才能又快(kuài)又穩又清晰地開發App，這(zhè)裏梳理(lǐ)了(le)我的(de)幾點心得(de)。

　　有限參與業務設計

　　從職責分(fēn)工上，業務設計是運營部門和(hé)産品經理(lǐ)的(de)工作，确實不應由研發負責，但我說的(de)是參與，研發(包括測試)應當盡早參與業務設計，一方面提前發現問題，另一方面可(kě)以引導和(hé)建議(yì)技術路線。

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

　　另一方面，研發參與設計還(hái)可(kě)以引導技術路線，例如采用(yòng)原生App、混合App還(hái)是ReactNative形式，采用(yòng)單用(yòng)戶體系還(hái)是多(duō)用(yòng)戶體系，采用(yòng)什(shén)麽收費形式等。

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

　　當然，參與設計必然會占用(yòng)研發時(shí)間，有人(rén)會覺得(de)委屈，感覺這(zhè)是替産品做(zuò)了(le)他(tā)們的(de)工作，但其實研發參與設計，省下(xià)的(de)還(hái)是自己的(de)時(shí)間，因爲無論産品如何設計，最終都需要技術來(lái)研發實現，如果設計上出了(le)問題，你修改代碼的(de)投入，可(kě)比産品改文檔的(de)那點兒(ér)投入大(dà)多(duō)了(le)。

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