Modern Web 的技術日新月異,但環境設定越來越繁瑣,組織程式也越來越不易,這對許多人而言,起手一個專案經常會是一個痛點,所以我想在接下來的 30 天裡介紹我的解法——打造一個結構健全、彈性、自動化、容易客製化、內建充足基礎設施(Infrastructure)的 Web 專案樣板。
我選擇 MongoDB、Expressjs、Reactjs、Nodejs 組成 MERN Stack 來實作 Boilerplate,目前已經有正常運作的版本,也有 Demo Site 可以試玩,有興趣的讀者請參考我在 Github 的開源專案 express-react-hmr-boilerplate。
寫程式最忌諱重造輪子,能重複利用的東西最好都重複使用,而我寫了幾年 Web,深覺自己在網站開發上總是在不同專案間來回剪貼大量程式碼(也許此時的你也正在做著一樣的事情),最終,不同的專案裡充滿了大量重複的程式碼,Bug 也隨著複製程式碼散落到不同專案裡,想要維護卻發現束手無策,技術債越積越多...
對於這樣的問題,甚至說是痛點,我認為實作一套半標準化的樣板是一個不錯的解決方案,加上近來 Modern Web 的環境設定越來越複雜,不可能再用複製貼上的方式來管理,因此大約一年前的此時,我開始實作這麼一個 Boilerplate,至今我依然看好它,也覺得它的潛力越來越大,因為它確實解決了我的問題,我認為整體而言它帶給我以下幾個好處:
節省起始一個專案的時間
標準化繁瑣的環境設定
內建常見的功能與模組,也容易因應不同專案的需求進行客製化
程式碼集中在一個專案內維護
搭配 Git 的操作,Clone 至不同專案的 Slave Boilerplate 也能追蹤 Master Boilerplate 的變動,統一解決 Bug,也統一增加 Feature,達到跨專案的程式碼重複使用。
我想談論的是內功,是心法,所以不希望把篇幅耗費在語法教學、工具操作等透過 Google 就可以學來的基本功上面,因此希望讀者們最好已經具備下列能力及知識:
廢話不多說了,咱們就開始ㄅ!
開始 Coding 之前,我整理了 3 個與 Boilerplate 本身程式碼無關的開發哲學,我自己開發時會以這些原則來檢視我的程式碼,在此分享給各位讀者:
言下之意就是,你寫的 Code 不是只有你一個人要用,變數命名請命一個大家看得懂的,能獨立抽出來的模組就抽出來,能共用的就共用,天曉得你的夥伴會不會哪天拿來用。所以身為團隊裡的一份子,產出的 Code 最好兼具可讀性、複用性、可維護性、高效率、可擴充性。
你的專案總有一天要推上線,不會無止境的處在開發階段,而是一個開發、測試、上線的週期,這和在學校寫作業交作業很不同。記得善用 process.env.NODE_ENV
讓你的程式在不同階段表現不同行為,例如 Error stack 只應該在 Development 環境下才顯示、Recaptcha 這種妨礙開發的東西應該要在 Production 時才 Turn on。所以開發 Feature 時,隨時想想這個 Feature 在 Development、Test、Production 三個環境下的表現分別是如何。
產品必須經得起各種奧客的嚴苛測試,要耐得住使用者投機取巧,因此從 Boilerplate 層面開始,就必須要提供健全的 Infrastructure,才足以支撐後面建立在 Boilerplate 之上的不同專案。
真相只有一個,所以同一個值變數不要分兩個變數存,同一個 Data 不要分兩個欄位存,提高程式碼複用性也容易 Debug 降低維護成本。
Boilerplate 本身就是 SSOT 的一個例子,真相是 Master Boilerplate,其他 Slave Boilerplate 都是假的,所以當 Slave 出現 Bug 時,只能修改那單一的來源:Master,再透過 Git 操作把修正 Bug 的更新套用到 Slave。