Search
Close this search box.

coder 守則第一條:別浪費時間編「完美代碼」

一般而言,一個系統能用 5 年、10 年,甚至 20 年以上。但是某特定代碼行以及某特定設計則往往比較短:當我們使用了不同的解決方法,其生命週期可能就只有幾個月、幾天,甚至是幾秒种的時間。

  • 有的代碼就是比其他代碼更重要

通過研究代碼如何隨時間變化,資深工程師 Michael Feathers 確定了代碼庫的功率曲線。每個系統都有代碼,通常而言裡面的很多很多代碼,一次寫好之後就永遠不會變了的。但是還是有少量的代碼,包括最重要和最有用的代碼,會被一遍又一遍地改動、重構甚至是重頭開始重寫。

隨著你對系統、問題領域以及架構方法方面經驗的增長,就更加容易知道和預測什麼代碼總是需要改動的,什麼代碼是永遠不會變的:有的代碼就是比其他代碼更重要

  • 我們是否應該寫完美代碼?

我們知道,我們應該寫乾淨的代碼,一致的、易於理解的且越簡單越好的代碼。

有些人因此而走向了一個極端,強迫自己盡可能地編寫美麗優雅趨於完美的代碼,著魔於重構,可著勁兒折騰每一個細節。

有的代碼只需要寫一次,以後就再也不需要作任何變動。但有些代碼則並非如此,試想,這些需要不斷改變的代碼,代碼寫得那麼完美卻在下一秒就立馬被 delete 不就太過浪費了嗎?而且也沒有必要這麼做。

「你不用去寫所謂完美的軟件。不是禁止你,只是真的沒有這個必要。好好想想,接受這個話。你需要明白完美的軟件其實是不存在的。計算機發展到今天還沒有人寫的軟件是完美的。你也不要自以為是地想去做第一個。除非你能接受這個事實,否則你最終只會是在浪費時間和精力,如果你想追求這個不可能實現的夢想。」
—— Andrew Hunt,《The Pragmatic Programmer: from Journeyman to Master》的作者

一次就能解決的代碼也不需要美麗和優雅,只要保證是正確的、容易理解的即可 —— 因為這些不變的代碼可能以後還要被多次讀取。也不必非要是乾淨和緊密的 —— 只需要乾淨即可。複製和粘貼等快捷方式在這類代碼上是被允許的,至少在一定程度上可以這麼做。

這些代碼不需要再重構(除非你需要改變這些代碼),即使它周圍的其他的代碼一直在變化中。總之一句話,這些代碼不值得我們在它身上花費額外的時間。

至於那些一直在變化的代碼?苦苦思索最優雅的解決方案純粹是在浪費時間,因為這段代碼很可能在幾天或者幾週後就會被改寫,甚至重寫。

所以我們要關注的重點是:這些代碼是否如願運行 —— 是否正確、實用和高效?是否能處理異常數據而不崩潰?—— 或者至少是否能做到即使失敗也不會出問題?是否容易調試?是否能簡單安全地改變?

這些實實在在的措施才是成功與失敗之間的分水嶺。

延伸閱讀:神級 Coder 絕不犯的錯誤:為炫耀編出超短碼

  • 編碼與重構要務實

精益開發的核心思想是:不要浪費時間去做那些不重要的事情,包括寫代碼、重構、代碼審查以及代碼測試等多個方面。

只需要重構真正需要的部分就足夠了 —— 這也被 Martin Fowler 稱之為是機會主義的重構和有準備的重構。

關於代碼審查也只需要專注於重要部分。這些代碼是否正確?是否安全?是否可以運行?

不要在意風格(除非風格本身妨礙了我們的理解)。讓 IDE 做主,格式化的照顧就 ok 了。我們不必去討論代碼還能不能更 OO,也不必一定要遵循某種樣式,喜歡與否也沒有關係,是否能用更好的方式解決也不重要——除非是你在教新手,並且需要做一些指導作為代碼審查的一部分。

測試也要挑關鍵的來。測試要覆蓋主要途徑和重要的異常情況。無論是大型測試還是小而集中的測試,無論是寫在代碼之前還是之後,只要能起到作用就成。

  • 這不僅僅是代碼問題

軟件開發總是在不斷地更新迭代。哪怕現在看它的設計和代碼是正確的,但是一段時間之後,它就會被要求改變或者直接被其他更好的所替代。

我們需要編寫優良的代碼:易於理解、正確以及安全。我們在重構和審查代碼、編寫有用的測試的同時也需要謹記:有些代碼或者甚至是所有的這些代碼,在不久的將來是要被拋​​棄的,或者永遠也不會再被讀取,或者再也不會被使用了。我們必須意識到,我們現在的一些工作將會成為無用功。做需要做的事情,僅此就夠了。不要浪費時間去寫所謂的完美代碼。

譯文鏈接:http://www.codeceo.com/article/do-not-weste-time-perfect-code.html
英文原文:Don’t Waste Time Writing Perfect Code
翻譯作者:碼農網  –小峰

(轉載自合作夥伴《碼農網》;未經授權,不得轉載;圖片來源:Yuri Yu. Samoilov,CC Licensed)