網頁

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

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更多)。

沒有留言:

張貼留言

感謝您的留言,如果我的文章你喜歡或對你有幫助,按個「讚」或「分享」它,我會很高興的。