關於這個話題，幾年來一直反反覆覆糾結在我的腦海裡，我開始漸漸發現這個論題本身就是一個既危險又錯誤的悖論。也許重新規劃這個論題能幫助我們達到一個共贏的局面：做出更好的產品、成就更優秀更有衝刺力的團隊。
當我們談及產品質量的時候，往往包含測試覆蓋率、變數命名法、程式碼格式化、元件化、介面設計、bug情況、邏輯錯誤等眾多指標。甚至有的時候，擴充套件能力、優化演算法複雜度、服務延時、類庫推廣以及產品功能完整性方面也在考慮之中。
為了使討論更明確，區分不同的類別，我更喜歡將第一類的產品質量稱為“程式碼質量”，而稱第二類為“執行質量”或“深度”：執行的深度、完成的深度。
偷工減料的程式碼質量可能短期內會有立竿見影的成效與收益，但是這只是水中月鏡中花，在不久的將來需要我們連本帶利地償還：花大量的時間重構、花大量的時間修復bug、花大量的時間搞清楚究竟該如何才能使程式運作起來。因此，為了開發速度而犧牲程式碼質量其實就是作繭自縛，時間一到它就會像“高利貸“一樣，利滾利地讓你付出更高的、甚至是高不可攀的代價：不得不推遲其他的工作、苦不堪言、悔不當初。
良好的程式碼質量其實能讓我們的程式跑得更快。保持一致的風格和帶點提示的命名法能幫助其他人——還有將來的你——理解程式碼；乾淨又周密的介面能讓我們即使卸下或者更換整個元件，也不需要重新檢查程式碼庫的角角落落；良好的測試覆蓋率能讓我們在做改動時更有信心、能減少bug的數量、能使得QA時間最少化。
隨著時代的發展，現在的實施深度已經演變成另外一個問題。如今有很多方法可以在不降低產品整體質量的同時簡化開發。
專案實施本身並不需要是非常完美的，一開始我們只要保證功能具備即可。而在之後的某個階段，我們可以再慢慢改善或者完全用新的內容取而代之。
例如，在一個新的app裡，其RPC層起初可能只是簡單地做了一個HTTP類庫。這樣我們就可以把省下來的時間用到迭代應用層，以及那些還不夠精緻需要再接再厲的內容上。然後在未來的某個時間點——也有可能是當我們正準備釋出的那一瞬間——突然覺得這些個RPC層需要更為迷人；或者是應該新增重試邏輯、異常處理、安全功能甚至是改變傳輸協議，沒錯，即便是在這樣的情況下去完善RPC層也完全ok。
在建設專案時，我們常常會歷盡千辛萬苦、嘔心瀝血、廢寢忘食，不斷地經歷開發、重新開發、刪除功能這個迴圈，最終導致大約6萬行程式碼胎死腹中，不出現在預覽版上。
如果我們忽視程式碼質量，後期要想維護和擴充套件就會困難重重，並且產生大量的冗餘程式碼。如果我們不能針對性地進行優化，事半功倍做出來的成果最終也跳脫不了記載於Git日誌裡而被靜靜遺忘在角落裡的命運。
事實上，現如今我們不但有能力給一些多餘內容減肥，迅速給產品瘦身，還能在大多數情況下依舊保持其成為迭代和實驗的良好基礎。
所以，要是下次有人再問你，“如果不關注程式碼的質量，能不能工作得更快？”的時候，理直氣壯氣地告訴他，“你問了一個愚蠢的問題！”
譯文連結：http://news.html5tricks.com/velocity-vs-quality.html
英文原文：Velocity vs. Quality
相關閱讀
評論(2)