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