我們費了這麼大工夫搞出這麼一個 Boilerplate,要怎麼知道它不是紙上談兵,而是真的可以上線當做商業服務呢?最好的辦法當然就是拿它來實作商業應用!
現階段我正使用這個 Boilerplate 開發自己參與的新創團隊的網站服務 - Caserhub;一位好友目前的新創團隊也採用我們的 Boilerplate 來開發自己的商業應用;另外,我自己最先套用 Boilerplate 的應用是我的個人網站;日後我也打算拿這套 Boilerplate 開發實驗室的形象網站。
在這個應用中,非常著重表單的填寫,還有表單欄位的多元性,因此 Boilerplate 在表單處理上提供的大量彈性根本發揮地淋漓盡致啊!在此案例中,我需要客製化一個深度未知的巢狀 Select 欄位,也需要可以輸入標籤的 Input 欄位,多虧了 Boilerplate 先前規劃好的欄位寫法與架構,讓我可以在短時間內建出這兩種客製化的新欄位,而且很方便地直接使用在表單上。
我的個人網站其實目前是未完工的狀態,目前正在使用 Draft.js 開發 WYSIWYG 編輯器,打算做為個人部落格的發文工具。在這個案例中,我可以全心開發編輯器,而不必煩惱多國語系、後台管理系統等如何撰寫,因為 Boilerplate 都已經幫我完成了。
各位是否注意到,其實這些客製化專案中新增的 Feature 不只是能夠用在自己的專案裡,其實可以淬煉成獨立的模組再塞回 Boilerplate 中,而且這些新 Feature 是經過 Real World 的考驗,提供 Feature 的模組本身已經擁有適度的開發彈性(該有的 props 都有了,該有的 options 也都有了)。
因此從這幾個案例中,我歸納出了 Boilerplate 的生態中其實隱藏著回饋補償機制
。
上游的 Boilerplate 提供基礎設施給下游不同的專案來進行客製化,客製化的過程中會開發出新的好用模組,這些模組為了適應客製化專案的需求而逐漸完善,最終這些好用的模組可以被加回 Boilerplate 中,未來就能提供更好用的 Boilerplate;而當上游的 Boilerplate 發現問題時,也可以透過 Git 的操作把 Patch 下載至下游的專案中。
下游專案把好用模組回饋
給上游 Boilerplate,上游 Boilerplate 也把 Bug 的修正補償
至下游的專案裡,這樣的機制我把它稱做回饋補償機制
,由於它是一個正向的循環,所以我認為 Boilerplate 將會不斷進化,這也是為什麼我一直看好我們的 Boilerplate 的原因。