什麼是好的程式碼?

以前剛接觸程式語言的我，總以為程式越簡短越厲害，覺得複雜的邏輯如果能用少少的幾行代碼表達，就是程式設計裡的大師，然而，隨著經驗的增加，加上閱讀一些軟體工程師的著作，發現這種想法其實很傻也幼稚。”程式越簡短越厲害” 這句話乍看之下或對於個人開發專案似乎沒什麼毛病，不過換到團隊開發專案上就並非如此，儘管程式碼簡短但是團隊成員看不懂就會是一個大問題。

為什麼要有好的程式碼?

先不管一個專案的技術是牽扯到前端、後端或其他，在軟體開發上，一定要了解的是軟體基層架構，就好比如果想建造出一棟好的建築，地基和鋼筋是需要先架設好的。軟體的基層架構會從開出的功能和規格清單開始，先定義出類別、型別、資料、共用函式等前置作業，這項前置作業對越大的專案來說，開發效果越顯著，因為越大的專案在修改、測試、debug 上越花費時間。另外，不論是開發大型專案還是團隊專案，若沒有在一開始說好程式結構和開發規則，容易造成後續專案上維護的困難。

關於程式結構設計的書籍相當多，也有不同派別的主張，耳熟能詳的主要有兩大派別，分別為函式設計 ( Functional programming) 和物件設計導向 ( Object-oriented programming)，而這兩派思維又被人們往下細拆分成多種寫法。多去看看不同的寫法，可以試著去思考為什麼會這樣寫? 又或是為什麼一定要這樣寫? 這些流派的設計並沒有誰對誰錯，也沒有說哪一派就是標竿，並且不同的做法也取決於專案的場景和條件。除次之外，隨著經驗的累積和時間的淬鍊，你也有可能創建自己的寫法派別，亦或是創立出另一種程式語言。

不論是哪一種派別的主張，最終目的都是為了寫出容易維護的軟體，這也就是大家很常在軟體中聽到的 “Clean Code” 一詞想實現的目標。”Clean Code” 一詞最早是被作者 Robert C. Martin 在 ⟪Clean Code⟫ 一書中所提起。Robert C. Martin 認為的 ”Clean Code” 是容易被人閱讀、容易被理解而且修改起來不費力的程式碼。Robert C. Martin 覺得程式設計師就是一位說故事的人，說的故事要能讓人可以清楚了解來龍去脈，他甚至覺得一個好的程式碼是不需要寫註解的，因為適當的命名和良好的程式結構就能說明一切。

建議的書籍

最近剛好看到一本軟體架構師－仙塲大也撰寫的書籍: ⟪這樣寫 CODE 好不好?⟫，頗有感觸，也覺得這本書非常適合想精進自己程式碼的軟體工程師來細細品味，特別是想寫出容易維護程式碼的工程師們。除此之外，這本書主要是集中在物件導向的設計上，所以如果對程式中物件導向設計，和類別設計以及值物件等設計思維想更進一步了解的人，也相當適合仔細咀嚼，從不同角度的思維來欣賞，或許能增添自己在開發的想法上有不一樣的觀點。

值得思考的例子

大部分書中的寫法和理論並非準則，實際使用上需要視使用場景和應用情況來做設計的取捨，舉例來說，在 ⟪這樣寫 CODE 好不好?⟫ 中提到將變數或參數設為不可變的寫法，來防止無法預期的錯誤 (像是特殊值的出現)，在此說法中，強調不要賦予新值到同一個變數上，目的是為了遠離難以察覺的問題發生，但若是想變更其值，就需要額外創建一個新的變數名稱再賦予新值。這個建議的確會讓程式碼更加不容易出錯，不過卻也會有其他需要犧牲的事情: 創建新的變數時需要占用額外的記憶體空間。一般的使用情況來說，這種記憶體佔比不會影響太大，除非是與性能高度相關的資料處理議題，例如需要高速處理大筆資料的情況或是高解析圖像的處理等狀況，這種設計寫法或許就沒那麼適合了。

所以什麼是好的程式碼?

其實何謂 “好的” 程式碼並沒有一定的寫法規則，越簡短的程式碼也並非就是好，而對於是否要將同性質的資料綁成一個類別，又或是要不要創建一個新的變數來接收新賦予的數值等多樣的問題，只能說不同場景狀況需要的結構設計不同，如何找到適當的平衡點是值得思考的議題。雖然沒有一定的規則去固定程式碼的編寫，但是有一項原則可以放在心上: 讓人們容易理解你的程式碼。最後，希望你的程式碼既有自己自由奔放的思考邏輯，也保有軟體維護和修改的彈性。

余談

記得剛邁入軟體領域的自己總想著如果能懂越多相關知識越好，所以比較重視知識的廣度而非深度，在這樣的想法下，接觸了前端、後端、資料庫等多種知識技術，但漸漸地卻發現這種方式對自我的成長其實有些侷限。這並非說接觸不同種類的軟體技術不好，而是要小心當越想快速上手一門技術或語言，就容易忽略了一些背後設計的目的和原理，而這些小細節往往是能通往更上一層樓的鑰匙。