架構設計好簡單系列 設計符合團隊的範本精靈 (Project template)

Gelis Wu

架構設計好簡單系列 - 設計符合團隊的範本精靈 (Project Templates)

Gelis 的程式設計訓練營

關於我• 連續五屆微軟最有價值專家 MVP (2011~2015)• 集英信誠資深 .NET 開發顧問• 部落客，點部落 (Gelis 技術隨筆 )• 在 2000 年早期致力於 Win32 底層 COM+ 與分散式應用的開發， 2002 年開始轉戰 .NET 平台，現在則致力於 VSTS 、軟體開發生命週期中， CI(Continuous Integration) 與 CD

(Continuous Delivery) 等應用• 熟悉 C# 、 ASP.NET 、 MVC 、 Web 平台技術開發、與各項微軟開發的 Solution ，架構設計、 UML 塑模化設計、 MDA 、與 OOAD 系統分析與設計、等

經歷• twMVC 社群講師• Study.4 社群講師• 企業 Visual Studio 2013/C# 課程講師• 企業 IIS 7.5/8.0/8.5 訓練講師

講授過課程• [.NET Framework 技術架構發展與 C# 6.0]• [ASP.NET MVC 6 新功能初探 ]• [ASP.NET 5 新功能與未來變革 ]• [.NET 技術研討 (LINQ 與架構開發 )]• [ASP.NET MVC 4 RC 新增功能介紹 ]• [ASP.NET MVC 4 Web API 開發簡介 ]• [ASP.NET MVC 4 Web API 全攻略 ]• [ASP.NET MVC 4 新增功能介紹 ]• [ASP.NET MVC 基礎 ]• [C#4.0 LINQ 與泛型應用 ( 簡介與開發 )]• [HTML5 課程 ]• [IIS 7.0 應用程式開發實務 ]• [Visual Studio 2010 UML]• [Visual Studio 2012 與 ASP.NET 4.5 ( 新功能與開發介紹 )]• [Visual Studio 2013 新功能介紹 ]• [ 如何培養架構性思考 ( 談軟體架構師必經之路 )]• [ 如何將現有 ASP.NET Web Form 網站轉為 ASP.NET MVC]

• 談談軟體開發這件事情• 近代軟體工程學，與軟體開發生命週期的管理• 軟體開發中的各個階段• 如何做好品質把關？從團隊，到個人• 關於為什麼要做範本精靈？• 建立團隊開發的共同規範 - Coding Standard (Programming Rule)

• 談原始碼管控的重要性• Visual Studio Project Template 概念• Project Template vs. NuGet Package?• 如何開始？開發流程？標準？導入？團隊如何進行？• 實作練習：開始設計我們的第一個 Project Template• 實作練習：如何在 Project Template 中呼叫範本精靈

Agenda

• 從軟體開發團隊談起

一個軟體專案裡面有什麼要素？

想賺多一點錢，改行做軟體就對了？

• 第 1 名：軟體工程師• 第 2 名：電子工程師• 第 3 名：大數據分析師• 第 4 名：金融理財專員• 第 5 名：企劃開發人員• 第 6 名：業務人員• 第 7 名：公務人員• ….

公務員出局！ 跳槽夢幻行業軟體工程師排第一

因為軟體工程師工作起薪高、未來發展性佳？

而成為網友最佳的轉職選擇？這麼容易轉職？

那麼這兩個新聞放在一起，好像有點諷刺… .

第一件事，工程師都在做什麼？第二件事，媒體宣揚的好處不過是種迷思第三件事，你對寫程式真的有愛嗎？

• 發展性與賺多少錢與軟體開發似乎沒有直接關係• 軟體開發也不是只有寫程式而已

所以…

所以我想，想要轉職的那些人應該是誤會了…

• 在專案開發的領域裡，有許多循環不能與技術能力畫上等號 !!

因為，開發技術強，不代表你會賺大錢

優秀的程式設計師養成不容易

• 同業競爭• 年紀競爭• 技術汰換• 價格競爭• 大環境改變• …

還要面對市場競爭

現在慢慢進入一個人人都會寫程式的年代

• 我們必須反覆的思考，我們與其它的競爭者有何不同？因此…

我們洞悉市場需求，因為我們比別人還知道客戶真正想要的是什麼？我們充分發揮經驗優勢我們了解市場趨勢，不至於被淘汰所以我們賺的錢比別人還多？

專案 ( 軟體 )開發寫程式

所以…

專案 ( 軟體 )開發賺很多

• 不知從什麼時開始，我們讓客戶以為，專案開發只是寫程式就好？• 專案開發裡面，有許多與寫程式沒有直接相關，但必須處裡、協調的事情

而且 .. 不知從什麼時候開始…

• 軟體開發從 1968 年的 [北大西洋公約組織(North Atlantic Treaty Organization, NATO) 的學術會議中提出了軟體工程這個名詞來界定，軟體開發是一種類似於工程的活動

• 因為，其中牽涉到不少流程、工法，還有使用的工具、平台、作業系統、執行環境的不同，而在開發流程上隨即稍有不同• 系統分析設計開始，也有許多不同的方法論

(UML 、 OOAD 等 ) ，這之間牽涉到的的領域知識極廣

其實 .. 軟體開發是一個複雜的工藝過程

• 實際的運作會發現，你除了需要訪談、蒐集需求、系統分析、系統設計、系統測試、佈署、上線、維運、改版、更新、修復 Bug 、反饋… 等等

技術顧問的專業是什麼？

喬丹• 即使是上籃這個看似簡單的動作，我到現在還是每天練習

軟體開發中的各個階段Phase of software developments

需求 反饋維運佈署測試

設計編程

建置VALUES AND PROCESS FLOW

EXTERNAL ENVIRONMENT

BUSINESS EXCELLENCE LIFECYCLE

UNIVERSAL BUSINESS EXCELLENCE

• 需求• 設計• 編程• 建置• 測試• 佈署• 維運• 反饋

在軟體開發循環中，我們應該做的有 ..

CICD DevOps

CI - Continuous IntegrationCD - Continuous Delivery

• 需求• 設計• 編程• 建置• 測試• 佈署• 維運• 反饋

•蒐集、管理需求• 面對需求變更•記錄需求• 團隊與客戶間能夠溝通需求•並且提高專案透明度• 而贏得客戶對我們的信任

• 需求• 設計• 編程• 建置• 測試• 佈署• 維運• 反饋

• 必須提高軟體的重用性！降低開發成本！• 必須提高軟體系統的延展性！• 設計高可用性的系統／網站架構？• 能夠確保開發人員遵循架構來進行開發• 適當的分層並降低相依性

• 需求• 設計• 編程• 建置• 測試• 佈署• 維運• 反饋

• 透過以下保障程式碼品質• Unit Test• Code Review• 讓開發人員撰寫風格一致的程式碼• 讓程式碼便於交接、維護、與重用

• 需求• 設計• 編程• 建置• 測試• 佈署• 維運• 反饋

• 必須實現自動化建置• VSTS • (Daily/Schedule) Build• Check-In source to Auto Build• Build with Auto Unit Test• Build with Auto Code Review

• 需求• 設計• 編程• 建置• 測試• 佈署• 維運• 反饋

• Unit Test• Test Case• Load Test (負載測試 )• SIT• UAT• 回歸測試

• 需求• 設計• 編程• 建置• 測試• 佈署• 維運• 反饋

• 上版方式？調整上版流程進行的方式• 如果可以，導入自動化上版• 建立候選版本機制• 不間斷服務進行上版的方式？• 希望做到讓有權限者單鍵發佈

• 需求• 設計• 編程• 建置• 測試• 佈署• 維運• 反饋

• 如果可以， Ap Server 最好有附載平衡• 如果可以， Ap Server 最好導入 Fail-

Over• 壓力測試進行方式、腳本？• 實現 Auto Scale ，面對未來成長量• 如何面對 DDOS

• 需求• 設計• 編程• 建置• 測試• 佈署• 維運• 反饋

• 蒐集客戶 Feedback• 控管客戶的每一個 Feedback ？讓客戶的

Feedback 有效被管理？• 將 Feedback 轉入 TFS／ VSTS (VSO) 與開發工作 Work Item 相連結• 得知每一個 Feedback 做了那些程式碼修改？• 管理 Feedback 與 Test Case 間的關係？

與軟體開發生命週期的管理近代軟體工程學

以前，我們所知道的軟體開發 ..

• 瀑布式• 漸進式• RUP

軟體開發發展出來的模型

• 瀑布式• 漸進式• RUP

軟體開發發展出來的模型

• 瀑布式• 漸進式• RUP

軟體開發發展出來的模型

• 以前，我們可能半年、三個月交付一次版本• 以前，我們可能會跟客戶說：您的需求從今天開始凍結，直到我們把這一版交付出來為止• 現在，我們可能兩個禮拜就得交付一個可用的版本• Visual Studio 都從兩年交付一版變成一年交付一版

• 因為，我們不可能凍結需求• 因為，我們不能抗拒市場的變化一樣

我們的團隊會導入 Scrum

藉由 Scrum 我們可以做到？

Agile, Scrum近代軟體開發流程

我們使用 (Agile/Scrum)

I

SCRUM PROCESS

SCRUM ROLES

Product owner

Scrum master

Team members

StakeholdersUsers

Release

PREPARATION

SCRUM PROCESS

•需求 & User Story•Acceptnace Criteria•Initial productbacklog•Architecture Design•Initial release plan•Stakeholders Benefit

針對反饋立即調整並隨時修正每兩周交付成果

符合客戶真正需求的產出高專案透明度

持續蒐集客戶需求與反饋基於企業及開發框架與架構

• 個人與互動 重於 流程與工具：• 避免資訊的錯誤，浪費溝通的時間

• 可用的軟體 重於 詳盡的文件：• 若詳盡的文件就是可用的軟體，可避免維護兩個地方，且文件就是運作結果本身。

• 與客戶合作 重於 合約協商：• 客戶才是需求的本身，與客戶合作將更接近目標，不會花錯力氣

• 回應變化 重於 遵循計劃：• 唯一不變的就是變，計畫趕不上變化，如果只是不知變通的依計劃進行，往往知道方向錯了已來不及

你得清楚『敏捷宣言』…

ALM 的導入要從 Version Control 開始

除了 Scrum..

現在，我們也在談論 DevOps…

• DevOps( 英文 Development和 Operations 的組合 )• 它不是解決方法！• 它根本沒有任何規範，更沒有描述任何解題的步驟，因此絕對不是一種方法 )

• 作到 DevOps ，是一串繁複的過程，你要先打通層層的關卡，但真正難的是持續維護的作業• 它牽扯到的是企業的文化，這是是一種文化層面的東西，所以必須由改善企業文化來解決問題• 豐田企業 Toyota 的選擇直接改善人們的行為方式，來形成一種團隊的責任精神，用責任文化來改善企業文化• 發揮 Lean 精實的精神，以消除浪費的原則來增進組織的工作效率，真實的運用它來改進企業的文化

DevOps 的定義

不要導入，要用引導的方式• 因為 DevOps 是一種創造文化的過程

三原則• 敏捷• 透明度• 自動化

歷史告訴我們什麼？

現在是一個多變的年代…

那個曾經美好的年代• 知名經濟學家亞當斯密（ Adam Smith）在「國富論」書中的一段記載• 亞當斯密曾經參觀一個具備機械化生產線的大頭針工廠，當時的大頭針都是在家庭式的手工作坊製造出來的，每位工匠要包辦整個製作工藝，從鐵線拉長、整直、裁切、磨尖、裝釘頭、包裝等一系列的流程，平均一天可生產 20-30根大頭針。但大型工廠出現後，在機械化生產線的協助下有著截然不同的運作方式。工廠工人不需要像工匠一樣學會整套工藝，每人只須負責一項工作，整天不斷重複即可。這樣一天下來，每人平均竟能產出 4,800根大頭針。這可不是 5倍 10倍的差距，而是 200倍的爆炸式革新！

• 當時生產線思維決定了人的價值• 「你不好好讀書，將來就去做苦工！」

• 那個曾被工業革命主導的時代已過去？

• 然而，工業革命的影響再深再廣，也終會有退場的時候，尤其是近十年來網路的普及與全球化的浪潮，更加速了這個趨勢• 2006 年台流問題• 這幾年我們也常聽到博士畢業賣雞排，碩士去當搬家工人的新聞。這些職場上看似爬到頂峰，考場上取得領先的人，原本應該是勝利者，走著走著卻似乎回到了原點• 傳統認可的職涯之路也不再是用功讀書、追求學歷、進大企業、向上晉升的線性軌道。傳統的生產線思維明顯開始生鏽，活在新世界卻抱持舊思維，遲早退出市場

逐漸生鏽的生產線思維

所以！未來 .. 有三個主要角色工匠、行腳商人、與管家三種特質合體 ＝ 最小戰鬥單位

• 工匠：從無到有製作一項產品的能力• 在工業革命之，世上幾乎所有的人造物品都是由工匠製作出來的• 有能力從原料到成品完整地製作出一件產品，甚至自己銷售，來滿足顧客的需要• 確實掌握所有製作環節才能成為合格的工匠

• 行腳商人：掌握特定族群需求與喜好的能力• 但他們十分了解特定族群的需要，並知道如何找到客戶想要的東西來滿足需求• 把城市裡的新奇玩意兒帶到鄉間販賣，或是反過來，把鄉間的手工藝品賣給都市居民。他們的貨物種類既多且雜沒有一定，基本上是客人喜歡甚麼他們就提供什麼，或者是接到客人的委託後才代為採買

• 管家：組織不同人事物形成一個整體的能力• 歐洲王公貴族都有一位衣著筆挺、態度沈穩的老管家，管家也好，總管也好，都是組織裡的核心人物。對上，他們要清楚掌握主人的需求；對下，他們要打理宅子裡所有瑣事，協調廚師、園丁、僕人、馬伕等完成每一項任務，對組織而言他們是實質的管理者

• 三種特質合體 ＝ 最小戰鬥單位• 近年來，以美國科技業開始，許多產業都出現了以角色結盟的工作團隊• 幾位擅長技術的「工匠」、幾位了解市場「行腳商人」、再搭配善於經營協調的「管家」，共組一個團隊• 由於他們具備獨立研發、銷售、與運作的能力，得以和大企業保持一種對等的合作關係，並非像傳統上班族僅能仰賴組織，當個聽命行事的員工

工匠、行腳商人、與管家

你是公司需要你比較多？還是你需要公司比較多？

• 技術在變、市場在變、世界也在變、 Device 在變、產業型態也在變、客戶的需求也在變，我們也得跟著改變• 一個專業的軟體設計師養成是不容易的• 以前，軟體技術沒這麼複雜，種類也沒那麼多、更新／淘汰速度也沒這麼快，但是現在 ....• 以前，我們可能兩三個月交付一個版本，但是，現在，我們可能每兩三個禮拜我們就得交付一個版本• 現在工具也進步了，所以我們透過工具幫我們做到 如：基本程式碼品質、測試 (自動化 ) 、佈署 (自動化 )• 不是用功讀書、學寫程式、學好新技術就會賺大錢• 錯過了學習錯過了改變錯過的機會

結論

如何做好品質把關？從團隊，到個人品質把關

什麼是品質？

• 軟體開發所謂的品質把關一直以來，都是不斷在各地論壇、或是公司內部討論的很熱烈的問題。• 軟體開發 => 究竟是把事情做好，作對比較重要？還有，究竟是做出客戶要的軟體比較重要？• 還是作出可延展、容易維護的軟體比較重要？能不能兩者都兼顧？

如何做好軟體品質把關？

軟體開發應該要有適當的 (限制 / 規範 )

軟體開發過度的自由會是一個災難的開始

• 比如：• Framework• 分層• Coding Standard (Programming Rule)

• 適當的限制 是為了讓軟使用的技術不會整個發散• 是為了讓軟體開發有脈絡可依循，更容易多人開發、維護、交接• 適當開發框架，可針對某些特殊領域加速開發

• 比較容易控管團隊的開發時程• 適當的限制 (缺點 )• 開發人員須花一點時間了解開發的守則 ( 共同規範 ) (Coding

Standard) (Programming Rule)

什麼叫做適當的限制？

所以，如何做好軟體品質把關？

• 在軟體開發的生命週期中，定義了許多階段，如：需求訪談 (Requirement Interview) 、需求分析(Requirement Analysis) 、系統設計 (System Design) 、開發 (Programming/Coding) 、測試(Testing) 、交付上線 (Production) 、維護(Maintain) 等階段，個階段關注、牽涉的領域知識也都不同，最後的 Programming 則為軟體開發實際的產出，當然個階段環環相扣，如果一開始對於需求即有誤解，那麼就算你在最後的開發階段把關所有的產出，即使程式寫的再好，沒有 Bug ，但如果不是使用者要的，哪也是枉然

• ( 因為軟體最終是要給你的客戶用的 )

所以，如何做好軟體品質把關？

• 近代的軟體開發也開始將 Code Review 視為軟體品質把關的一個重要環節• 因為軟體不管是多人開發，或是一人開發，都可能因為需求認知的誤解、對實作的技術 ( 程式語言／環境架構／作業平台 ) 的不了解，而產生一些隱憂、臭蟲 (Bug)

所以，如何做好軟體品質把關？

談了這麼多、開發流程、 CI 、 CD 、 Code Review

但是沒有一切源頭的 Version Control 一切都無法做到…

Code review 的目的？

• Code Review 它是開發流程裡唯一讓開發人員有機會針對代碼進行深入討論的關鍵活動• 它是邀請其他人來幫你審查，原始碼上是否存在著不妥之處，例如風格是否與團隊一致、程式碼是否有哪邊可讀性不佳、有壞味道、不容易維護、不好擴充、有安全性疑慮、或效能不佳、甚至壓根就誤解需求的問題存在

Code Review 的目的？

• 在版控工具上進行是必然的，否則光是管理修正的 Version 、或是追蹤 reviewer 給的建議 (comments) 就會太過費力，反而會削減了 code review 帶來的好處

• 有幾個原則可以遵循：• 團隊應該有一致的程式碼 ( 共同規範 ) (Coding Standard)

(Programming Rule) ，這樣比較不會有爭議• 盡量使用代碼檢查工具 (static analysis) ，如：

StyleCop 、 FxCop 、 Visual Studio 內建的原始碼掃描工具來代替人工的檢查• 善用 CodeMaid 這類的 code formatting 工具來維持代碼風格的一致性

Code Review 進行的方式

• Code Review 是為了有效溝通• 根據團隊資深人員、新進人員人數的多寡、團隊編制的方式、工作分工的方式、使用的 Code

Review 次數、每次 Code Review 的時間有所不同• 我們盡量能夠在開發階段時：• 提早發現 bug並進行修復• 凝聚團隊共識• 藉著 Code Review 更了解 Domain Knows-how 需求 ( 這樣的學習比起單向的一對多專案分享或教育訓練，來得有效率地多 )

Code Review 進行的方式

• 團隊有產出時• 表示可以週期性的進行 Code Review• 看團隊狀況，可以由 Program Leader 主導，但相關人員參與即可，通常新進人員也可共同參與，藉機了解哪些錯誤以後不該犯• 團隊由某開發的資深 Program Leader 主導，也可採用抽籤的方式，每週由六個團隊中，對抽到的團隊 (也許是負責某項 Function 的小團隊 )

• 有 Bug 出現時• 當 QA 回報有 Bug 時，這也許就是一個進行 Code Review 的切入點• 但是多人開發的團隊每周還是有固定的時間來進行 Code Review 會比較恰當

• 程式碼是有瑕疵、或效能不佳時• 團隊由某開發的資深 Program Leader 主導，每週由團隊中，由 User回饋所建立的 Backlog 或 Bugs(先處裡嚴重 Bugs [ 在循環內做 ] ，後做 Code Review)

Code Review 的幾個時機點

• 一般來說 Code Review 的建議可以大致分成兩類： • must fix: 一定要修正的問題• nice to have: 建議要修正的問題，但如果需要花太多時間來修改，可以另外開 task 來追蹤

• 如果 must fix 類的問題都處理了， Reviewer 也可以直接結束今日的 Code Review Meeting• nice to have 的問題則是以互相信任尊重的態度來處理• Reviewer 如果拖延太久沒有開始進行 Code

Review ， Developer 也可以主動提醒

如何加快 Code Review?

使用 StyleCop先做初步 Code ReviewFor Developer

• 調整語系為 zt-TW• 取消不太適合中文環境的規則• SA1630 DocumentationTextMustContainWhitespace 注釋節點內部的文本必須包含空格• SA1628 DocumentationTextMustBeginWithACapitalLetter 注釋節點內部的文本必須以大寫字母開頭• SA1629 DocumentationTextMustEndWithAPeriod 注釋節點內部的文本必須英文的句號結束

• 制定團隊共同規範的 StyleCop Rule (Settings.StyleCop)

StyleCop 基本環境設定

與 VSTS 的簽入原則整合VSTS

StyleCop Source Analysis Policy

實作 ( 一 ) 、設定 StyleCop 環境

設計屬於團隊的 StyleCop Source Analyzer Rules

StyleCop Source Analyzer Rules

• 建立 Class Library 專案• 使用 .NET Framework 3.5

• 加入 StyleCop.dll 與 StyleCop.CSharp.dll 的參考

• 定義 StyleCop 的 XML 定義檔• 撰寫程式碼

自訂 StyleCop Rule

• 繼承 SourceAnalyzer• override AnalyzeDocument(CodeDocuemnt) 方法• CsDocument 即是繼承自 CodeDocument• 每一個 CsElement 就是一個 C# 項目• Class• Constructor• Event• Delegate• Interface• Method• Enum• …

撰寫 MyCustomRule 程式碼

測試 MyCustomRule• 複製到 StyleCop 安裝資料夾• 開啟 StyleCop

Setting

實作 ( 二 ) 、實作檢查沒有 Connection Close 程式碼的 Source Analyzer Custom Rule

談原始碼管控的重要性原始碼管控

Team Foundation Server Source Control 說明• 為什麼需要 Source Control ？• 多人開發• 備份、紀錄• 避免覆蓋、失誤• 改壞• 合併 (Merge)• Local 的檔案遺失• 追朔變更的紀錄• 控管權限• 異地工作• 工作管理 (Work Item)

Visual Studio Project Template 概念Project

Templates

什麼是 Visual Studio Project Template?

• Visual Studio 初始建立專案的樣板• 定義不同的框架 (Web, Cordova, UWP,

Desktop…)• 決定 Platform, 決定 Target framework…• 從 VS2010 開始，您可以透過 VSIX Project 來擴充、客製、佈署 Project Template• 甚至使用 DTE 的 IWizard 介面來程式化真正動態的 Project Template

什麼是 Visual Studio Project Template?

• 在 VS 2010 時推出• 讓您可以擴充你的 Visual Studio• 將命令、 按鈕、 功能表和其他 UI 項目新增至 IDE• 擴充指定語言的 IntelliSense • 自訂專案類型 (Project Template)• 相關連結：• 下載 Microsoft Visual Studio 2013 SDK• https://www.microsoft.com/en-us/download/details.aspx?id=40758• MSDN Visual Studio SDK• https://msdn.microsoft.com/zh-tw/library/bb166441.aspx• MSDN 使用 Visual Studio 的 SDK 快速入門• https://msdn.microsoft.com/zh-tw/library/bb166030.aspx

Microsoft Visual Studio 2013 SDK

關於為什麼要做範本精靈？製作範本精靈

• 多人團隊• 一致性的團隊的開發規範 - Coding Standard

(Programming Rule)• 開發更一致化• 加快開發的效率 - 避免重複造輪子• 減低人為的錯誤率• 保障程式碼品質 (搭配 UnitTest & Code

Review)• 讓程式碼更容易交接、維護、與重用

關於為什麼要做範本精靈？

Project Template vs. NuGet Package?使用哪一個？

何時用 Project Template ？何時用 NuGet ？UI (Web

Page/View/)

Controller 或 BasePage 或 Sample Code

Pattern 共用的 Interface 或

Common Class

Configuration (web.config/App.config) or

ConnectionString

References 參考的組件 或 DLL (Class

Library)

Project Tem

plates

NuG

et Packages

前端

後端

開發流程？標準？導入？團隊如何進行？如何開始？

1) 使用原始檔版本控制 (首要項目 ) 不管是一人開發，或是多人開發因為對於 Framework 或 框架 的開發也要導入 Version Control2) 導入 Work Item 原本 WBS 或 WKM 系統上的工作項目要能夠與 TFS 整合3) 盡可能落實 Code-Review4) 導入 Check-In Policy 定義 開發的守則 ( 共同規範 ) (Coding Standard) (Programming Rule) 要有文件 & StyleCop policy XML 檔案5) 導入 Team Build 並落實 VS 程式碼分析 goto (3) 循環6) 使用 Team Build 並結合 (TFS/VSTS) StyleCop Check-In Policy goto (3) 循環7) 導入 & 實作 Unit Test 測試涵蓋率8) 導入 Team Build 結合自動化 Unit Test9) 效能 & 壓力測試

開發流程？標準？導入？團隊如何進行？

開始設計我們的第一個 Project Template

實作練習( 三 ) ：

• 使用 NuGet 設定自動還原、設定 RestorePackage 、與 BuildPackage• 使用 ClassLibrary 自動包裝一個 NuGet Package 的 DAL 元件• 使用 Visual Studio SDK Extensibility  建立 C# Project

Template• 編輯 .vstemplate 與 貼上相關需要的 .cs .js ( 團隊已經預先定義好的 Programming Rule/Coding Standard)• 編輯 ProjectTemplate.csproj• 建立 VSIX Project• 透過 VSIX Project (編輯／佈署 ) 自己的 Project

Template

開始設計我們的第一個 Project Template

實作 (三 ) ：1). 建立 DAL 類別庫專案2). 設定為自動產生 NuGet Package3). 建立 C# Project Template 專案修改為 Web Project Template4). 建立 VSIX Project 佈署 Web Project Template5). 測試

實作 (四 ) ：

References• Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application

(9 of 10)http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

• 非關語言 : 設計模式 - OpenHome.cchttp://openhome.cc/Gossip/DesignPattern/

• Learn About ASP.NET MVChttp://www.asp.net/mvc

• Visual Studio UML 軟體工程 (OOA/OOD 塑模化應用程式設計 )http://gelis-dotnet.blogspot.tw/2011/03/visual-studio-2010.html

• MSDN 台灣部落格http://blogs.msdn.com/b/msdntaiwan/

• Gelis 技術隨筆－架構設計系列http://www.dotblogs.com.tw/gelis/Tags/%e8%bb%9f%e9%ab%94%e6%9e%b6%e6%a7%8b%e8%a8%ad%e8%a8%88/default.aspx

Q&A