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

[[119579]]

關(guān)于這個(gè)話題，幾年來一直反反復(fù)復(fù)糾結(jié)在我的腦海里，我開始漸漸發(fā)現(xiàn)這個(gè)論題本身就是一個(gè)既危險(xiǎn)又錯(cuò)誤的悖論。也許重新規(guī)劃這個(gè)論題能幫助我們達(dá)到一個(gè)共贏的局面：做出更好的產(chǎn)品、成就更優(yōu)秀更有沖刺力的團(tuán)隊(duì)。

當(dāng)我們談及產(chǎn)品質(zhì)量的時(shí)候，往往包含測(cè)試覆蓋率、變量命名法、代碼格式化、組件化、界面設(shè)計(jì)、bug情況、邏輯錯(cuò)誤等眾多指標(biāo)。甚至有的時(shí)候，擴(kuò)展能力、優(yōu)化算法復(fù)雜度、服務(wù)延時(shí)、類庫推廣以及產(chǎn)品功能完整性方面也在考慮之中。

為了使討論更明確，區(qū)分不同的類別，我更喜歡將***類的產(chǎn)品質(zhì)量稱為“代碼質(zhì)量”，而稱第二類為“執(zhí)行質(zhì)量”或“深度”：執(zhí)行的深度、完成的深度。

偷工減料的代碼質(zhì)量可能短期內(nèi)會(huì)有立竿見影的成效與收益，但是這只是水中月鏡中花，在不久的將來需要我們連本帶利地償還：花大量的時(shí)間重構(gòu)、花大量的時(shí)間修復(fù)bug、花大量的時(shí)間搞清楚究竟該如何才能使程序運(yùn)作起來。因此，為了開發(fā)速度而犧牲代碼質(zhì)量其實(shí)就是作繭自縛，時(shí)間一到它就會(huì)像“高利貸“一樣，利滾利地讓你付出更高的、甚至是高不可攀的代價(jià)：不得不推遲其他的工作、苦不堪言、悔不當(dāng)初。

良好的代碼質(zhì)量其實(shí)能讓我們的進(jìn)程跑得更快。保持一致的風(fēng)格和帶點(diǎn)提示的命名法能幫助其他人——還有將來的你——理解代碼；干凈又周密的接口能讓我們即使卸下或者更換整個(gè)組件，也不需要重新檢查代碼庫的角角落落；良好的測(cè)試覆蓋率能讓我們?cè)谧龈膭?dòng)時(shí)更有信心、能減少bug的數(shù)量、能使得QA時(shí)間最少化。

隨著時(shí)代的發(fā)展，現(xiàn)在的實(shí)施深度已經(jīng)演變成另外一個(gè)問題。如今有很多方法可以在不降低產(chǎn)品整體質(zhì)量的同時(shí)簡(jiǎn)化開發(fā)。

項(xiàng)目實(shí)施本身并不需要是非常***的，一開始我們只要保證功能具備即可。而在之后的某個(gè)階段，我們可以再慢慢改善或者完全用新的內(nèi)容取而代之。

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

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

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

事實(shí)上，現(xiàn)如今我們不但有能力給一些多余內(nèi)容減肥，迅速給產(chǎn)品瘦身，還能在大多數(shù)情況下依舊保持其成為迭代和實(shí)驗(yàn)的良好基礎(chǔ)。

所以，要是下次有人再問你，“如果不關(guān)注代碼的質(zhì)量，能不能工作得更快？”的時(shí)候，理直氣壯氣地告訴他，“你問了一個(gè)愚蠢的問題！”

譯文鏈接：http://news.html5tricks.com/velocity-vs-quality.html

英文原文：Velocity vs. Quality