所有開發(fā)人員都認為自己寫的代碼完全能讓人看懂，然而，他們卻無法解密彼此的代碼(更不用說維護代碼了)。

原因在于他們寫的代碼都是有效卻草率的，看起來很干凈，但實際上卻很凌亂。草率代碼是指就是那些可以正常運行，但因凌亂而不能很好地拓展或通用的代碼。

計算機科學家與之不同——他們寫的是無法正常運行的漂亮代碼。

原因何在?以下的四大理由將為你揭秘。

四大理由

理由1：對于計算機科學家來說，編碼是一項藝術。而對于其他人來說，編碼是一種工具

計算機科學家編碼是因為他們想編碼，而其他人編碼是因為他們想完成某件事。開發(fā)人員一般會根據自己的第一個想法來構建程序。之后，他們會以之為基礎，直到最簡化可實行產品出現(xiàn)，通常不會考慮其他方法。

而計算機科學家恰恰相反，他們會考慮實施的每一種選擇，并權衡利弊。幾周之后，他們會寫出一段漂亮的代碼，不過由于尚未確定輸出格式，代碼仍然無法完全正常運行。

開發(fā)人員使用簡單的工具有組織地擴展代碼，從而產生了大量草率代碼;計算機科學家則會在一開始建立起一個結構，之后在結構中開展工作。

最有效的就是用有機方法避免編碼器的阻礙并按時交付。但是，如果想要編寫持久代碼，則可能需要把結構放在首位。

理由2：開發(fā)人員寫代碼時不?？紤]讀者的感受

即使是在合作項目中，開發(fā)人員寫代碼時也往往只考慮到它的功能。實際上，代碼也需要維護，不過他們經常會把這件事拋之腦后。

問題在于，這樣的習慣會造成意想不到的后果。當三個月后，他們想給代碼添加一個功能時，很可能會看不懂自己寫的代碼。這種情況經常出現(xiàn)，次數之多超乎想象!

其他開發(fā)人員按要求實施新功能時，則會更艱難。看懂別人寫的代碼可能需要幾天或幾周的時間，這取決于項目的大小。

理由3：即時獎勵的謬論

被問題困擾了好幾天，最后終于找到了解決方案，是不是感覺特別痛快?

這確實是激動人心的時刻。但問題在于，開發(fā)人員對快速修復的渴望往往會讓他們忽略那些長期存在的問題。比如，他們可能解除了故障或添加了功能，但他們沒有意識到代碼結構已經過時了。

這意味著每添加一個新功能，他們都必須要開展更多的工作。相反，從長遠來看，對程序進行一次重組會讓功能的添加變得更容易。

寧愿快速修復而非解決根本問題的人不在少數。與長期的變化相比，人類的獎賞系統(tǒng)更容易受到短期修復的影響。但這樣一來就會累積大量的技術負債。從長遠來看，這會消耗人的很多精力。

理由4：風格也是一個因素

每個人的編碼風格都不一樣。有些人討厭內嵌注釋，有些人卻很喜歡這么做。有些人在第一行代碼上方添加函數注釋，有些人卻選擇在下方添加。有些人喜歡單值判斷，有些人卻對此厭惡至極。

這就是為什么同一段代碼對一個人來說仿佛洪水猛獸，而對另一個人來說卻是小菜一碟。要是獨立工作還好說，然而如今的很多軟件都是通過合作構建的。因此，在項目的早期階段確定好風格十分重要。

當然，確保所有開發(fā)人員遵守風格指南也是必須的。否則，最后產生的將是混亂代碼，畢竟其中混雜著不同的約定。

干凈的危害vs.凌亂的危害

一些開發(fā)人員聲稱自己一直在寫干凈代碼的，他們要么是在撒謊，要么高估了自己。話雖如此，開發(fā)人員不想寫過分干凈代碼也不是毫無理由的：

• 有些開發(fā)人員整天都在清理代碼，只是為了美觀。如果是與其他人合作或者代碼需要呈現(xiàn)，這當然很有用。但通常來說，完善代碼與普通醫(yī)療保健提供的外科手術產生的效果一樣——看起來不錯，但沒有解決深層次的問題。
• 如果他的目標是從頭開始編寫非常干凈的代碼，那么他遭遇編碼器阻礙的幾率就會變大。為避免出現(xiàn)重大阻礙，最好從一開始就自然生成代碼。初學者尤其適用。

[[320428]]

圖源：unsplash

但反過來講，開發(fā)人員也并不想讓代碼過于混亂，這會讓代碼變得難以維護。缺少維護會導致代碼腐爛，從長遠來看，這樣弊大于利，項目會被放棄。

因此，開發(fā)人員需要在立竿見影和可維護代碼之間找到平衡。很多人都深陷混亂的困境，因此提高清潔度是必由之路。

五項技巧

養(yǎng)成一些良好的習慣，可能會對開發(fā)人員的清潔度和生產力大有益處。

圖源：medium.com

技巧1：盡早測試，經常測試

有些開發(fā)人員對自己的技術很有信心，甚至到了不運行測試就構建整個項目的地步。但是，除非手頭的任務完全微不足道的，否則會后悔的。

他們一開始編譯或執(zhí)行程序，屏幕上就會顯示錯誤信息，情況可能還會更糟。幾個月以后，用戶發(fā)現(xiàn)程序無法正常運行，錯誤才被發(fā)現(xiàn)。

從事技術工作會獲得如下經驗：

“如果沒有經過所有情況的測試，永遠不要認為程序會正常運行。”

盡快構建可執(zhí)行文件。只要有機會，就進行測試，一旦出現(xiàn)錯誤就可以立即進行修復。

技巧2：結構合理，格式隨意

只要代碼的基礎結構良好，就可以進行快速修復。而現(xiàn)實是，開發(fā)人員常常面對的是結構凌亂或過時的代碼。在這種情況下，最好花些時間重構代碼。如果修復程式未正確注釋或存在隱藏變量名，也沒什么大不了。

但是，在錯誤代碼中構建干凈的功能完全是浪費時間和資源——開發(fā)人員可能必須要重寫很多功能。

因此，保持清潔度和速度的折中方案就是保持基礎結構的清潔和更新，在細節(jié)上盡可能讓內容混亂。

技巧3：讓代碼保持干凈狀態(tài)

筆者稱之為廁所法則。如果人們使用完的公共浴室(至少)像使用之前的一樣干凈，那這公共浴室的狀態(tài)就堪稱完美。從大多數公共廁所的狀態(tài)來看，現(xiàn)實并非如此。維持廁所法則需要所有人遵守紀律——還需要一位優(yōu)秀的管理者。

遵守這樣的紀律是值得的，因為從長遠來看獲得的回報是巨大的。通過完成不可能的事情來實現(xiàn)不可能，這是天方夜譚——做出明智的決定，每天前進一一點點，不可能才會實現(xiàn)。

技巧4：為重構分配時間

每一次混亂都在產生技術負債。像金融一樣，時間越長，產生的債務就越多。

對于普通開發(fā)人員來說，花上幾天甚至幾周時間清理代碼聽上去并不是那么美好。這就是為什么要養(yǎng)成每天償還一點債務的習慣。

一開始可以每天抽出15%的時間進行重構，這是個不錯的方法。筆者稱之為時間規(guī)劃，長此以往完善的代碼數量將令人驚嘆!

技巧5：要求審查

有時候，代碼出現(xiàn)混亂是因為開發(fā)人員不知道該怎么完善。比如，某個代碼可能使用了switch語句，但使用映射會容易得多。在這種情況下，高級開發(fā)人員的建議至關重要。

建立代碼審查例程有助于創(chuàng)建反饋環(huán)路。這會幫助年輕開發(fā)人員改善學習曲線，形成健康的討論文化。

例程是關鍵，這與廁所法則以及時間規(guī)劃是一樣的。初級開發(fā)人員應養(yǎng)成要求審查的習慣，而高級開發(fā)人員也應提供建議。理想情況下，審查時間應該是開發(fā)團隊核心過程的一部分，每次討論也應總結關鍵建議。

平衡結構與混亂

過多的清理會浪費時間和資源，編寫草率代碼比受到編碼器阻礙而完全無法交付要好得多。但同時，草率代碼不靈活且難以維護。

這五大技巧能幫助你有效清理代碼同時節(jié)省時間，在混亂和結構之間找到平衡點。

快去實踐一下吧!