程序開發(fā)項目進行過程中，通常會冒出這樣的困惑：應該選擇效率，還是選擇質(zhì)量？很多程序猿都會有偷懶的思維，覺得把一些摸不清頭緒、不知道怎么寫的代碼片段去掉，可以節(jié)省很多時間，更早完成項目計劃。

其實過去幾年中，我也是這么想的，但最近我開始意識到，這個問題的糾結之處不在于選擇困難，而在于問題本身是個偽命題。

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

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

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

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

程序員選擇效率，還是選擇質(zhì)量呢？