我們知道，項目越復雜、代碼量越多、參與開發(fā)人員越多、開發(fā)維護時間越長，我們就越是要重視代碼質(zhì)量。代碼質(zhì)量下降會導致項目研發(fā)困難重重，比如：開發(fā)效率低，招了很多人，天天加班，出活卻不多；線上 bug 頻發(fā)，查找 bug 困難，領(lǐng)導發(fā)飆，中層束手無策，工程師抱怨不斷。

導致代碼質(zhì)量不高的原因有很多，比如：代碼無注釋，無文檔，命名差，層次結(jié)構(gòu)不清晰，調(diào)用關(guān)系混亂，到處 hardcode，充斥著各種臨時解決方案等等。那怎么才能時刻保證代碼質(zhì)量呢？當然，首要的是團隊技術(shù)素質(zhì)要過硬，能夠適當?shù)乩迷O(shè)計原則、思想、模式編寫高質(zhì)量的代碼。除此之外，還有一些外在的方法可循。

今天，我就從研發(fā)管理和開發(fā)技巧的角度來帶你看下，面對大型復雜項目的開發(fā)，如何長期保證代碼質(zhì)量，讓代碼長期可維護。

話不多說，讓我們正式開始今天的學習吧！

1. 吹毛求疵般地執(zhí)行編碼規(guī)范

嚴格執(zhí)行代碼規(guī)范，可以使一個項目乃至整個公司的代碼具有完全統(tǒng)一的風格，就像同一個人編寫的。而且，命名良好的變量、函數(shù)、類和注釋，也可以提高代碼的可讀性。編碼規(guī)范不難掌握，關(guān)鍵是要嚴格執(zhí)行。在 Code Review 時，我們一定要嚴格要求，看到不符合規(guī)范的代碼，一定要指出并要求修改。

但是，據(jù)我了解，實際情況往往事與愿違。雖然大家都知道優(yōu)秀的代碼規(guī)范是怎樣的，但在具體寫代碼的過程中，執(zhí)行得卻不好。我覺得，這種情況產(chǎn)生的主要原因還是不夠重視。很多人會覺得，一個變量或者函數(shù)命名成啥樣，關(guān)系并不大。所以命名時不推敲，注釋也不寫，Code Review 的時候也都一副事不關(guān)己的心態(tài)，覺得沒必要太摳細節(jié)。日積月累，項目代碼就會變得越來越差。所以我這里還是要強調(diào)一下，細節(jié)決定成敗，代碼規(guī)范的嚴格執(zhí)行極為關(guān)鍵。

2. 編寫高質(zhì)量的單元測試

單元測試是最容易執(zhí)行且對提高代碼質(zhì)量見效最快的方法之一。高質(zhì)量的單元測試不僅僅要求測試覆蓋率要高，還要求測試的全面性，除了測試正常邏輯的執(zhí)行之外，還要重點、全面地測試異常下的執(zhí)行情況。畢竟代碼出問題的地方大部分都發(fā)生在異常、邊界條件下。

對于大型復雜項目，集成測試、黑盒測試都很難測試全面，因為組合爆炸，窮舉所有測試用例的成本很高，幾乎是不可能的。單元測試就是很好的補充。它可以在類、函數(shù)這些細粒度的代碼層面，保證代碼運行無誤。底層細粒度的代碼 bug 少了，組合起來構(gòu)建而成的整個系統(tǒng)的 bug 也就相應(yīng)的減少了。

3. 不流于形式的 Code Review

如果說很多工程師對單元測試不怎么重視，那對 Code Review 就是不怎么接受。我之前跟一些同行聊起 Code Review 的時候，很多人的反應(yīng)是，這玩意兒不可能很好地執(zhí)行，形式大于效果，純粹是浪費時間。是的，即便 Code Review 做得再流暢，也是要花時間的。所以，在業(yè)務(wù)開發(fā)任務(wù)繁重的時候，Code Review 往往會流于形式、虎頭蛇尾，效果確實不怎么好。

但我們并不能因此就否定 Code Review 本身的價值。在 Google、Facebook 等外企中，Code Review 應(yīng)用得非常成功，已經(jīng)成為了開發(fā)流程中不可或缺的一部分。所以，要想真正發(fā)揮 Code Review 的作用，關(guān)鍵還是要執(zhí)行到位，不能流于形式。

4. 開發(fā)未動、文檔先行

對大部分工程師來說，編寫技術(shù)文檔是件挺讓人“反感”的事情。一般來講，在開發(fā)某個系統(tǒng)或者重要模塊或者功能之前，我們應(yīng)該先寫技術(shù)文檔，然后，發(fā)送給同組或者相關(guān)同事審查，在審查沒有問題的情況下再開發(fā)。這樣能夠保證事先達成共識，開發(fā)出來的東西不至于走樣。而且，當開發(fā)完成之后，進行 Code Review 的時候，代碼審查者通過閱讀開發(fā)文檔，也可以快速理解代碼。

除此之外，對于團隊和公司來講，文檔是重要的財富。對新人熟悉代碼或任務(wù)的交接等，技術(shù)文檔很有幫助。而且，作為一個規(guī)范化的技術(shù)團隊，技術(shù)文檔是一種摒棄作坊式開發(fā)和個人英雄主義的有效方法，是保證團隊有效協(xié)作的途徑。

5. 持續(xù)重構(gòu)、重構(gòu)、重構(gòu)

我個人比較反對平時不注重代碼質(zhì)量，堆砌爛代碼，實在維護不了了就大刀闊斧地重構(gòu)甚至重寫。有的時候，因為項目代碼太多，重構(gòu)很難做到徹底，最后又搞出來一個四不像的怪物，這就更麻煩了！

優(yōu)秀的代碼或架構(gòu)不是一開始就能設(shè)計好的，就像優(yōu)秀的公司或產(chǎn)品也都是迭代出來的。我們無法 100% 預(yù)見未來的需求，也沒有足夠的精力、時間、資源為遙遠的未來買單。所以，隨著系統(tǒng)的演進，重構(gòu)是不可避免的。

雖然我剛剛說不支持大刀闊斧、推倒重來式的大重構(gòu)，但持續(xù)的小重構(gòu)我還是比較提倡的。它也是時刻保證代碼質(zhì)量、防止代碼腐化的有效手段。換句話說，不要等到問題堆得太多了再去解決，要時刻有人對代碼整體質(zhì)量負責任，平時沒事就改改代碼。千萬不要覺得重構(gòu)代碼就是浪費時間，不務(wù)正業(yè)！

特別是一些業(yè)務(wù)開發(fā)團隊，有時候為了快速完成一個業(yè)務(wù)需求，只追求速度，到處 hard code，在完全不考慮非功能性需求、代碼質(zhì)量的情況下，堆砌爛代碼。實際上，這種情況還是比較常見的。不過沒關(guān)系，等你有時間了，一定要記著重構(gòu)，不然爛代碼越堆越多，總有一天代碼會變得無法維護。

6. 對項目與團隊進行拆分

我們知道，團隊人比較少，比如十幾個人的時候，代碼量不多，不超過 10 萬行，怎么開發(fā)、怎么管理都沒問題，大家互相都比較了解彼此做的東西。即便代碼質(zhì)量太差了，我們大不了把它重寫一遍。但是，對于一個大型項目來說，參與開發(fā)的人員會比較多，代碼量很大，有幾十萬、甚至幾百萬行代碼，有幾十、甚至幾百號人同時開發(fā)維護，那研發(fā)管理就變得極其重要。

面對大型復雜項目，我們不僅僅需要對代碼進行拆分，還需要對研發(fā)團隊進行拆分。上一節(jié)課我們講到了一些代碼拆分的方法，比如模塊化、分層等。同理，我們也可以把大團隊拆成幾個小團隊。每個小團隊對應(yīng)負責一個小的項目（模塊、微服務(wù)等），這樣每個團隊負責的項目包含的代碼都不至于很多，也不至于出現(xiàn)代碼質(zhì)量太差無法維護的情況。

重點回顧

好了，今天的內(nèi)容到此就講完了。我們一塊來總結(jié)回顧一下，你需要重點掌握的內(nèi)容。

實際上，我剛剛講的 6 條方法論應(yīng)該都沒啥新奇的，也沒有葵花寶典似的殺手锏，說出來感覺都很簡單。而且，現(xiàn)在互聯(lián)網(wǎng)這么發(fā)達，信息都很透明，所以大方向我覺得你應(yīng)該都知道，具體的策略和架構(gòu)各家也都差不多，最后誰做得好，關(guān)鍵在于執(zhí)行和細節(jié)。

我經(jīng)常聽人說，我們做了單元測試、Code Review 啊，但到最后，項目還是一堆 bug，代碼質(zhì)量還是很差。這個時候，我們就要去思考一下，單元測試、Code Review 做得到底夠不夠好，從決策到執(zhí)行再到考核是否形成了閉環(huán)，不要口號喊的 100 分，落實到執(zhí)行只有 50 分，最后又沒有很好的考核機制，好壞大家也都不知道。所以，一句話總結(jié)一下：切記敏于言而訥于行。

除此之外，我們剛剛講的所有方法都治標不治本。軟件開發(fā)過程中的問題往往千奇百怪。要想每個問題都能順利解決，除了理論知識和經(jīng)驗之外，更重要的是要具備分析問題、解決問題的能力。這也是為什么很多公司很重視應(yīng)屆生招聘，希望從一開始就招聘一些有潛力的員工。找到對的人、用對好的人，打造優(yōu)秀的技術(shù)文化，才是一直保持卓越的根本。

課堂討論

從研發(fā)管理和開發(fā)技巧的角度，你還有哪些能夠有效保持項目代碼質(zhì)量的經(jīng)驗，可以分享給大家？文章來源地址http://www.zghlxwxcb.cn/news/detail-511012.html

到了這里，關(guān)于【開源與項目實戰(zhàn)：開源實戰(zhàn)】79 | 開源實戰(zhàn)二（中）：從Unix開源開發(fā)學習應(yīng)對大型復雜項目開發(fā)的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！