Project Template使用前請詳閱公開說明書

前篇「.NET開發者，你應該養成用空白範本寫正式專案」引起不少正反討論。其中有提到到團隊專案範本幾個字，fb討論我留下：「template有好有壞，好的是有規範，壞的是沒有創新與創意。但創新與創意又常常是重構的來源...」這句話，意外得到另一主題回應。我想就團隊專案範本來做另一主題說明，我為什麼會做這樣留言。

---

先看好的一面。

一個團隊，如果已經有能力走到自製專案範本，首先，這個團隊最少有位技術能力不錯的開發者且他有一定技術主導權。這樣他才能引導或指導團隊在團隊範本的使用。

一、提高開發效率

像ASP.NET MVC與ASP.NET Web API等內建範本都是依M-V-C Pattern設計，而使用M-V-C Pattern都會提到習慣取代配置，當整個團隊的習慣一致時，自然而然能提供開發效率。

二、穩定性高

團隊範本通常不會一改在改，整體架構通常事先就經過層層考量，就算改版，相容性通常會處理的不錯。

三、可重用性高

會發展團隊範本有很大一部份是為了重復使用。也就是說，希望每一次的專案不需要都是重新一層一層組織起來，而是開完專案，可能已經完成50%、60%的雛形，除了重新接資料來源(Data Source)之外，它可能是一個已經含CRUD基本功能模組的專案。

四、可維護性高

發展到團隊範本的團隊通常還會配合Coding Style，把習慣取代配置的層級往上提升至程式面。程式面的習慣一致，可以為第一點的開發效率加分不少。並且團隊成員之間的支援成本會低很多。

團隊範本的產生有一定目的，上面四點都是在求快求穩，快的是讓專案在最短時間完成，穩的是單一架構，任何團隊成員都起接手其他人的任務。

---

不好的一面。

重復21次，就會成為習慣。習慣是一種內化的東西，是一種已經沒有經驗值的行為與動作，已經內化到像呼吸一樣自然。用個極端的比喻，如果每天都叫你寫CRUD，就只有CRUD，你會住在一個叫CRUD的舒適圈，當有一天，突然要你離開它時，你會不知所措，因為除了CRUD就只會CRUD。

一、大小通吃

世界上的框架發展百百種，團隊範本也可以是說其中一種客製化框架，不管專案大小，一套通吃，一開始就給你滿滿的火力支援，管你殺雞、殺牛、殺羊通通用大炮打就對了，讓你爽度永遠是100分。

二、團隊規範

團隊範本通常規範會比通用範本(指ASP.NET MVC, ASP.NET Web API, ASP.NET Core等內建範本)嚴僅很多，也就是你能做新嘗試的機會少很多。例如，當團隊經過考量採用Dapper當成團隊範本裡資訊存取層的底層，除非團隊允許(或是介面開的好)，不然你應該很少有機會能抽換為其他ORM Solution(例如，Entity Framework)。

三、規範限制

規範代表一種不希望你做的事，不能犯的錯，一種限制條件，一個圈圈。例如，公司就明文規定，不得用LINQ直接存取資料庫，必須全部透過預儲程序。時間久了慢慢就形成一種不可抵觸的規則。

四、戰爭與和平

一個團隊的向心力最強的時刻是挑戰高難度的工作時。通常，高難度的內容是不易透過一般化範本來決解的。團隊範本的出現，代表戰況已趨向穩定，團隊已摸索出一個模型，將此心中的開發模型實體化的成品。和平時期，是不可能有太空船、原子彈的出現。技術上突破性的發展，從來都不是和平時期的產物。

---

範本的好是提供一個快速且穩定的解決方案。但創新、創意和穩定三詞要混在一起難度就比較高。因為創新或創意都代表一定程度的破壞規則與建立新規則的過程。舉個例子，朋友找我寫購物車，問完需求後我很明白的表示，你去找個開店網站(範本型)即可完成「產品上架與陳列」、「金流」幾個問題都能快速解決，因為就是幾十項產品。相反的，如果你是要發展大型電商(高難度)，一秒幾十萬幾百萬上下，目前我是還沒看過有那個範本有這種能力解決。

我自己也研究及發展過自訂範本，一個穩定的Pattern當然合適範本的發展與使用，相對不穩定的環境，過早發展範本，只是讓選擇更少(也有可能Delay更多)。