不得不承認(rèn)，現(xiàn)在幾乎每個(gè)軟件開(kāi)發(fā)項(xiàng)目都會(huì)不可避免地都會(huì)出現(xiàn)一個(gè)問(wèn)題，那就是關(guān)于開(kāi)發(fā)速度與代碼質(zhì)量該如何抉擇。忽略一些細(xì)枝末節(jié)、偷工減料毫無(wú)疑問(wèn)能讓我們的項(xiàng)目進(jìn)展地更快，所需時(shí)間更短。

3

例如，在一個(gè)新的app里，其RPC層起初可能只是簡(jiǎn)單地做了一個(gè)HTTP類(lèi)庫(kù)。這樣我們就可以把省下來(lái)的時(shí)間用到迭代應(yīng)用層，以及那些還不夠精致需要再接再厲的內(nèi)容上。然后在未來(lái)的某個(gè)時(shí)間點(diǎn)——也有可能是當(dāng)我們正準(zhǔn)備發(fā)布的那一瞬間——突然覺(jué)得這些個(gè)RPC層需要更為迷人；或者是應(yīng)該添加重試邏輯、異常處理、安全功能甚至是改變傳輸協(xié)議，沒(méi)錯(cuò)，即便是在這樣的情況下去完善RPC層也完全ok。

在建設(shè)項(xiàng)目時(shí)，我們常常會(huì)歷盡千辛萬(wàn)苦、嘔心瀝血、廢寢忘食，不斷地經(jīng)歷開(kāi)發(fā)、重新開(kāi)發(fā)、刪除功能這個(gè)循環(huán)，最終導(dǎo)致大約6萬(wàn)行代碼胎死腹中，不出現(xiàn)在預(yù)覽版上。

如果我們忽視代碼質(zhì)量，后期要想維護(hù)和擴(kuò)展就會(huì)困難重重，并且產(chǎn)生大量的冗余代碼。如果我們不能針對(duì)性地進(jìn)行優(yōu)化，事半功倍做出來(lái)的成果最終也跳脫不了記載于Git日志里而被靜靜遺忘在角落里的命運(yùn)。

那么開(kāi)發(fā)速度和代碼質(zhì)量，你的選擇是什么？