其實(shí)過(guò)去幾年中，我也是這么想的，但最近我開始意識(shí)到，這個(gè)問(wèn)題的糾結(jié)之處不在于選擇困難，而在于問(wèn)題本身是個(gè)偽命題。

　　什么是“質(zhì)量”呢？一般程序員說(shuō)到“質(zhì)量”二字時(shí)，他們說(shuō)的有可能是測(cè)試通過(guò)率、變量命名、代碼格式化、組件化、查找bug
、程序測(cè)試等等。也有可能是程序的可拓展性、服務(wù)延時(shí)、產(chǎn)品功能的完整程度。

　　問(wèn)題往往就產(chǎn)生于以上兩者被統(tǒng)一看待、不做區(qū)分的時(shí)候。其實(shí)前一種圍繞代碼的問(wèn)題可以看成“代碼質(zhì)量”問(wèn)題，第二種情況則
可以看成“執(zhí)行質(zhì)量”，或者“執(zhí)行程度”。

　　從“代碼質(zhì)量”上來(lái)看，程序猿走捷徑的偷懶思維，其實(shí)是種十分短視的做法。含糊繞過(guò)某個(gè)問(wèn)題，你可能會(huì)一時(shí)覺得省事不少，
但到頭來(lái)，往往發(fā)現(xiàn)因此攪亂了 系統(tǒng)而要花費(fèi)更多的時(shí)間來(lái)一行行檢查代碼，找出bug，甚至重新調(diào)整整體邏輯框架。所以犧牲代碼質(zhì)
量換取速度通常是得不償失的做法。

　　相反地，高質(zhì)量的代碼其實(shí)是可以幫助你節(jié)省時(shí)間的。統(tǒng)一的代碼規(guī)范和變量命名，不僅可以幫到別的程序猿，還可以幫到未來(lái)的你
，更好地理解你現(xiàn)在寫下的代 碼;經(jīng)過(guò)嚴(yán)密思考而設(shè)計(jì)出的輕量級(jí)代碼架構(gòu)，則可以讓你在迭代產(chǎn)品的時(shí)候獲得更高的效率，更清晰地了
解該從何處入手，而不是到數(shù)據(jù)庫(kù)里漫天尋找需要替代的 地方;
而高測(cè)試通過(guò)率還可以給你充足的自信去調(diào)整產(chǎn)品，減少bug數(shù)量，最小化QA時(shí)間。

　　至于“執(zhí)行質(zhì)量”，這又是另一個(gè)命題。有很多方式可以在不降低產(chǎn)品質(zhì)量的情況下，使得產(chǎn)品開發(fā)過(guò)程很緊湊。
比如你可以先推遲一些不那么著急的工作，等到整體執(zhí)行優(yōu)化、系統(tǒng)穩(wěn)健性做好的時(shí)候，再來(lái)做那些被暫時(shí)擱置的事情。

　　具體的做法就是，先把最終想要的產(chǎn)品效果定好，然后往其中填充內(nèi)容不斷修改，至于一些無(wú)關(guān)的細(xì)節(jié)可以最后再來(lái)優(yōu)化。
舉例來(lái)說(shuō)，剛開始開發(fā)產(chǎn)品時(shí)，可以用 RPC來(lái)簡(jiǎn)化應(yīng)用開發(fā)的流程，繞過(guò)復(fù)雜的協(xié)議傳輸問(wèn)題，先在產(chǎn)品應(yīng)用層面上快速迭代，隨后再替換
掉RPC，加入重試、錯(cuò)誤控制、安全檢驗(yàn)等代碼，或者干脆 替換掉傳輸協(xié)議。

　　寫Medium代碼的時(shí)候，我們就是先實(shí)現(xiàn)效果，再調(diào)整細(xì)化部分的，最后刪掉了很多無(wú)法整合進(jìn)原先設(shè)定好的框架中的功能，大約是六萬(wàn)行
代碼左右。

　　所以如果我們起初沒(méi)有小心處理代碼質(zhì)量的問(wèn)題，最終一定會(huì)被查找各種很細(xì)微的問(wèn)題困擾。如果我們沒(méi)有完全聚焦在效果實(shí)現(xiàn)上，就一
定會(huì)拖拖拉拉延后項(xiàng)目進(jìn)度。但如你所見，很幸運(yùn)我們前期工作做得充分，所以現(xiàn)在產(chǎn)品可以迭代得很快，并不斷試驗(yàn)新功能。