[[320382]]

 策劃 | 劉燕

作者 | Rhea Moutafis Following

翻譯 | 劉雅夢

編輯 | Linda

好的事物都是在結構和混亂的健康平衡中產生的。

為什么你的代碼這么潦草?

為什么每個開發人員都認為自己編寫的代碼是完全可以理解的?為什么同一個開發人員不能看懂和理解別人編寫的代碼，從而很少能對其進行維護呢?

是因為他們寫的代碼都很潦草。也就是說，代碼現在可以正常運行，但由于它相當混亂，不具備很好的可擴展性或通用性。計算機科學家是個例外 — 他們編寫的代碼很“漂亮”，但不起作用。

原因 1：對于計算機科學家來說，編碼是一門藝術。對其他人來說，它僅是個工具

計算機科學家編碼是因為他們想編碼。其他人編碼是因為他們想完成工作。

一個普通的開發人員會根據他們能想到的第一個想法來構建程序。然后他們會在這個想法的基礎上繼續延伸，直到構建出類似 MVP 的東西。通常情況下，他們甚至不會考慮是否還有其他可行的方法。

相反，計算機科學家會考慮實現的各種方案，權衡每種方案的利弊。幾周之后，他們可能還只是編寫了一段漂亮但仍然不能完全運行的代碼，因為計算機科學家還沒有決定好輸出要采用什么格式。

很多潦草代碼的產生是由于開發人員僅從一個簡單的工具開始，然后就有機地增長代碼造成的。相比之下，計算機科學家通常會先構建一個結構框架，然后再在框架內實現編碼。

有些代碼看起來很整潔，但實際上卻很混亂。

 

為了避免 Coder Block 能按時交付，采用有機的方法是最好的。但是，如果我們想要編寫可持續的代碼，可能就需要將結構框架放在第一位了。

原因 2：開發人員并不總是以讀者為中心來編碼

即使是在協作項目中，開發人員也傾向于在編碼時僅考慮其功能。他們這樣做時，就會忘記“代碼也是需要維護”的這一事實。

問題在于這種心態會適得其反。當開發人員想在三個月后再添加一個特性時，他們可能連自己都無法理解自己編寫的代碼了。這種情況比你想象中的要更常見!

當另一個開發人員被要求實現這個新特性時，情況會變得更加復雜。由于項目規模大小的不同，理解其他人編寫的代碼可能需要花費幾天到幾周的時間。

原因 3：風格很重要

每個人都以不同的方式編碼。有人討厭行注釋，有人則喜歡。有人會在第一行的上面注釋它們的功能，有人則會在第一行的下面注釋。有人喜歡使用 switch 開關語句，有人則討厭。

這就是為什么一段代碼對一個人來說可能很可怕，但對另一個人來說卻很好。

當你獨自工作時，這沒什么問題。但如今，很多軟件都是協同構建的。因此，在項目的早期，制定風格指南是很重要的。

當然，我們還需要確保所有的開發人員都遵守它。否則，我們將以代碼更加混亂而告終，因為此時代碼會是各種不同約定混雜后的產物。

及時修復是有益的，但從長遠來看可能會導致大混亂。

 

理由原因 4：即時獎勵的謬論

你被一個問題困擾了很幾天，當你終于找到了解決方案時，你是否會感到興奮?這是一個非常激動人心的時刻。

問題在于，當開發人員追求快速修復時，往往會忽略長期的問題。例如，他們可能修復了一個 bug 或者添加了一個特性，但是他們沒有意識到代碼結構已經過時了。

這意味著每當他們要添加一個新特性時，都不得不投入更多的工作。相反，從長遠來看，對程序進行一次重構，當添加更多新特性時，將會變得更加容易。

如果你更喜歡快速修復而不是解決潛在的問題，沒關系，這樣的人很多。人類的獎勵系統更容易受到短期修正而不是長期變化的影響。但這樣一來，我們就欠下了“技術債”。從長遠來看，這會讓我們付出更多代價。

整潔 vs 混亂的危險

聲稱自己總是編寫整潔代碼的開發人員要么是撒謊，要么是高估了自己。也就是說，我們不想編寫太整潔的代碼是有原因的：

• 如果你的目標是從頭開始編寫整潔的代碼，那么你就增加了 Coder Block 的風險。為了避免主要的 Block 發生，最好是在一開始時就有機地增加代碼。這尤其適用于初學者。
• 一些開發人員會花一整天的時間來清理他們的代碼，只是為了美觀，而沒有其他原因。當然，如果還有很多其他協作者，或者代碼可以以任何一種方式來呈現，這都是無可厚非的。但通常情況下，潤色代碼的效果就像一般的醫療整形手術一樣——可能看起來很不錯，但并不解決任何更深層次的問題。

另一方面，我們也不希望代碼太混亂。太混亂會使我們的代碼無法維護。缺乏維護會導致代碼“腐爛”，從長遠來看，項目將會被丟棄，因為它們的弊大于利。

因此，我們需要的是在快速拿結果和代碼可維護性之間維持健康的平衡。大多數開發人員都會陷入代碼混亂的困境，所以提高整潔度才是解決之道。好消息是，一些好的習慣可以對開發人員的代碼整潔度和生產力產生巨大的影響。

 

 

 

 

技巧 1：盡早進行測試并提高測試頻度

一些開發人員對他們的技術非常有信心，以至于他們在不運行任何測試的情況下就構建完了整個項目。但是，除非手頭的任務是完全無關緊要，否則只會適得其反。

當他們嘗試編譯或執行程序時，屏幕上就會充滿各種錯誤消息。或者，更糟糕的是，直到幾個月后，當用戶意識到程序沒有按照預期運行時，錯誤才會被發現。

這些都是不好的做法。如果在技術部門工作可以教會我們什么的話，那應該是：

如果你沒有對所有場景進行測試，就永遠不要假設某些東西能像預期的那樣運行。

盡可能快速地構建一些可執行的代碼。即使它非常非常的簡單。一有機會就測試一下它。這樣你就可以在錯誤構建完之后能立即修復它們了。

技巧 2：結構良好但格式混亂

只要代碼的底層結構是好的，追求快速修復也是可以的。但實際情況是，開發人員試圖在混亂或過時的代碼結構中實現快速修復。

在這種情況下，最好花時間重構代碼。如果需要修復的代碼沒有正確的注釋，或者變量命名詞不達意，那也不是沒得救。但是，試圖在充滿 bug 的代碼中構建一個干凈的特性卻是浪費時間和資源的，不管怎么樣，我們可能需要重寫很多其他特性。

因此，在代碼整潔度和速度之間進行選擇的一個很好的折衷方案是保持底層結構的整潔和更新，但在細節上可以容忍混亂。

 

技巧 3：為重構分配時間

每次你搞得一團糟，你都是在制造技術債。就像貨幣債一樣，你借貸的時間越長，它的成本就越高。

另一方面，花上幾天甚至幾周的時間來清理代碼，對一般的開發人員來說，并不能受到鼓舞。這就是為什么建立一個每天都能還一點債務的習慣是非常有用的。

一個好的開始方法是每天花費 15% 的時間來進行重構。我稱之為時間規則。你會為你能改進的代碼量感到驚訝的!

技巧 4：留下比你發現時更整潔的代碼

我把這叫做“廁所規則”。如果每個人在離開公廁時，公廁至少要和他們進入時一樣干凈，那么他們將會處于無可挑剔的狀態。

從大多數公共廁所的狀況來看，現實并非如此。維持這樣的規則需要每個開發人員都遵守紀律，而這反過來還需要一個優秀的管理者。

但遵守這種紀律是值得的，因為隨著時間的推移，回報是巨大的。我們不可能通過做不可能的事情來實現不可能。我們只需通過做一些好的決定就能實現它，并且每天都朝著這個目標邁出一小步即可。

技巧 5：請求審查!

有時，代碼會很混亂，是因為開發人員不知道如何才能做得更好。例如，代碼可能在使用 map 更簡單的情況下使用了 switch 語句。在這種情況下，來自高級開發人員的建議就是關鍵。

建立代碼審查的例程可以幫助我們創建一個反饋機制。這將會改善年輕開發人員的學習曲線，并能培養一種健康討論的文化。

就像“廁所規則”和時間規則一樣，例程是關鍵。請求審查應該是初級開發人員的一種習慣，提供建議應該是高級開發人員工作的一部分。

理想情況下，審查時間應該是開發團隊核心流程的一部分，而對關鍵審查建議的總結也應是每次會議的一部分。

 

 

 

 

平衡結構與混沌

編寫太過整潔的代碼會浪費時間和資源。編寫潦草的代碼比遭遇 Coder Block 而根本無法交付要好得多。

另一方面，潦草的代碼不靈活且難以維護。這五條規則將有助于使我們的代碼變得更整潔，且無需浪費時間。正如生活的各方面一樣，好的事物都是在結構和混亂的健康平衡中產生的。