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

先前 Pragmatic Engineer 作者分享的推文，谈说当年在学时，在课堂中被要求开发一个 App。而在经过数周的开发，多数组别好不容易完成后，教授在展示当天开始每一组试，然后开始在输入框输各种奇耙的字串。

想当然尔，没有太多开发经验的学生做的 App，就这样被教授搞爆。当时学生们抱怨说教授出作业时，没有提到要处理各种特别字串；但同时也透过这经验学习到输入框净化 (sanitization) 的概念。

从这个例子可以看出，要写出好维护的程式码，或者说要写出「未来的自己，不用替过去的自己擦屁股」的程式码，在一开始就要把许多面向考量进来。

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

在一开始就先做好设计的好处，不只是在撰写程式上。举例来说，今年夏天 ExplainThis 团队成员有短暂回台，在台北碰面时，适逢台北的午后雷阵雨，即使撑伞，上下车时的那几秒钟，仍然会被淋成落汤鸡。

在台北，目前有一些建筑有把雨天的因素考量进来，所以搭 Uber 停到这类建筑，让乘客上下车时，不仅不会被淋到，甚至连伞都不用拿出来。

当有这种体验时就会想，为什么不所有建筑物都这样设计? 这样就完全不会被淋到如此狼狈。

想当然尔，要改没那么无容易。

事实上，改实体建筑物跟改程式码有异曲同工之妙，如果要改实体建筑，会需要确保在更动时，不会影响到附近的交通，且在改的时候会需要不小时间成本的投入。

写程式也是一样，如果前面没有考虑清楚，就可能导致后面要改的时候，会需要做很多预防措施，来避免影响线上正在运行的程式，以及会需要花许多额外成本下去修改。

以「输入框」为例

回到写程式上，一般来说，产品经理写的产品需求文件，通常不会完整涵盖所有情境。在写程式码时，想到那些应该被覆盖的情境，是工程师的价值所在之一。以上面提到的输入框来说，在最开始开发时，就可以去想以下的不同面向。

最基本的

• 信箱空白、密码空白
• 信箱与密码的长度限制 (没处理的话，会有 buffer overflow 的问题)
• 信箱格式验证错误
• 密码安全性不足
• 输入框清理 (没做的话，可能被 XSS 或 SQL injection 攻击)

更进阶的

• 如果信箱已经被注册，要如何处理 (直接说「该信箱已被注册」会有资安疑虑)
• 如果客户端呼叫 API 失败了，有没有重试机制?
• 加上限流 (避免被攻击大量注册)

小结

希望透过这个贴文内容，让读者们对于写程式时「把各类状况考量进来」很重要，这个概念有更具体的理解。

假如你对如何写出更好维护的程式码感兴趣，欢迎加入 E+ ，先前我们有一场《如何写出干净好维护的程式码？》直播的回放，更详细探讨了这个主题 (点此了解 E+ 的详细介绍)。