身為一位認真負責的開發者,總是希望且能盡力寫出優美的程式碼,只是這程式碼在其他開發者眼中,卻有可能是醜陋的程式碼。

若你曾經公開或非公開地訕笑過其他開發者撰寫的程式碼,那麼,不妨試著重構一下過去自己撰寫過的陳年程式碼,在默默嘲笑、感受自己無地自容,或者偶而發現過去竟也能神來一筆的過程中,評斷一下這些日子以來,自己對程式碼美醜標準的演變。

聞自己的程式臭味

要指出別人的缺點總是比較容易,在討論區上,若開始出現「各種神人的code」或者「看過哪些誇張的code」之類的標題,就會引來各路人馬圍觀並提供各式程式碼笑點。

當然,大部份情況下,這只是程式人間的閒聊或工作上的抱怨,不過換個角度來想,能夠看得出笑點,表示對這類程式碼有著一定的瞭解與經驗,也才能夠看得出程式中的謬誤或幼稚之處,只是,誰沒有過去呢?何不把自己多年前的程式碼拿出來重構一下,看是不是還笑得出來呢?

要能夠重構程式,必須能嗅出程式碼的臭味,只是這次是聞的不是別人,而是自己的程式碼臭味,翻出來的程式碼越舊越好,最好是舊到連自己都不記得生過這個程式,然後試著運行、操作一下,回憶當初為什麼要撰寫這程式,接著閱讀程式碼,把自己會沿路訕笑、咒罵的東西記錄下來,你的心中可能會不斷湧現關掉程式碼的衝動,一定要忍住,別忘了,這令人憤怒的程式碼可是自己寫的!

自己的程式到底能有多少臭味呢?

每個程式人在「年紀小」的時候,寫出來的程式碼多半是冗長得難以閱讀,也由於不熟悉程式思考方式,而使得程式中有許多愚笨邏輯,當時因為對語言、程式碼等技術的不熟悉,而寫出了許多錯誤的語法、函式呼叫等。

在閱讀的過程中,有時也會因為要瞭解某條流程的定義,而必須在數個類別的程式碼之間穿梭閱讀,讓自己都快搞不清楚現在身處何方了。

此時,要能說出程式碼美醜的標準就簡單多了,就像那些在討論區上被嘲笑的程式碼一樣,似乎自己該犯的錯誤都犯了,程式中的「可讀性」極差,充斥著完全蠻幹的「演算邏輯」,對「技術的熟悉度」不足,類別的「職責分配」混亂,程式中各元件的「相依性」極高。

而許多文件或書籍,討論關乎程式碼美醜時,差不多也就是這幾個標準,你完全可以確定自己的程式碼是醜的了。

培養程式美感

程式碼的美或醜其實是個綜合指標,隨著開發者程度之提升,對程式碼的美感標準也會有所不同,在程度不足時,太美的程式也會因為無法理解,而看不出其價值。

無論如何,不具可讀性的程式碼絕對稱不上美,《無瑕的程式碼》、《易讀程式之美學》等書,都直接指出了程式碼可讀性的重要性,可與藝術之美比擬。

過於冗長的函式幾乎都能確定其內容難以閱讀,冗長往往造成函式本身命名上的困難,或者是其中的參數、變數等命名上的困難,而幾乎每個談及可讀性的文件或書籍,都會強調正確命名的重要性,在平時撰寫程式時,就應該維持函式的簡短而明瞭,在簡短方面,《無瑕的程式碼》中的建議是「函式的長度不要大於20行」,在明瞭方面的建議是「縮排程度不應該大過一或兩層」、「只做一件事」,也就是「只有一層抽象概念」。

程式中的愚笨邏輯,大概是最常被拿出來在討論區訕笑的對象,我在〈跳入程式屎坑〉中也談過,削減笨邏輯是大量改善程式碼品質的重要方式,然而,開發者在不同時期,也會寫出不同程度的笨邏輯,舉例來說,或許過去對你而言,對null的判斷是理所當然之事,現在的你看到程式碼中充斥大量null判斷,卻可能會感到愚蠢而不耐。

這說明了,要能不寫出笨邏輯,其實是需要經驗與訓練,這可能是來自對大量程式碼的觀摩、各種程式語言語法的模仿或典範學習,事實上,也會來自一個經常被忽略的面向,也就是對資料結構、演算法甚至是數學上的訓練,在《程式之美》中,就將程式的美妙之處,著重在結構、演算法、數學等分析與訓練上,而不是只靠著基礎流程語法來組合蠻幹。

程式碼中展現的技術熟悉度,也表現出程式的美感,例如,過去可能因為不熟悉API而使用兩個List做一對一,現在也許會改用Map;過去使用索引跑迴圈,現在也許會改用for each語法,而處理數列相關的問題時,過去也許撰寫迴圈,現在能使用filter、map、reduce等方法。

必須謹記的是,對技術的熟悉度不應當是賣弄聰明,而故意寫得玄疑難解,Brian Kernighan說過:「除錯難度會是一開始寫程式時的兩倍,因此,如果你在寫程式時盡了力賣弄聰明,根據定義,你的智商會不足以進行除錯」。

自己的爛帳自己還

程式碼的品質該怎麼衡量呢?Thom Holwerda在2008年發表了一幅漫畫〈WTFs/m〉(http://goo.gl/rGF9UN),嘲諷對程式碼品質唯一有意義的評斷指標,就是程式碼審閱時每分鐘WTF的次數。看著別人的程式碼,可以指指點點,說我才不會這麼寫是很簡單的一件事。只是,換做自己來寫的時候,真的是如此嗎?

如果現在審閱的是自己的程式碼,而每分鐘WTF次數太高,那麼就是該還帳的時候了,如果有辦法看出自己的程式碼醜陋之外,也有能力清償自己的債務,也才能真的證明,自己對程式碼美感不單只是嘴砲,也具有建立美感時貨真價實的能力,畢竟若面對自己寫的舊程式,都不肯盡心盡力去重建美感,要能在面對他人程式時認真地面對,我想也是不太可能的事。

實際上,在自己的爛帳自己還的過程中,除了訓練重構能力之夕,也是在重新訓練美感。例如說,將冗長函式化為逐個小函式其實並不難,特別是有強力支援重構的編輯器在手的時候,真正的重構與美感訓練,也就發生在變數、函式的命名,重複演算的提取與重用之時。

最難的,或許是在職責的分配或相依性的隔離。經常發生的事情就是,某個函式搬到B類別重構之後,又重新搬回原類別,接著又發生重構,發現到函式又可放到C類別,這過程有時令人沮喪,但並不愚蠢,而是程式碼被磨練地越來越細膩。

不見得全然都是醜的

一起來看看〈The six months rule〉(http://goo.gl/8MIWUp)這篇短文,大意是說,每個程式人都應該回頭看看自己六個月前的程式碼,並應當對當時的作法感到作噁,如果是這樣,應當感到高興,這代表程式人一直在成長。

六個月的規則我想只是個比喻,這表示開發者偶爾要翻翻自己的舊帳,不要只是會笑別人,最好的方式是也不要怕人笑,現在利用GitHub等管道公開程式碼給大家看,是很好的一個管道,若在某個討論區發現被笑的是自己的程式碼,也應該高興,至少你知道了被笑的原因。

當然,若在評析自己的程式碼美醜時,能發現其實以前某些神來一筆的想法也不錯,那就更值得高興了,這表示過去寫出的不見得全然都是醜陋,而是有些許美感的程式碼了,這時可想想看美感是在哪呢?

這類的程式碼,若有機會重新看一次時,還會覺得美,或是略顯醜陋呢?

屆時覺得醜陋的原因,又是何在呢?

作者簡介


Advertisement

更多 iThome相關內容