Categories
程式開發

怎樣處理糟糕的代碼?


怎樣處理糟糕的代碼? 1

在職業生涯中,程序員難免會遇到糟糕的代碼(bad code]——但是你並不需要成為一個打敗這些糟糕代碼的“惡人”。

從輕鬆的角度來講,糟糕的代碼可以創造大量的就業機會。比如:

  • 需要從諸多優秀開發人員中找一個人來修復錯誤代碼。
  • 需要一兩個高級開發人員來做代碼審查,確保代碼以後不會再次變得糟糕。
  • 其他人還需要時不時地去諮詢那位糟糕的程序員,以便弄明白這些亂七八糟的代碼到底在幹嘛。

也就是說,我們都有過類似經歷。我們不知疲倦地加班加點,試圖去解決一個特別麻煩的錯誤,這時我們發現一個代碼塊,而它就是問題的根源。當你試圖弄明白這堆一團亂麻的代碼的意義時,卻發現這段代碼根本無法閱讀,邏輯混亂不堪,且完全未加任何代碼註釋,你會倒吸一口涼氣,然後開始咒罵:

“這到底是誰寫的代碼?”

“誰竟然如此愚蠢?”

“怎麼會有人寫出如此毫無條理、人神共憤的代碼呢?”

但我要說,這並不是正確的解決方式。畢竟,我們所有人,在某些時期都會寫出糟糕的代碼。可以這麼說,在這個星球上,每一個開發人員都會在他的一生中製造出安全漏洞、不匹配的UI元素,而且絕對不止一次犯下這些錯誤。不能就此評價說這個開發人員很糟糕。我們都是人,是人就會犯錯。

作為一名優秀的開發人員,你對糟糕代碼的處理方式與你未來的職業發展有很大關係。優秀的開發人員會拋開個人或群體恩怨,對代碼進行更深入透徹的理解,而不是將他們的憤怒情緒一股腦兒發洩到那些編寫糟糕代碼的倒霉開發人員身上。

優秀的開發人員會盡量避免主觀性評價,對糟糕的代碼給予建設性的、客觀的批評,這樣糟糕的代碼就不會捲土重來。他們把解決這些糟糕的代碼轉化為學習和分享的機會,這樣每個人都能從中受益。

這裡我想分享一些優秀的開發人員處理糟糕代碼的方法。

1.識別問題

美國音樂家“艾靈頓公爵”有句話說得很對:

“問題是讓你竭盡全力去努力的機會。”

請帶著好奇心和同理心去解決問題。一般來說,代碼的問題在於,編寫代碼有多種方法,而沒有一種方法稱得上是最好的方法。所以在評估代碼前,試著找出這樣寫代碼背後的原因。設身處地為其他開發人員著想,並找出問題所在。

程序員往往很固執。他們不喜歡被別人告知他們自己的錯誤。所以,正確的方法是對他有足夠的同理心,找出是什麼原因讓他們寫出如此隨處可見的goto語句,如此層層嵌套的switch語句,以及如此晦澀難懂的變量命名。只要有足夠的同理心,你很快就會弄明白背後原因。

“我必須在1小時內完成代碼”

“沒有可用的API”

“我的領域知識有限”,等等……

通過識別問題,你不僅可以從代碼原作者的角度來看待問題,還可以提出具體的解決措施來糾正代碼,而不是在黑暗中對別人進行盲目攻擊。

2.謹慎提問

英國哲學家弗朗西斯·培根有句名言:

“一半的智慧來自於謹慎的提問。”

一旦你識別了代碼問題,下一步就是與你的同事坐下來,提出一些更深入的問題。這裡的關鍵詞是“謹慎”。最好的做法是確保問答環節不會演變成一場像西班牙宗教審判一樣殘酷無情的審問。

對歷史愛好者來說,西班牙教士托爾克瑪達在費迪南德二世國王和伊莎貝拉一世女王的幫助下建立。在西班牙宗教審判所時期,許多人在街上圍觀人群面前被活活燒死。實際上,西班牙宗教審判所的作用是為了鞏固新統一的西班牙王國的君主制,但它卻是通過這種臭名昭著的殘忍手段來達到這一目的。

通過問合乎邏輯的問題,你不僅能鞏固自己對問題的理解,而且還允許其他開發人員對錯誤產生自我認識,並以此讓他學會運用正確的自我質詢來改善自己的代碼,他需要在編寫代碼前用這些問題來進行自省。

通過提問,你也表明了你對他的觀點持開放態度。當你的同事感到受到尊重時,他們就不太可能持有防禦性態度。

一旦你找到錯誤和原因,你就有責任在整個團隊中傳播睿智的話語,這樣以後就沒有人再編寫糟糕的代碼了。

3.抑制重寫代碼的本能

美國作家Anthony J. D’Angelo有一句名言說得很中肯:

“不要重新發明輪子,而是去重新調整它。”

編寫高質量的代碼會比編寫前面所提及的糟糕代碼花費更多時間。有時候,更快地“把某樣東西做出來”在商業上是有其意義的。

Kimber Lockhart在一次黑客峰會的演講中曾經說過,開發人員在處理糟糕代碼時所犯的最大錯誤之一就是去重新編寫代碼。大多數情況下,重寫代碼並不能解決糟糕的代碼。因此,在採取這重寫代碼這一步驟之前,不妨先問許多問題:

重寫後的代碼一定會比舊版本更好嗎?

從成本效益的角度來分析,值得付出這樣的精力嗎?

真的是所有的舊代碼都很糟糕嗎,或許我們可以重用很多舊代碼?

等等……

她提出了一個包含三步驟的方法來處理糟糕的代碼。

  • 對代碼進行優先排序。首先需要解決哪一部分問題?我們能保留代碼的其他部分嗎?
  • 封裝處理糟糕的代碼。仍然讓舊代碼保持運行,但通過把它封裝在一個模塊中使其與其他新代碼分離,這意味對於這段代碼除了修復外,其他人不能再對它添磚加瓦。雖然舊代碼仍然可以被調用,但是對它的封裝可以防止糟糕代碼的進一步傳播。
  • 凸顯糟糕的代碼。顯式地標記糟糕的代碼,這樣就沒有人復制這些糟糕的代碼讓問題變得更加複雜。 Lockhart建議刪除糟糕代碼,但是要小心地進行刪除操作。而且建議為了準確識別要刪除的代碼,每週花幾個小時來創建一個自動化系統,這對於系統的長期清理來說是一個很好的實踐。

關鍵是要從最壞的情況中找出其最好的部分,並以緩慢而穩定的方式來消除最壞情況。並不是所有糟糕的代碼都是技術債造成的,如果在這些代碼中也有不錯的部分,我們應該聰明地對之進行合理重用和適應。

4.最後,要謙虛

正如美國作家和演講家Zig Zigler所說的:

“謙卑會比傲慢打開更多的大門。”

總所周知,驕傲導致許多悲劇英雄的墮落。

例如,簡·奧斯汀的名著《傲慢與偏見》中的達西先生在得到伊麗莎白·班納特的愛之前,不得不放下他的傲慢。而但丁把驕傲列為七宗罪之一。

我想大家都同意以上對於驕傲的看法。而與之相對的,謙卑的真正定義是一種安靜的理解,即使你擅長你所做的事情,但你不期望別人過分讚揚你。

所以,如果你已經修正了代碼,也不要讓你的自負對你產生影響。不要得意忘形地向整個團隊發送垃圾郵件。也不要一有機會就站在高處大聲嚷嚷你的成績。

要知道,你也是凡人,不可能毫無紕漏永不失誤。你也可能會寫出糟糕的代碼並陷入同樣的困境,當這種情況發生時,你需要的是每個人的幫助和支持。請永遠不要忘記這一點。

簡而言之,請以開放的心態處理糟糕的代碼,學習,改進,然後你教育其他人去改進。

正如美國作家Roy T. Bennett所說的那樣:

“要去改進,而不是找藉口。要尋求尊重,而不是尋求關注。

作者介紹:

Ravi Rajan,總部位於印度孟買的全球IT項目經理。他還是一位狂熱的博主、俳句詩人、考古學家和歷史狂人。也是一個多產的作家,寫作主題從人工智能到愛情,十分廣泛。

英文原文:

How to Deal with Bad Code.