• 《關(guān)于爛代碼的那些事（上）》

• 《關(guān)于爛代碼的那些事（中）》

假設(shè)你已經(jīng)讀過爛代碼系列的前兩篇：了解了什么是爛代碼，什么是好代碼，但是還是不可避免的接觸到了爛代碼（就像之前說的，幾乎沒有程序員可以完全避免寫出爛代碼?。┙酉聛淼膯栴}便是：如何應(yīng)對這些身邊的爛代碼。

1.改善可維護(hù)性

改善代碼質(zhì)量是項大工程，要開始這項工程，從可維護(hù)性入手往往是一個好的開始，但也僅僅只是開始而已。

1.1.重構(gòu)的悖論

很多人把重構(gòu)當(dāng)做一種一次性運(yùn)動，代碼實(shí)在是爛的沒法改了，或者沒什么新的需求了，就召集一幫人專門拿出來一段時間做重構(gòu)。這在傳統(tǒng)企業(yè)開發(fā)中多少能生效，但是對于互聯(lián)網(wǎng)開發(fā)來說卻很難適應(yīng)，原因有兩個：

• 互聯(lián)網(wǎng)開發(fā)講究快速迭代，如果要做大型重構(gòu)，往往需要暫停需求開發(fā)，這個基本上很難實(shí)現(xiàn)。

• 對于沒有什么新需求的項目，往往意味著項目本身已經(jīng)過了發(fā)展期，即使做了重構(gòu)也帶來不了什么收益。

這就形成了一個悖論：一方面那些變更頻繁的系統(tǒng)更需要重構(gòu)；另一方面重構(gòu)又會耽誤開發(fā)進(jìn)度，影響變更效率。

面對這種矛盾，一種方式是放棄重構(gòu)，讓代碼質(zhì)量自然下降，直到工程的生命周期結(jié)束，選擇放棄或者重來。在某些場景下這種方式確實(shí)是有效的，但是我并不喜歡：比起讓工程師不得不把每天的精力都浪費(fèi)在毫無意義的事情上，為什么不做些更有意義的事呢？

1.2.重構(gòu)step by step

1.2.1.開始之前

開始改善代碼的第一步是把IDE的重構(gòu)快捷鍵設(shè)到一個順手的鍵位上，這一步非常重要：決定重構(gòu)成敗的往往不是你的新設(shè)計有多么牛逼，而是重構(gòu)本身會占用多少時間。

比如對于IDEA來說，我會把重構(gòu)菜單設(shè)為快捷鍵：

這樣在我想去重構(gòu)的時候就可以隨手打開菜單，而不是用鼠標(biāo)慢慢去點(diǎn)，快捷鍵每次只能為重構(gòu)節(jié)省幾秒鐘時間，但是卻能明顯減少工程師重構(gòu)時的心理負(fù)擔(dān)，后面會提到，小規(guī)模的重構(gòu)應(yīng)該跟敲代碼一樣屬于日常開發(fā)的一部分。

我把重構(gòu)分為三類：模塊內(nèi)部的重構(gòu)、模塊級別的重構(gòu)、工程級別的重構(gòu)。分為這三類并不是因?yàn)槲沂鞘裁捶诸悘?qiáng)迫癥，后面會看到對重構(gòu)的分類對于重構(gòu)的意義。

1.2.2.隨時進(jìn)行模塊內(nèi)部的重構(gòu)

模塊內(nèi)部重構(gòu)的目的是把模塊內(nèi)部的邏輯梳理清楚，并且把一個巨大無比的函數(shù)拆分成可維護(hù)的小塊代碼。大部分IDE都提供了對這類重構(gòu)的支持，類似于：

• 重命名變量

• 重命名函數(shù)

• 提取內(nèi)部函數(shù)

• 提取內(nèi)部常量

• 提取變量

這類重構(gòu)的特點(diǎn)是修改基本集中在一個地方，對代碼邏輯的修改很少并且基本可控，IDE的重構(gòu)工具比較健壯，因而基本沒有什么風(fēng)險。

以下例子演示了如何通過IDE把一個冗長的函數(shù)做重構(gòu)：

上圖的例子中，我們基本依靠IDE就把一個冗長的函數(shù)分成了兩個子函數(shù)，接下來就可以針對子函數(shù)中的一些爛代碼做進(jìn)一步的小規(guī)模重構(gòu)，而兩個函數(shù)內(nèi)部的重構(gòu)也可以用同樣的方法。每一次小規(guī)模重構(gòu)的時間都不應(yīng)該超過60s，否則將會嚴(yán)重影響開發(fā)的效率，進(jìn)而導(dǎo)致重構(gòu)被無盡的開發(fā)需求淹沒。

在這個階段需要對現(xiàn)有的模塊補(bǔ)充一些單元測試，以保證重構(gòu)的正確。不過以我的經(jīng)驗(yàn)來看，一些簡單的重構(gòu)，例如修改局部變量名稱，或者提取變量之類的重構(gòu)，即使沒有測試也是基本可靠的，如果要在快速完成模塊內(nèi)部重構(gòu)和100%的單元測試覆蓋率中選一個，我可能會選擇快速完成重構(gòu)。

而這類重構(gòu)的收益主要是提高函數(shù)級別的可讀性，以及消除超大函數(shù)，為未來進(jìn)一步做模塊級別的拆分打好基礎(chǔ)。

1.2.3.一次只做一個較模塊級別的的重構(gòu)

之后的重構(gòu)開始牽扯到多個模塊，例如：

• 刪除無用代碼

• 移動函數(shù)到其它類

• 提取函數(shù)到新類

• 修改函數(shù)邏輯

IDE往往對這類重構(gòu)的支持有限，并且偶爾會出一些莫名其妙的問題，（例如修改類名時一不小心把配置文件里的常量字符串也給修改了）。

這類重構(gòu)主要在于優(yōu)化代碼的設(shè)計，剝離不相關(guān)的耦合代碼，在這類重構(gòu)期間你需要創(chuàng)建大量新的類和新的單元測試，而此時的單元測試則是必須的了。

為什么要創(chuàng)建單元測試？

• 一方面，這類重構(gòu)因?yàn)樯婕暗骄唧w代碼邏輯的修改，靠集成測試很難覆蓋所有情況，而單元測試可以驗(yàn)證修改的正確性。

• 更重要的意義在于，寫不出單元測試的代碼往往意味著糟糕的設(shè)計：模塊依賴太多或者一個函數(shù)的職責(zé)太重，想象一下，想要執(zhí)行一個函數(shù)卻要模擬十幾個輸入對象，每個對象還要模擬自己依賴的對象……如果一個模塊無法被單獨(dú)測試，那么從設(shè)計的角度來考慮，無疑是不合格的。

還需要啰嗦一下，這里說的單元測試只對一個模塊進(jìn)行測試，依賴多個模塊共同完成的測試并不包含在內(nèi)-例如在內(nèi)存里模擬了一個數(shù)據(jù)庫，并在上層代碼中測試業(yè)務(wù)邏輯-這類測試并不能改善你的設(shè)計。

在這個期間還會寫一些過渡用的臨時邏輯，比如各種adapter、proxy或者wrapper，這些臨時邏輯的生存期可能會有幾個月到幾年，這些看起來沒什么必要的工作是為了控制重構(gòu)范圍，例如：

class Foo {

String foo() {

...

}

}

如果要把函數(shù)聲明改成：

class Foo {

boolean foo() {

...

}

}

那么最好通過加一個過渡模塊來實(shí)現(xiàn)：

class FooAdaptor {

private Foo foo;

boolean foo() {

return foo.foo().isEmpty();

}

}

這樣做的好處是修改函數(shù)時不需要改動所有調(diào)用方，爛代碼的特征之一就是模塊間的耦合比較高，往往一個函數(shù)有幾十處調(diào)用，牽一發(fā)而動全身。而一旦開始全面改造，往往就會把一次看起來很簡單的重構(gòu)演變成幾周的大工程，這種大規(guī)模重構(gòu)往往是不可靠的。

每次模塊級別的重構(gòu)都需要精心設(shè)計，提前劃分好哪些是需要修改的，哪些是需要用兼容邏輯做過渡的。但實(shí)際動手修改的時間都不應(yīng)該超過一天，如果超過一天就意味著這次重構(gòu)改動太多，需要控制一下修改節(jié)奏了。

1.2.4.工程級別的重構(gòu)不能和任何其他任務(wù)并行

不安全的重構(gòu)相對而言影響范圍比較大，比如：

• 修改工程結(jié)構(gòu)

• 修改多個模塊

我更建議這類操作不要用IDE，如果使用IDE，也只使用最簡單的“移動”操作。這類重構(gòu)單元測試已經(jīng)完全沒有作用，需要集成測試的覆蓋。不過也不必緊張，如果只做“移動”的話，大部分情況下基本的冒煙測試就可以保證重構(gòu)的正確性。

這類重構(gòu)的目的是根據(jù)代碼的層次或者類型進(jìn)行拆分，切斷循環(huán)依賴和結(jié)構(gòu)上不合理的地方。如果不知道如何拆分，可以依照如下思路：

1. 優(yōu)先按部署場景進(jìn)行拆分，比如一部分代碼是公用的，一部分代碼是自己用的，可以考慮拆成兩個部分。換句話說，A服務(wù)的修改能不能影響B(tài)服務(wù)。

2. 其次按照業(yè)務(wù)類型拆分，兩個無關(guān)的功能可以拆分成兩個部分。換句話說，A功能的修改能不能影響B(tài)功能。

3. 除此之外，盡量控制自己的代碼潔癖，不要把代碼切成一大堆豆腐塊，會給日后的維護(hù)工作帶來很多不必要的成本。

4. 案可以提前review幾次，多參考一線工程師的意見，避免實(shí)際動手時才冒出新的問題。

而這類重構(gòu)絕對不能跟正常的需求開發(fā)并行執(zhí)行：代碼沖突幾乎無法避免，并且會讓所有人崩潰。我的做法一般是在這類重構(gòu)前先演練一次：把模塊按大致的想法拖來拖去，通過編譯器找到依賴問題，在日常上線中把容易處理的依賴問題解決掉；然后集中團(tuán)隊里的精英，通知所有人暫停開發(fā)，花最多2、3天時間把所有問題集中突擊掉，新的需求都在新代碼的基礎(chǔ)上進(jìn)行開發(fā)。

如果歷史包袱實(shí)在太重，可以把這類重構(gòu)也拆成幾次做：先大體拆分成幾塊，再分別拆分。無論如何，這類重構(gòu)務(wù)必控制好變更范圍，一次嚴(yán)重的合并沖突有可能讓團(tuán)隊中的所有人幾個周緩不過勁來。

1.3.重構(gòu)的周期

典型的重構(gòu)周期類似下面的過程：

1. 在正常需求開發(fā)的同時進(jìn)行模塊內(nèi)部的重構(gòu)，同時理解工程原有代碼。

2. 在需求間隙進(jìn)行模塊級別的重構(gòu)，把大模塊拆分為多個小模塊，增加腳手架類，補(bǔ)充單元測試，等等。

3. （如果有必要，比如工程過于巨大導(dǎo)致經(jīng)常出現(xiàn)相互影響問題）進(jìn)行一次工程級別的拆分，期間需要暫停所有開發(fā)工作，并且這次重構(gòu)除了移動模塊和移動模塊帶來的修改之外不做任何其他變更。

4. 重復(fù)1、2步驟

1.3.1.一些重構(gòu)的tips

1. 只重構(gòu)經(jīng)常修改的部分，如果代碼一兩年都沒有修改過，那么說明改動的收益很小，重構(gòu)能改善的只是可維護(hù)性，重構(gòu)不維護(hù)的代碼不會帶來收益。

2. 抑制住自己想要多改一點(diǎn)的沖動，一次失敗的重構(gòu)對代碼質(zhì)量改進(jìn)的影響可能是毀滅性的。

3. 重構(gòu)需要不斷的練習(xí)，相比于寫代碼來說，重構(gòu)或許更難一些。

4. 重構(gòu)可能需要很長時間，有可能甚至?xí)_(dá)到幾年的程度（我之前用斷斷續(xù)續(xù)兩年多的時間重構(gòu)了一個項目），主要取決于團(tuán)隊對于風(fēng)險的容忍程度。

5. 刪除無用代碼是提高代碼可維護(hù)性最有效的方式，切記，切記。

6. 單元測試是重構(gòu)的基礎(chǔ)，如果對單元測試的概念還不是很清晰，可以參考《使用Spock框架進(jìn)行單元測試》。

2.改善性能與健壯性

2.1.改善性能的80%

性能這個話題越來越多的被人提起，隨便收到一份簡歷不寫上點(diǎn)什么熟悉高并發(fā)、做過性能優(yōu)化之類的似乎都不好意思跟人打招呼。

說個真事，幾年前在我做某公司的ERP項目，里面有個功能是生成一個報表。而使用我們系統(tǒng)的公司里有一個人，他每天要在下班前點(diǎn)一下報表，導(dǎo)出到excel，再發(fā)一封郵件出去。

問題是，那個報表每次都要2，3分鐘才能生成。

我當(dāng)時正年輕氣盛，看到有個兩分鐘才能生成的報表一下就來了興趣，翻出了那段不知道誰寫的代碼，發(fā)現(xiàn)里面用了3層循環(huán)，每次都會去數(shù)據(jù)庫查一次數(shù)據(jù)，再把一堆數(shù)據(jù)拼起來，一股腦塞進(jìn)一個tableview里。

面對這種代碼，我還能做什么呢？

• 我立刻把那個三層循環(huán)干掉了，通過一個存儲過程直接輸出數(shù)據(jù)。

• sql數(shù)據(jù)計算的邏輯也被我精簡了，一些沒必要做的外聯(lián)操作被我干掉了。

• 我還發(fā)現(xiàn)很多ctrl v生成的無用的控件（那時還是用的delphi），那些控件密密麻麻的貼在顯示界面上，只是被前面的大table擋住了，我當(dāng)然也把這些玩意都刪掉了；

• 打開界面的時候還做了一些雜七雜八的工作（比如去數(shù)據(jù)庫里更新點(diǎn)擊數(shù)之類的），我把這些放到了異步任務(wù)里。

• 后面我又覺得沒必要每次打開界面都要加載所有數(shù)據(jù)（那個tableview有幾千行，幾百列?。?，于是我hack了默認(rèn)的tableview，每次打開的時候先計算當(dāng)前實(shí)際顯示了多少內(nèi)容，把參數(shù)發(fā)給存儲過程，初始化只加載這些數(shù)據(jù)，剩下的再通過線程異步加載。

做了這些之后，界面只需要不到1s就能展示出來了，不過我要說的不是這個。

后來我去客戶公司給那個操作員演示新的模塊的時候，點(diǎn)一下，刷，數(shù)據(jù)出來了。那個人很驚恐的看著我，然后問我，是不是數(shù)據(jù)不準(zhǔn)了。

再后來，我又加了一個功能，那個模塊每次打開之后都會顯示一個進(jìn)度條，上面的標(biāo)題是“正在校驗(yàn)數(shù)據(jù)……”，進(jìn)度條走完大概要1分鐘左右，我跟那人說校驗(yàn)數(shù)據(jù)計算量很大，會比較慢。當(dāng)然，實(shí)際上那60秒里程序毛事都沒做，只是在一點(diǎn)點(diǎn)的更新那個進(jìn)度條（我還做了個彩蛋，在讀進(jìn)度的時候按上上下下左右左右BABA的話就可以加速10倍讀條…）?？蛻艉荛_心，說感覺數(shù)據(jù)準(zhǔn)確多了，當(dāng)然，他沒發(fā)現(xiàn)彩蛋。

我寫了這么多，是想讓你明白一個事實(shí)：大部分程序?qū)π阅懿⒉幻舾?。而少?shù)對性能敏感的程序里，一大半可以靠調(diào)節(jié)參數(shù)解決性能問題；最后那一小撮需要修改代碼優(yōu)化性能的程序里，性價比高的工作又是少數(shù)。

什么是性價比？回到剛才的例子里，我做了那么多事，每件事的收益是多少？

• 把三層循環(huán)sql改成了存儲過程，大概讓我花了一天時間，讓加載時間從3分鐘變成了2秒，模塊加載變成了”唰“的一下。

• 后面的一坨事情大概花了我一周多時間，尤其是hack那個tableview，讓我連周末都搭進(jìn)去了。而所有的優(yōu)化加起來，大概優(yōu)化了1秒左右，這個數(shù)據(jù)是通過日志查到的：即使是我自己，打開模塊也沒感覺出有什么明顯區(qū)別。

我現(xiàn)在遇到的很多面試者說程序優(yōu)化時總是喜歡說一些玄乎的東西：調(diào)用棧、尾遞歸、內(nèi)聯(lián)函數(shù)、GC調(diào)優(yōu)……但是當(dāng)我問他們：把一個普通函數(shù)改成內(nèi)聯(lián)函數(shù)是把原來運(yùn)行速度是多少的程序優(yōu)化成多少了，卻很少有人答出來；或者是扭扭捏捏的說，應(yīng)該很多，因?yàn)檫@個函數(shù)會被調(diào)用很多遍。我再問會被調(diào)用多少遍，每遍是多長時間，就答不上來了。

所以關(guān)于性能優(yōu)化，我有兩個觀點(diǎn)：

1. 優(yōu)化主要部分，把一次網(wǎng)絡(luò)IO改為內(nèi)存計算帶來的收益遠(yuǎn)大于捯飭編譯器優(yōu)化之類的東西。這部分內(nèi)容可以參考Numbers you should know；或者自己寫一個for循環(huán)，做一個無限i 的程序，看看一秒鐘i能累加多少次，感受一下cpu和內(nèi)存的性能。

2. 性能優(yōu)化之后要有量化數(shù)據(jù)，明確的說出優(yōu)化后哪個指標(biāo)提升了多少。如果有人因?yàn)椤碧嵘阅堋爸惖睦碛蓪懥艘欢炎屓藷o法理解的代碼，請務(wù)必讓他給出性能數(shù)據(jù)：這很有可能是一坨沒有什么收益的爛代碼。

至于具體的優(yōu)化措施，無外乎幾類：

1. 讓計算靠近存儲

2. 優(yōu)化算法的時間復(fù)雜度

3. 減少無用的操作

4. 并行計算

關(guān)于性能優(yōu)化的話題還可以講很多內(nèi)容，不過對于這篇文章來說有點(diǎn)跑題，這里就不再詳細(xì)展開了。

2.2.決定健壯性的20%

前一陣聽一個技術(shù)分享，說是他們在編程的時候要考慮太陽黑子對cpu計算的影響，或者是農(nóng)民伯伯的豬把基站拱塌了之類的特殊場景。如果要優(yōu)化程序的健壯性，那么有時候就不得不去考慮這些極端情況對程序的影響。

大部分的人應(yīng)該不用考慮太陽黑子之類的高深的問題，但是我們需要考慮一些常見的特殊場景，大部分程序員的代碼對于一些特殊場景都會有或多或少考慮不周全的地方，例如：

• 用戶輸入

• 并發(fā)

• 網(wǎng)絡(luò)IO

常規(guī)的方法確實(shí)能夠發(fā)現(xiàn)代碼中的一些bug，但是到了復(fù)雜的生產(chǎn)環(huán)境中時，總會出現(xiàn)一些完全沒有想到的問題。雖然我也想了很久，遺憾的是，對于健壯性來說，我并沒有找到什么立竿見影的解決方案，因此，我只能謹(jǐn)慎的提出一點(diǎn)點(diǎn)建議：

• 更多的測試測試的目的是保證代碼質(zhì)量，但測試并不等于質(zhì)量，你做覆蓋80%場景的測試，在20%測試不到的地方還是有可能出問題。關(guān)于測試又是一個巨大的話題，這里就先不展開了。

• 謹(jǐn)慎發(fā)明輪子。例如UI庫、并發(fā)庫、IO client等等，在能滿足要求的情況下盡量采用成熟的解決方案，所謂的“成熟”也就意味著經(jīng)歷了更多實(shí)際使用環(huán)境下的測試，大部分情況下這種測試的效果是更好的。

3.改善生存環(huán)境

看了上面的那么多東西之后，你可以想一下這么個場景：

在你做了很多事情之后，代碼質(zhì)量似乎有了質(zhì)的飛躍。正當(dāng)你以為終于可以擺脫天天踩屎的日子了的時候，某次不小心瞥見某個類又長到幾千行了。

你憤怒的翻看提交日志，想找出罪魁禍?zhǔn)资钦l，結(jié)果卻發(fā)現(xiàn)每天都會有人往文件里提交那么十幾二十行代碼，每次的改動看起來都沒什么問題，但是日積月累，一年年過去，當(dāng)初花了九牛二虎之力重構(gòu)的工程又成了一坨爛代碼……

任何一個對代碼有追求的程序員都有可能遇到這種問題，技術(shù)在更新，需求在變化，公司人員會流動，而代碼質(zhì)量總會在不經(jīng)意間偷偷的變差……

想要改善代碼質(zhì)量，最后往往就會變成改善生存環(huán)境。

3.1.1.統(tǒng)一環(huán)境

團(tuán)隊需要一套統(tǒng)一的編碼規(guī)范、統(tǒng)一的語言版本、統(tǒng)一的編輯器配置、統(tǒng)一的文件編碼，如果有條件最好能使用統(tǒng)一的操作系統(tǒng)，這能避免很多無意義的工作。

就好像最近渣浪給開發(fā)全部換成了統(tǒng)一的macbook，一夜之間以前的很多問題都變得不是問題了：字符集、換行符、IDE之類的問題只要一個配置文件就解決了，不再有各種稀奇古怪的代碼沖突或者不兼容的問題，也不會有人突然提交上來一些編碼格式稀奇古怪的文件了。

3.1.2.代碼倉庫

代碼倉庫基本上已經(jīng)是每個公司的標(biāo)配，而現(xiàn)在的代碼倉庫除了儲存代碼，還可以承擔(dān)一些團(tuán)隊溝通、代碼review甚至工作流程方面的任務(wù)，如今這類開源的系統(tǒng)很多，像gitlab(github)、Phabricator這類優(yōu)秀的工具都能讓代碼管理變得簡單很多。我這里無意討論svn、git、hg還是什么其它的代碼管理工具更好，就算最近火熱的git在復(fù)雜性和集中化管理上也有一些問題，其實(shí)我是比較期待能有替代git的工具產(chǎn)生的，扯遠(yuǎn)了。

代碼倉庫的意義在于讓更多的人能夠獲得和修改代碼，從而提高代碼的生命周期，而代碼本身的生命周期足夠持久，對代碼質(zhì)量做的優(yōu)化才有意義。

3.1.3.持續(xù)反饋

大多數(shù)爛代碼就像癌癥一樣，當(dāng)爛代碼已經(jīng)產(chǎn)生了可以感覺到的影響時，基本已經(jīng)是晚期，很難治好了。

因此提前發(fā)現(xiàn)代碼變爛的趨勢很重要，這類工作可以依賴類似于checkstyle，findbug之類的靜態(tài)檢查工具，及時發(fā)現(xiàn)代碼質(zhì)量下滑的趨勢，例如：

1. 每天都在產(chǎn)生大量的新代碼

2. 測試覆蓋率下降

3. 靜態(tài)檢查的問題增多

有了代碼倉庫之后，就可以把這種工具與倉庫的觸發(fā)機(jī)制結(jié)合起來，每次提交的時候做覆蓋率、靜態(tài)代碼檢查等工作，jenkins sonarqube或者類似的工具就可以完成基本的流程：伴隨著代碼提交進(jìn)行各種靜態(tài)檢查、運(yùn)行各種測試、生成報告并供人參考。

在實(shí)踐中會發(fā)現(xiàn)，關(guān)于持續(xù)反饋的五花八門的工具很多，但是真正有用的往往只有那么一兩個，大部分人并不會去在每次提交代碼之后再打開一個網(wǎng)頁點(diǎn)擊“生成報告”，或者去登陸什么系統(tǒng)看一下測試的覆蓋率是不是變低了，因此一個一站式的系統(tǒng)大多數(shù)情況下會表現(xiàn)的更好。與其追求更多的功能，不如把有限的幾個功能整合起來，例如我們把代碼管理、回歸測試、代碼檢查、和code review集成起來，就是這個樣子：

當(dāng)然，關(guān)于持續(xù)集成還可以做的更多，篇幅所限，就不多說了。

3.1.4.質(zhì)量文化

不同的團(tuán)隊文化會對技術(shù)產(chǎn)生微妙的影響，關(guān)于代碼質(zhì)量沒有什么共同的文化，每個公司都有自己的一套觀點(diǎn)，并且似乎都能說得通。

對于我自己來說，關(guān)于代碼質(zhì)量是這樣的觀點(diǎn)：

1. 爛代碼無法避免

2. 爛代碼無法接受

3. 爛代碼可以改進(jìn)

4. 好的代碼能讓工作更開心一些

如何讓大多數(shù)人認(rèn)同關(guān)于代碼質(zhì)量的觀點(diǎn)實(shí)際上是有一些難度的，大部分技術(shù)人員對代碼質(zhì)量的觀點(diǎn)是既不贊成、也不反對的中立態(tài)度，而代碼質(zhì)量就像是熵值一樣，放著不管總是會像更加混亂的方向演進(jìn)，并且寫爛代碼的成本實(shí)在是太低了，以至于一個實(shí)習(xí)生花上一個禮拜就可以毀了你花了半年精心設(shè)計的工程。

所以在提高代碼質(zhì)量時，務(wù)必想辦法拉上團(tuán)隊里的其他人一起。雖然“引導(dǎo)團(tuán)隊提高代碼質(zhì)量”這件事情一開始會很辛苦，但是一旦有了一些支持者，并且有了可以參考的模板之后，剩下的工作就簡單多了。

這里推薦《布道之道：引領(lǐng)團(tuán)隊擁抱技術(shù)創(chuàng)新》這本書，里面大部分的觀點(diǎn)對于代碼質(zhì)量也是可以借鑒的。僅靠喊口號很難讓其他人寫出高質(zhì)量的代碼，讓團(tuán)隊中的其他人體會到高質(zhì)量代碼的收益，比喊口號更有說服力。

4.最后再說兩句

優(yōu)化代碼質(zhì)量是一件很有意思，也很有挑戰(zhàn)性的事情，而挑戰(zhàn)不光來自于代碼原本有多爛，要改進(jìn)的也并不只是代碼本身，還有工具、習(xí)慣、練習(xí)、開發(fā)流程、甚至團(tuán)隊文化這些方方面面的事情。

寫這一系列文章前前后后花了半年多時間，一直處在寫一點(diǎn)刪一點(diǎn)的狀態(tài)：我自身關(guān)于代碼質(zhì)量的想法和實(shí)踐也在經(jīng)歷著不斷變化。我更希望能寫出一些能夠?qū)嵺`落地的東西，而不是喊喊口號，忽悠忽悠“敏捷開發(fā)”、“測試驅(qū)動”之類的幾個名詞就結(jié)束了。

但是在寫文章的過程中就會慢慢發(fā)現(xiàn)，很多問題的改進(jìn)方法確實(shí)不是一兩篇文章可以說明白的，問題之間往往又相互關(guān)聯(lián)，全都展開說甚至超出了一本書的信息量，所以這篇文章也只能刪去了很多內(nèi)容。

我參與過很多代碼質(zhì)量很好的項目，也參與過一些質(zhì)量很爛的項目，改進(jìn)了很多項目，也放棄了一些項目，從最初的單打獨(dú)斗自己改代碼，到后來帶領(lǐng)團(tuán)隊優(yōu)化工作流程，經(jīng)歷了很多。無論如何，關(guān)于爛代碼，我決定引用一下《布道之道》這本書里的一句話：

“‘更好’，其實(shí)不是一個目的地，而是一個方向…在當(dāng)前的位置和將來的目標(biāo)之間，可能有很多相當(dāng)不錯的地方。你只需關(guān)注離開現(xiàn)在的位置，而不要關(guān)心去向何方?！?/p>