最近跟一些年輕的工程師合作，發現系統上線之後 bug 有點多
這當然很正常，不過，如果適度的留意自己的當下的「寫作風格」
其實可以減少很多 bug，或者是可以減少 debug 的時間
這些年工作下來，我發現在開發不同元件的時候，我基本上會在兩種風格中選擇，簡單跟大家分享
嚴格風
在寫一些基礎重要元件、或者呼叫第三方 API 時，我認為把「可能的狀態」通通清楚列出來比較好
也就是像這樣
function doTask($arg1)
{
if ($arg1 === 'val1') {
// ...
} else if ($arg1 === 'val2') {
// ...
} else if ($arg1 === 'val3') {
// ...
} else {
throw new Exception("Impossible state.");
}
}只要出現預期之外的值，就直接丟出例外，這樣可以大幅改善 developer experience
也就是在當下就提醒同事：「我這元件當初設計不是這樣用的，請檢查」
很多人不會把「可能的狀態」寫完，而是放在 else 底下，比如說
function doTask($arg1)
{
if ($arg1 === 'val1') {
// ...
} else if ($arg1 === 'val2') {
// ...
} else {
// handle `val3` here
}
}雖然程式課本都是這樣教的，但實務上這會導致很多可能的 bug
比方說有同事在使用這元件時，參數傳入 val4 結果程式繼續運行
這會導致一些錯誤的理解、讓錯誤的假設在團隊中持續蔓延
所以，在重要的元件，比如金流相關時，採用這種「嚴格風」去寫會比較好
也就是強迫大家搞清楚這個元件的用法，不准許憑感覺隨意呼叫
隨興風
在一些寬鬆的元件，通常是 search 相關的元件、抓資料相關的元件時，可以預期，呼叫方會隨意嘗試各種參數
甚至會有一些參數傳都不傳，覺得元件要有預設才合理
這種元件，就寫得盡量寬鬆、盡量多給預設值，會比較好
也就是呼叫方，參數要傳不傳，都可以，傳錯的時候，就當作是跟沒傳一樣，就用預設值就好
這種元件就是用起來很寬鬆，主要目的是希望不要因為這些小事，讓程式爛掉、故障在那邊
寫起來就是多檢查變數有沒有存在，沒有就給預設值
然後 if else 的時候也比較隨興，基本上不會丟例外，不管怎麼傳都盡量讓你跑
不同的元件，適合採用不同的風格來寫
雖然這是一個主觀的問題，但適當的分辨當下應該採用哪種風格
會讓你的同事非常喜歡跟你工作，覺得你寫的元件「總是很好用」、「用錯的時候都會提醒」、「在不需要拘泥小節的時候，也不會囉唆」
話雖如此，要能知道當下適用的風格，其實需要許多年的經驗累積。
嚴格風、隨興風，只是一個概念，實際上的 coding style 有很多寫法，大家可以慢慢實驗＆嘗試
簡單給個方向，跟大家簡單分享
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式