考量極端案例 (edge case) 是工程師的基本功

先前 Pragmatic Engineer 作者分享的推文，談說當年在學時，在課堂中被要求開發一個 App。而在經過數週的開發，多數組別好不容易完成後，教授在展示當天開始每一組試，然後開始在輸入框輸各種奇耙的字串。

想當然爾，沒有太多開發經驗的學生做的 App，就這樣被教授搞爆。當時學生們抱怨說教授出作業時，沒有提到要處理各種特別字串；但同時也透過這經驗學習到輸入框淨化 (sanitization) 的概念。

從這個例子可以看出，要寫出好維護的程式碼，或者說要寫出「未來的自己，不用替過去的自己擦屁股」的程式碼，在一開始就要把許多面向考量進來。

從生活的例子了解「先想清楚」

在一開始就先做好設計的好處，不只是在撰寫程式上。舉例來說，今年夏天 ExplainThis 團隊成員有短暫回台，在台北碰面時，適逢台北的午後雷陣雨，即使撐傘，上下車時的那幾秒鐘，仍然會被淋成落湯雞。

在台北，目前有一些建築有把雨天的因素考量進來，所以搭 Uber 停到這類建築，讓乘客上下車時，不僅不會被淋到，甚至連傘都不用拿出來。

當有這種體驗時就會想，為什麼不所有建築物都這樣設計? 這樣就完全不會被淋到如此狼狽。

想當然爾，要改沒那麼無容易。

事實上，改實體建築物跟改程式碼有異曲同工之妙，如果要改實體建築，會需要確保在更動時，不會影響到附近的交通，且在改的時候會需要不小時間成本的投入。

寫程式也是一樣，如果前面沒有考慮清楚，就可能導致後面要改的時候，會需要做很多預防措施，來避免影響線上正在運行的程式，以及會需要花許多額外成本下去修改。

以「輸入框」為例

回到寫程式上，一般來說，產品經理寫的產品需求文件，通常不會完整涵蓋所有情境。在寫程式碼時，想到那些應該被覆蓋的情境，是工程師的價值所在之一。以上面提到的輸入框來說，在最開始開發時，就可以去想以下的不同面向。

最基本的

• 信箱空白、密碼空白
• 信箱與密碼的長度限制 (沒處理的話，會有 buffer overflow 的問題)
• 信箱格式驗證錯誤
• 密碼安全性不足
• 輸入框清理 (沒做的話，可能被 XSS 或 SQL injection 攻擊)

更進階的

• 如果信箱已經被註冊，要如何處理 (直接說「該信箱已被註冊」會有資安疑慮)
• 如果客戶端呼叫 API 失敗了，有沒有重試機制?
• 加上限流 (避免被攻擊大量註冊)

小結

希望透過這個貼文內容，讓讀者們對於寫程式時「把各類狀況考量進來」很重要，這個概念有更具體的理解。

假如你對如何寫出更好維護的程式碼感興趣，歡迎加入 E+ ，先前我們有一場《如何寫出乾淨好維護的程式碼？》直播的回放，更詳細探討了這個主題 (點此了解 E+ 的詳細介紹)。