嗨~ 歡迎閱讀本期的全端雙週報。先前在 E+ 的《如何寫出乾淨好維護的程式碼?》直播當中 (連結),我們談到一個不少參與者提到學習很多的概念,那就是想要寫出好維護的程式碼,需要考量夠全面
當時我們舉了 Pragmatic Engineer 作者分享的推文,談說當年在學時,在課堂中被要求開發一個物流相關的 App。而在經過數週的開發,多數組別好不容易完成後,教授在展示當天開始每一組試,然後開始在輸入框輸各種奇耙的字串。
想當然爾,沒有太多開發經驗的學生做的 App,就這樣被教授搞爆。當時學生們抱怨說教授出作業時,沒有提到要處理各種特別字串;但同時也透過這經驗學習到輸入框淨化 (sanitization) 的概念。
從這個例子可以看出,要寫出好維護的程式碼,或者說要寫出「未來的自己,不用替過去的自己擦屁股」的程式碼,在一開始就要把許多面向考量進來。
從生活的例子了解「先想清楚」
在一開始就先做好設計的好處,不只是在撰寫程式上。舉例來說,今年夏天 ExplainThis 團隊成員有短暫回台,在台北碰面時,適逢台北的午後雷陣雨。上週台北的雨狂暴到,即使撐傘,上下車時的那幾秒鐘,仍然會被淋成落湯雞。
在台北,目前有一些建築有把雨天的因素考量進來,所以搭 Uber 停到這類建築,讓我們上下車時,不僅不會被淋到,甚至連傘都不用拿出來。
當有這種體驗時就會想,為什麼不所有建築物都這樣設計? 這樣就完全不會被淋到如此狼狽。想當然爾,要改沒那麼無容易。事實上,改實體建築物跟改程式碼有異曲同工之妙,如果要改實體建築,會需要確保在更動時,不會影響到附近的交通,且在改的時候會需要不小時間成本的投入。
寫程式也是一樣,如果前面沒有考慮清楚,就可能導致後面要改的時候,會需要做很多預防措施,來避免影響線上正在運行的程式,以及會需要花許多額外成本下去修改。
以「輸入框」為例
回到寫程式上,一般來說,產品經理寫的產品需求文件,通常不會完整涵蓋所有情境。在寫程式碼時,想到那些應該被覆蓋的情境,是工程師的價值所在之一。以上面提到的輸入框來說,在最開始開發時,就可以去想以下的不同面向。
最基本的
信箱空白、密碼空白
信箱與密碼的長度限制 (沒處理的話,會有 buffer overflow 的問題)
信箱格式驗證錯誤
密碼安全性不足
輸入框清理 (沒做的話,可能被 XSS 或 SQL injection 攻擊)
更進階的
如果信箱已經被註冊,要如何處理 (直接說「該信箱已被註冊」會有資安疑慮)
如果客戶端呼叫 API 失敗了,有沒有重試機制?
加上限流 (避免被攻擊大量註冊)
小結
希望透過這期的雙週報內容,讓讀者們對於寫程式時「事先把許多面向考量進來」,這個概念有更具體的理解。假如你對如何寫出更好維護的程式碼感興趣,歡迎加入 E+ 看先前的《如何寫出乾淨好維護的程式碼?》直播回放 (點此了解 E+ 的詳細介紹)。
[本期推薦]
前後端工程師都推薦參加的 WebConf Taiwan 在 12 月將舉辦 2024 年的場次,今年 ExplainThis 團隊也會擔任講者。對於技術交流有興趣的讀者,在 10/17 (四) 中午開始可以報名 (連結)。去年一開放就被報名完,推薦讀者可以先把這時間放在行事曆上。
談到技術會議,ViteConf 的直播回放 (連結) 陸續釋出,推薦對前端工具鏈感興趣的讀者,沒跟上直播的話可以看回放。如果對 Vite 還不熟,可以看先前我們寫過的這篇介紹文 (連結)
最近重讀了 Google 首席工程師 Jaana Dogan 多年前寫的《Things I Wished More Developers Knew About Databases》,還是覺得非常經典,推薦大家溫習 (連結)
在 Visual Copilot 與 v0 等生成式 UI 工具被推出一陣子後,最近社群有一個討論度更高的生成式 UI 工具 Bolt,不僅讓你透過自然語言生成 UI,還直接整合到雲端開發環境,非常厲害 (連結)
Gumroad 創辦人先前在《Why Gumroad Didn't Choose htmx》一文中,提到他們在新產品沒有選用 htmx 的理由,推薦對於思考新產品技術選擇的人一讀 (連結)
OpenAI 最近推出了 ChatGPT Canvas,我們實際用過後,有種在用寫作版本的 Cursor 的感覺,比起過往的 ChatGPT,使用體驗提升不少。談到 AI 工具,前陣子 Google 推出的 NotebookLM Audio Overview,被視為 Google 近期難得推出的好產品,還不知道的人推薦看這篇介紹 (連結)。此外,近期 Anthropic 的執行長寫了一篇,《Machines of Loving Grace》談了他對 AI 發展的願景,以及未來世界可能會有的變化,雖然很長,但非常推薦一讀 (連結)
提到 AI,先前 Dan Shipper 寫了《Why Generalists Own the Future》一文,談到通用型人才在 AI 時代的利基點,對於開發者來說也很受用 (連結)
Paul Graham 先前曾發過一則推文,提到說談到他花很多時間才終於理解,很多時候大家尋求的不是解答,而是尋求有人能夠同理自己,這是工程師在與他人溝通時,很常會有的問題 (連結)