掌握 5 個基本概念,讓你寫出好 Code

評論
評論

code and coding(Photo Credit: Luis Llerena)

原文為《Writing good code: how to reduce the cognitive load of your code》,作者為軟體開發自由工作者 Christian Maioli Mackeprang。Inside 獲授權編譯。

Bug 少、表現好、易於更改。好的程式碼影響深遠,而且大概是大家公認高效率開發者背後的重要因素之一。儘管如此,新手還是很難理解什麼是好的程式碼,大部分的相關文章會有整理很多沒有前後因果的小秘訣,但新手開發者怎麼可能全部背起來?比如說,光是這本程式領域的經典《軟體建構之道》(Code Complete),就有 960 頁這麼厚。

我相信能建立一種心態架構,是能超越任何語言和函式庫,讓人一開始就能產生好的程式碼。這裡提出 5 點概念,記住這些原則,寫出好的程式碼將非難事。

1. 避免特立獨行的程式碼

當你看到文章談到新技巧,瞬間驚為天人,一定忍不住就想用來寫些聰明的程式碼來讓你的同事眼睛一亮。

問題是,其他人其實只想把 bug 修好,然後繼續處理其他事。所謂的聰明小技巧只會讓人分心。就像我在「Applying neuroscience to software development」一文所說,當人們需要消化你寫的那段程式碼,他們腦袋裡的 stack 堆疊就會塞爆,而變得難以運作。

lJxlWBW▲如果需要你來解釋才能懂,就不要把程式碼弄得太有個性

別用「你自己的流派」寫程式,照標準來寫就好。這些東西都已經有標準做法了,照大家習慣的方式來寫,能讓你的程式盡量好預測又好讀。

2. Divide and Conquer

複雜的程式碼通常能利用模組化技巧來整理,而且除了創造更多函式以外,還有很多方法可以達成。把一項長條件的結果放在一兩個變數內,就是取代呼叫函式 overhead 系統開銷的模組化方法之一。這樣一來還能用它們組成更大的條件式,或是在其他地方重複使用這些結果。

這個拆解問題的方法,要盡量讓每個部分保持集中,影響範圍只留在本地狀態,不要混進其他不相干的 issue,可能的話盡量避免副作用。程式語言和函式庫通常都帶有各自的 issue,把這層影響抽掉能夠讓你的程式碼專注在自己的工作上。「單一責任原則」也是在強調,專注在本地程式碼可以產生好的設計。

zXwGnO4▲我喜歡利用變數來釐清邏輯

TDD (測試驅動開發) 除了成功實行帶來的好處以外,還強迫大家採用一些之前沒那麼熱門的準則。之前無狀態的程式碼被嫌棄又慢又沒必要(看看大部分的舊 C 或 C++ 程式),而現在大家都在談純函式(pure function)。就算你沒在用 TDD ,也該瞭解一下背後的原則。在新的規範下工作能讓你成為更堅韌的開發者。

3. 分散且可行

寫程式的時候,電腦和工具面對的困難跟程式設計師差不多,而程式愈複雜,要使用的前端處理程式和變體(Mutation)就愈多。

先不說額外建置工具的優點,它們有很高的機率會要你用像自訂模板或雜湊表格之類的複雜動態資料架構等等限定範圍的語言。整合開發環境(IDE)通常在這方面的表現都不太好,要找到相關的程式片段就會更加困難。

避免使用你的 IDE 支援度低的擴充和程式,它們帶來的衝擊,遠遠超過簡化架構或節省幾行程式這些微不足道的好處。

hyNFKuw▲使用 ServiceLocator 也是和 IDE 整合不佳的例子之一

另一個保持 IDE 整合度的重點是避免使用 magic code。大部分的語言都會提供一些方法讓你寫出更動態的程式,但濫用這些像是魔術字串(magic string)、魔術陣列索引(magic array index)和自訂模板語言等功能,會產生一個更難連結的 codebase。

通常只有人類才看得懂的程式碼,就會讓你走上這條難以回頭的路,因為如果你的 IDE 看不懂這些程式碼,那當你想要換到更靜態的架構時,它所有的重構(refactoring)功能都沒用了。

4. 讓程式更好讀

建立一個可預期的架構。這樣一來團隊成員能更容易地找到東西,而大幅減少完成工作的時間。 當你定好整體架構,記得讓主要元素的位置保持顯眼。 比如用 MVC 就把模型(model)、視圖(view)和控制器(controller)放在各自的資料夾裡,不要藏在層層路徑下或是分散在各個不同的地方。

前面談到了模組化,過猶不及也可能發生過度模組化的情形,讓人更難找到程式碼。IDE 有時候幫得上忙,不過通常會因為有太多不相干的程式碼,你還得讓 IDE 忽略 vendor/library 資料夾,或編入指引,手動處理這些問題。這是雙輸的局面,因此盡量試著選擇符合最多需求的函式庫,減少函式庫的數量。

函式庫和工具也可能成為新開發者的阻礙,我最近就用 EcmaScript 7 (bable) 建置新專案,隨後卻發現開發的新人卡在那裡,試著弄懂這些程式碼的意思。這大大地拖累了團隊的生產力,我也能了解對新手來說這壓力有多大。不要使用太難上手的工具,除非你碰到更好的時機。

1rkblTg▲這是我寫的 makefile 的部分程式碼。而新人無法處理過多的新技術。

5. 讓程式更好消化

如果你終於讀到這裡,恭喜你,這可能是最重要的一段。命名在軟體開發中是公認的大哉問。建置工具大概不會在這上面有所改進了,因為電腦不會懂某個解背後的意義。 你得親自記下原因,為變數及函式取個有關聯且有包含前後文的名字會是不錯的方法。 能夠傳達用途的名字甚至還能減少所需的紀錄文件。

直接把意義加在名字前方是個好方法,以前曾經很流行,我想它逐漸消失的原因應該是太常被誤用。比如 匈牙利命名法 原本是為了附加意義,但最後常失去前後脈絡,變成只有表達類型之類的資訊。

yNBTr4A▲流暢介面 (fluent interface) 最近常被濫用

最後就是降低迴圈的老生常談。意思是讓條件的分支(branch)愈少愈好,每多一條分支不只會增加縮排,也會影響易讀性,而且最重要的是會增加需要追蹤的項目。

結論和推薦閱讀

以上就是 5 點簡單又包羅萬象的概念,這篇文章的目的就是給你一些收納箱,可以讓你把管理程式碼的想法放進去。

在寫程式的時候,練習應用並進一步加強這些觀念。 如果你還沒開始,我也相當推薦《軟體建構之道》這本書,裡面有很多範例,並且詳細剖析了絕大部分的狀況。

 

相關文章

評論