很久沒上來,都快長蜘蛛絲了。為什麼是煮拉麵呢?主題是來自前同事在問我為什麼有人的程式好像常常會歪掉,或是變得難維護,後續的討論中,他用的例子就是拉麵,所以... 今天就用程式來煮拉麵吧!
說真的,要煮出一碗好吃的拉麵,其實超級複雜的,網路上可以找到很多影片,下面是我找了一個蠻完整的影片,從熬製湯頭開始,滷製叉燒,到製麵,最後煮麵到上桌,步驟相當繁複。所以,這次我們只從影片的 13 分 35 秒開始,也就是真的煮一碗拉麵開始。
這次,雖然反而讓我想超久的,但我刻意不加入任何物件的概念,希望都是由 function 來完成這次的例子,另外,我知道可以用 SOLID、DIP 或是很多聽起來很專業的術語,但只要對解釋幫助不大的,我也盡量不用。先從第一個版本開始,我們用 cookRamen
來製作一碗拉麵:
一般來說,剛開始學程式,這樣寫沒什麼問題,甚至在正式工作上,能先用最簡單的方式將「功能」做對,我覺得也可以,醜但是對的程式,比起花俏但錯的程式有用。只是這樣的程式有什麼問題?
這沒有標準答案,全看用什麼角度來看,以我來說,這程式的抽象度不太夠,滿滿的細節,並沒有將 domain term 使用進去 (等等會解釋,如果不是很懂可以先暫時忽略這些術語)。另外,這個 cookRamen
只能煮豚骨拉麵,沒法煮鹽味拉麵、味增拉麵或是魚介拉麵。
假設,先不管美醜,因為需求馬上又進來了,現在希望 cookeRamen
也可以煮鹽味拉麵,加上時間又很趕,於是有人可能選擇,讓 cookRamen
帶個參數,由參數決定煮什麼拉麵,如果是鹽味拉麵,那就是加入鹽醬汁以及雞高湯,完美,不用幾分鐘就改完上線了,因為速度很快,老闆也很開心。
那不是很好嗎?但軟體開發都是這樣的,後面會有越來越多的調整,除了少數只提供一種拉麵的店,大多都提供多種口味,麵的硬度、湯的濃淡都可以調整,像是我蠻喜歡的凪 Nagi,就有五種口味,以及很多可以調整的項目:
另外一個我也蠻喜歡的一幻,有三種口味搭四種湯頭,另外有一個特殊口味只使用雞白湯。
也就是說,如果繼續使用 if-else
或是 switch-case
,即便將參數細化,最後只會讓程式變成一個超恐怖,難以維護的怪物,如果又因為沒時間沒有寫測試案例支撐,之後連修改都會膽顫心驚。
所以,也許打從一開始,我們提供的抽象就是錯的,事實上,這回到一開始我說的,抽象程度不夠,缺少 domain 的 term,如果去問拉麵師傅,或是問拉麵迷,問他們拉麵是怎麼煮的,他們也不會說的這麼細,相反,他們可能會這樣說 (這只是個範例,我不會煮拉麵,只是看了很多漫畫得到的冷知識,想學美食相關的知識,可以看《美味大挑戰》,第 38 集有很多拉麵相關的知識):
- 加熱碗 (冷的碗會讓高湯變冷,喝起來會覺得比較鹹)
- 調製醬汁 (或叫湯底)
- 調製風味油 (決定湯頭風味的關鍵)
- 加入高湯 (濃淡也是在這個步驟調整)
- 煮麵 (時間決定硬度,越硬越地道,最好麵心還有點生)
- 加入煮好的麵跟配料
會發現,這個說法不像我們第一個版本那樣充滿細節,這就是一種抽象,將原本很複雜很細瑣的東西,用更高層次的方式去描述,使事情更容易理解,而抽象化的過程中,就會看到 domain expert 用哪些詞彙描述一件事,而這些詞彙便是 domain term。
因此,我們可以用這些 domain term 改寫 (refactor) 第一個版本的程式碼,得到一個更容易讀的版本:
然後,會發現另一件事,即便是要同時能煮豚骨拉麵、味增拉麵、鹽味拉麵或是魚介拉麵,雖然不同的拉麵在某些步驟裡的細節可能不同,但主流程都是類似的,這時要設計彈性的組合也會覺得便容易了,例如:
到目前為止,透過將流程抽象化,搭配參數,已經讓 cookeRamen
變成一個還不錯的程式,要增加味增拉麵,在不需要改動主流程的情況下,能夠很輕鬆地就完成。
但現實有時候會更加複雜一點,而且雖然能做出豚骨拉麵、醬油拉麵和味增拉麵,非常有彈性,但也有一些問題:
- 程式看不出來這家店有提供什麼拉麵,也可以解讀成,我們仍然是用接近程式的語言在描述問題,而不是接近 domain 的語言在描述問題。
- 如果要限制醬汁與湯頭的組合,例如味增不能搭配雞高湯 (我隨便說說的,這組合應該還是很好吃),似乎在不改動主流程的情況下做不到?
- 為了滿足不同喜好的客人,高湯要能有不同的準備方式,例如兌水降低濃度,或是用 1.5 倍的湯煮成更濃的湯,這是行為上的不同,無法簡單用參數就可以替換。
上述的問題中,第三個相較是比較容易解決的,既然無法用單純的參數,那乾脆就把製作的方式當作參數:
如此一來,我們就可以煮出一碗濃的豚骨拉麵和一碗正常濃度的鹽味拉麵,這裡稍微用了 JavaScript closure 的小技巧,其實用跟不用都可以,只是這裡使用 closure 的用意是,提供一個對 cookRamen
來說,不論之後因為其他原因要改變實作,仍然一致的 function signature:一個沒有參數的 function 。如此一來,cookRamen
永遠只需呼叫 prepareSoup
即可。有人猜出來這是什麼了嗎?
解決了第三個問題,再回頭看第一個問題,以目前第五個版本來說,我覺得已經是相當不錯了,硬要雞蛋裡挑骨頭的話,就是 options
這個字,不太像是廚房裡會用的詞彙,如果真要選一個字,也許 Recipe 食譜會合適一點。
所以只是把 options
換成 recipe
?當然不是,一般來說聽到食譜,會覺得食譜是什麼?指定的食材加上有一定順序的執行步驟,聽起來,好像可以搭配一起解決第二個問題,加入食譜的概念:
在這個版本中,除了 recipe 之外,也加入了 order 的概念,order 就是消費者填寫的那張紙,上面可以選擇口味 (flavor)、醬汁(部分口味可選)、麵的硬度、湯的濃度、配料等等。此外,我們也在程式中可以知道這家店目前提供兩種口味:豚骨拉麵與醬油拉麵,以及這兩種口味各別的食譜,若仔細看食譜會發現,醬油拉麵並沒有加豬背脂,而是在最後配料加完後,淋上滾燙的蔥油,且醬汁跟湯頭都是固定的。
如此,我們在不用 if-else
與 switch-case
的情況下 (個人對 switch-case 的想法可參考《閒談軟體架構:Switch 壞味道》),完成了能夠煮出不同口味、麵的硬度、湯的濃度等各式組合的程式,某種程度上,每個 function 應該都非常易懂,在每個層級上都提供了合適的抽象:
- 將訂單轉成食譜
- 然後
cookRamen
照著食譜煮 - 每個食譜都是用合乎餐廳慣用語的步驟
- 每個步驟則是由可執行的細節組成
要新增一個新口味時,只需要組合既有的步驟即可,不會影響到其他既有的口味。
到這裡為止,我覺得目前的版本算是一個還蠻不錯的寫法。裡面其實用了很多可以拿來說嘴的東西,像是 strategy pattern (大家覺得哪邊是 strategy pattern 呢?),又或者是 dependency injection (這裡使用哪幾種 injection) 等等,但我如果先講 strategy pattern 然後再講怎麼使用在例子中,似乎幫助不大,畢竟光講完 intent、context 等理論,很多人就已經受不了想睡覺了。
反而這次,不斷地用拆解加組合,慢慢一步一步 refactor 的方式,寫出我心目中的樣子,我自己覺得反而更容易解說為什麼要這樣寫,即便沒有剛剛那一段的描述,應該還是可以看得懂怎麼去改善一段程式。
至於所謂資深的工程師是否第一次就要寫出最終版的樣子,我覺得倒未必,視已知的需求而定,但最起碼,要能寫到 v3 的樣子,然後能夠依需求的變化,改寫到 v6 或是更適合新需求的樣子。如果需求就是只煮一種拉麵,花很多時間寫出 v6 其實效益不大,但我個人不會寫出 v1,因為不好讀。切記,只要是有一定複雜度的需求,就沒有一次就寫好的程式,重點是如何隨著需求變化,不斷地改善程式。
好了,時間到這邊也差不多該收尾了,這次雖然用 JavaScript 設計例子,但真的要用 Java 或是語言改寫成由 interface/class 組成的程式也很簡單,有興趣的可以自己試試。最後,煮拉麵的程式不只有一種寫法,上面有六種不同的版本,我相信有其他更好的版本,如果看官覺得你的方式更好,也歡迎來煮碗拉麵並分享吧!
2022/5/16 更新,大概用了半小時,把 Java 的版本寫出來,注意,主要用 interface
、enum
和 record
,盡可能簡潔寫,但行數確實比 JavaScript 的版本多一些。
夜深了,來碗雞白湯拉麵當消夜吧!
系列索引
上一篇:《閒談軟體架構:UUID 之三部曲》
下一篇:《閒談軟體架構:Java virtual thread》