前言
宜未雨而綢繆，毋臨渴而掘井
程序員大多是重技能而輕規范的，因為要出活快，要搶占市場，要快速迭代..
這些都沒錯，但從長遠來看，不去管質量真的讓我們的開發效率更高效了嗎？
場景
死海效應
文檔的編寫一直是老生常談的問題，可能有人會說這個功能很簡單，文檔沒寫完我都開發完了。
是的，文檔是一項耗時的事情，他是有成本的，但是互聯網行業的人員變更是很頻繁的，需求的變更也是很常見的，也許你接盤的需求已經有7，8個人經手過了，如果沒有詳細的文檔沉淀，就會出現上圖一樣的情況，雖然不知道這段代碼想干什么甚至不知道它怎么就運行起來了，但是常年踩坑的經驗告訴我，此段代碼非同小可，觸者非傷即死，說不定會出現驚喜的bug，還是留着吧...，然后隨着時間的推進，這種沒頭沒腦的代碼就形成了死海效應，后續的越來越多的需求覆蓋在這個功能上，這種祖傳代碼就更沒人肯修改了。
在前期，沒有文檔可能確實會快很多，但是，長期迭代的項目沒有文檔，你覺得還會對效率有提高嗎？
改造成本
開發的生性都向往自由，各種奇技淫巧層出不窮，你有18種居中對齊的方法，我有36種顏色漸變的手段，但在多人協作的工程中，如果沒有規范的約束，大家自由發揮，項目可能會像左圖一樣，雜亂無章，這種情況往往潛藏着兼容性bug，也許有人會說，需求這不是完成了嗎，沒有出現問題，為什么要聽這種束縛我創造力的規則？
因為多一種實現方式，就多一種出現bug的風險，如果遵循統一的標准規范，就可以收斂出錯的情況，也利於之后重構改造，健壯的代碼是經得起反復改造與重構的，如果聽到重構兩個字，腦子里閃過一團亂麻，可能你的項目真的需要代碼規范了。
代碼風格
網上經常會看見諸如“用tab好還是用空格好”，“用兩個空格好還是4個空格好”的問題，這種代碼風格的問題有正確解嗎？沒有，況且也沒意義。但是，在多人協作的場景下，如果代碼風格不統一，就會浪費大量的時間在爭論這種腦殘問題與拉取代碼解決格式沖突上。
其實，就像開車行駛一樣，你靠左開可以，靠右開也沒錯，但是，每個人都隨意開的話就很危險了，所以靠右行駛的規則才會誕生，目的是為了讓大家開發都安全一點。
所以規范不一定是宣布誰的觀點正確，而是為了降低多人協作時的無意義分歧，讓大家把時間更聚焦於解決問題上面。
質量體系的作用
收斂工程復雜度的影響
隨着需求的不斷增多，各個模塊的關系越來越復雜，往往牽一發而動全身，這時的研發效率是被復雜度所拖住的，因為工程的復雜度往往與需求的數量是指數關系。
質量體質的構建就是讓大家遵守相同的規則，而相同的場景在相同的規則下具有相同的解法，這樣，代碼復雜度不隨需求而上升，只受場景的影響，收斂工程復雜度，提升持續迭代項目的研發效率。
多人協作
在大型項目里，開發人員的能力往往良莠不濟，同一個功能，可能幾行代碼實現，也可能被實現的又臭又硬，而代碼規則就像是最佳實踐的抽象，如果發現自己的代碼不符合規范，說明是有代碼壞味道的，可以考慮優化或者重構了，讓團隊成員的代碼像一個人編寫一般，也是代碼規范的目的之一。
將bug扼殺在搖籃里
《重構》中說過，出現問題的代碼往往散發着相同的bad smell。我們將各組的最佳實踐與代碼壞味道沉淀到規范中，並加以級別，就是為了可以提前發現隱藏的bug，如果違反了紅線級別的規則，說明代碼已經出現預見性的危害或嚴重的性能影響，而違反建議性規范，可能對現階段沒影響，但是日后的重構或是修改可能會困難重重。
結論
質量體系是整個開發流程的保護者，從需求階段的文檔保證，到開發過程中的代碼規范與書寫風格，最后開發結束后的code review，都是為了保證代碼足夠的健壯，最大程度的減少bug，方便功能的擴展。
所以，前期質量上的投入或許拖慢了研發的進度，但是，體系的建設是為了后期更快地擴展功能，避免陷入bug的泥潭中，更大程度地提升研發效率。