Day27 - 我們需要乾淨的 code

乾淨，這個詞可以代表的事情太多。
套用在寫扣上，會直覺聯想到「簡潔的、寥寥數行的 code」。
但是乾淨這個詞，是不是也可以套用在「容易閱讀的、容易維護的」code 上呢？
我覺得也是可以的。
那問題來了，簡潔跟易讀、易維護，這兩個目標會不會有衝突？

前一陣子，我看了原子能在 Youtube 上這部「我們需要更愚蠢的代碼」，我深思了很久。
影片中提到的 Regex (正則表達式) 絕對是工程師心中永遠的痛。
它足夠簡潔，但絕對不是什麼易讀、易維護的東西。
我們用 date format 來做個範例：

用 Regex 的寫法
const input = "2025-08-30"
const output = input.replace(/(\d{4})-(\d{2})-(\d{2})/, "$1/$2/$3")

console.log(output) // 2025/08/30

不用 Regex 的寫法
function formatDate(dateStr) {
  const parts = dateStr.split("-")   // ["2025", "08", "30"]
  const year = parts[0]
  const month = parts[1]
  const day = parts[2]
  return `${year}/${month}/${day}`
}

const input = "2025-08-30"
console.log(formatDate(input)) // 2025/08/30

可以看到 Regex 的寫法輕輕鬆鬆一行就把日期格式做了轉換。
用了 split 的用法則足足多了好幾行。
論起簡潔，Regex 那個方法確實相當簡潔，但有多少人能在不查表的情況下翻譯出 /(\d{4})-(\d{2})-(\d{2})/ 這段正則表達式呢？
顯而易見的，它的易讀性是遠遠不及後者的。

那陣子我深受這部影片影響，甚至隱隱有想要提議把專案裡的 Regex 都換成更易讀但也更冗長的寫法，因為我覺得 Regex 真的太難讀了。
於是我在某次公司慣例所有前端都要出席的會議上向大家詢問了對使用 Regex 的看法，意圖知道大家對於「簡潔」與「易讀」的取捨。
有趣的是，公司的 Senior 們清一色支持寫 Regex，但前提是必須以 function 包裹 Regex，並且 function 名稱要能清楚表達這個 Regex 的用途。
最重要的一點是：測試必須做好做滿。

我後來思考了一下，總算理解 Senior 為何這麼強調那兩個前提。
透過 Regex 撰寫邏輯保持了簡潔，這是無庸置疑的。
但包進 function 後，function 名稱就能表達這個 Regex 的用途，這樣就能大幅提升使用時的易讀性。
而測試寫好寫滿，如同我之前寫的測試那篇文，也是在確定 Regex 的功能以及提高維護性。
對 Senior 來講，它們這操作就是完滿平衡了「簡潔」與「易讀、易維護」這兩個目標。

簡潔 + 易讀 = 乾淨

其實實務上很多方式都是兼具簡潔與易讀的。
比如重複性結構我們會抽成 component，讓它可以複用進而縮短 code 以及提高易讀與易維護性。
抽變數、抽 function 也是類似的邏輯。
但終歸，簡潔與易讀總有背道而馳的時候，就如上面 Regex 的討論一般。

我覺得工程師需要乾淨的扣沒錯。
但這個乾淨應該是指在「簡潔」與「易讀、易維護」之間取得平衡的乾淨。
就如同我們公司當初 Senior 在會議上針對 Regex 提出的論點一樣。
這種平衡的極致，我覺得已經可以算是 coding 的藝術。

其它 murmur

其實這篇一開始是想講說，做 code review 時有時會看到 Junior 把 code 通通黏在一起，那樣實在很難分出哪一段是什麼功能。
所以想提醒大家寫 code 時其實可以好好地為 code 的順序排個序 & 分個段。
以 Vue 舉例，我就會希望你 template 裡的內容是可以按照 UI 的結構用空行做個分段；script 的部分可以按照一般變數、ref、computed、methods 的順序排序，並適時以空行分段。
這對於跟你一起工作的人來說，都是讓它提高對你印象的時候，因為有好好分組、分段的 code 的可讀性真的比通通黏在一起的好太多了。

本來這篇是想講上面這件事的，但一開始打字就想到 Regex 的議題，想想也是跟 coding style 有關的東西，於是就這樣洋洋灑灑地寫下去了 XD

簡潔 + 易讀 = 乾淨​

其它 murmur​

簡潔 + 易讀 = 乾淨

其它 murmur