Gelis 技術隨筆-部落格

圖片取自： https://www.cheers.com.tw/article/article.action?id=5089076&eturec=1 前言 這一次，小弟受邀在高雄敏捷社群分享一場『利用基礎軟件架構打造敏捷（Agile）之工作環境 為（DevOps）做準備』，這是一個關在於敏捷開發中，軟體開發這件事情裡，你的開發方法、甚至細到 Framework 框架，這與你們的協同工作+效率+反應 有什麼關聯性呢？ 關於軟體開發這件事 因為在軟體技術蓬勃發展的現代，各種流程開發的方法如雨後春筍般不斷湧現，像是：Agile／Scrum／Kanban 等等、以及您是不是曾聽說導入 Scrum 後，OOA/OOD/Modeling 分析就沒有用了的說法？可是... 當你實際進行開發時，你又覺得需求很難收集、也很難被管理，即便團隊使用 Agile 或 Scrum，但是使用者需求總是到了 SD 階段時，容易發散？更不用說到了實際在進行開發的時候，到底撰寫的程式是不是實際使用者要的東西？ 而這些工作必須由你個人的工作開始 到 團隊，課程中，會告訴大家，我們如將『使用者故事地圖 User Story Mapping』到 你的 Modeling 分析方方法，來溝通使用者需求  ？甚至，小弟會介紹我如何只用初步的 UML 三張圖型（Use Case／Class Diagram／Sequence Diagram）來展現使用者故事地圖所看見的全貌，並建構 MVP（Minimum Viable Product）雛形，在反覆的最小增量當中，不斷的修正方向以確保交付的是使用者需要的軟體。 因為，雖然我們需要縮短交付軟體的時間，但更需要交付的是『正確的軟體』。 可以帶給聽眾什麼樣的收穫： 了解為什麼建置適合的軟件架構為敏捷開發的基礎，並學習到如何為自己團隊建置容易上手、學習曲線不高 + 堅固可靠的 Software Infrastructure、與團隊共通的語言的團隊共同規範，讓團隊成員彼此學習、交互成長。 報名連結： https://agilekaohsiung.kktix.cc/events/agiledevops 在高雄的朋友別忘了過來相認一下唷 關於 Gelis： 資深 .NET 技術顧問 FB 社團 (軟體開發之路)： https://www.facebook.com/...

前言 最近在客戶端遇到一個需求，由於時常發生一種情況就是 Developer 撰寫完程式碼簽入 TFS 時，總是會將無法編譯通過的程式碼簽入，通常，在直覺上想到的就是 TFS Build 的『閘道簽入』 透過閘道簽入可以做到『先提交程式碼』到後端 TFS 的 Build 主機，交由 Build 主機確認該程式碼可以建置通過，當然，一般來說，所謂的完整地 CI 必須經由 Build Server 建置通過 + Unit Test + Source Analysis 完成的才表示程式碼是可交付、且沒有問題，當然，流程上是沒有問題的！標準的 CI 確實是如此，但是…. 有另外的一個問題來了！因為，所謂的閘道簽入它還是將『無法編譯的程式碼』簽入到 TFS 中了，而且，熟悉 TFS 的應該都知道，Developer 還是可以選擇將『在本機保留我的暫止的變更』的勾勾消掉，甚至略過驗證組建… 所以，這根本還是無法達到客戶的需求，客戶雖然希望由 CI 機制通過、出去的程式碼才是標準、可運行的，但是，希望開發人員可以在本機先進行『建置』動作，並確認建置動作是 OK 沒有問題的！才開放讓開發人員簽入程式碼。 TFS Check-In Policy 而這時，客戶提了個需求，說：TFS 有沒有 Check-In Policy 是可以在 Client Visual Studio 端確認建置過才可簽入呢？就像是 StyleCop 可以在 Client 先掃過程式碼，確認符合團隊的 Coding Style 後才允許簽入。 聽到這需求後，我當下想了想，身為 Visual Studio 擴充套件開發魔人的我，寫過各式 VS Extensions 還上架了一個 MyORM Extension ，甚至還推出了『C# Project Templates』的線上課程，當然 VsPackage 是不同的，但是我也寫過 VsPackage，卻沒寫過 TFS Check-In Policy 這…他日恐遭人話柄 XD 需求分析： 使用 C# 撰寫一個 VS 擴充套件，就像 StyleCop 一樣，只是這個套件必須呼叫 Local 端的 MSBuild 進行專案的建置動作，如果建置不過，就不讓 Developer 簽入程式碼，並秀出錯誤訊息。 這個 Check-In Policy 也必須可以被包裝成 VSIX 的可...

前言 前一篇文章中『 從使用者需求、談架構設計 』，筆者以一個房貸線上申請系統的例子，關於一個從使用者需求、來談架構設計的一個比較實際的例子，當時，筆者以 UML／OOAD 常見的循環星型分析法，帶著各位由系統分析開始、如何串聯到系統設計、並解釋因為從系統設計開始，便可牽涉到 Platform/OS/Framework/程式語言 等等，而在 UML 這裡也有模型驅動架構 MDA (Model Driven Architecture) 可以補助，課程中，我也利用的這樣的概念，將 Domain Class Diagram 帶入細部 Class Diagram 分析時，拆解為兩塊，一個是 BO (Business Objects) 另一個是 VO (View Objects)，接著，並實際的撰寫程式，並實作出最小可行性產品。 在今天的這一篇文章裡，我將利用在 Clean Architecture 書中的一個整潔的軟體架構的概念，將我三年前所設計的 EasyArchitect Framework 來做一個應證，從頭來探討軟體開發、從需求面開始、你的需求大方向的掌握度其實會決定你的架構設計的方向性是否恰當、符合所需、不是過度設計的架構。好，我們接著往下看。 需求掌握度 圖（一）、Impacts Mapping to User Story Mapping 圖片來源： https://www.slideshare.net/chassa/2014-0618srdimpact-mapsstorymapsen 為什麼談需求的掌握度？訪間，許多軟體開發方法告訴你的大部分是，何時該做什麼、那些角色該關注什麼？有哪些會議？什麼時候招開？該注意什麼？以敏捷創建使用者故事地圖（User Story Mapping）來說，它敏捷需求規劃中的一個流行方法。用戶故事地圖可以將你的 Backlog 變成一張二維地圖，而不是傳統的簡單列表。用戶故事地圖可以讓你更容易看清 Backlog 的全貌。這概念真的非常好，因為它幫助你有更好的進行疊代的增量式開發，同時確保早期的發布，可以驗證整體架構和解決方案，為傳統的開發計劃提供了一個更好的替代工具。 且創建 User Story Mapping 可以有七～八個步驟，因為篇幅關係我不在這一一說明，第一個步驟是招集 3-5 對產品熟悉的人一起討論，並讓每個人在便簽紙...

前言 在最近這幾年，『敏捷』一詞，幾乎成為軟體開發領域的罩門，企業內部軟體發部門成功的例子不少，但是失敗的例子幾乎也是隨處可以聽到，真的只是就像人家說的，因為『成功經驗』無法被複製？所以，有些人無法成功，但….？真的只是這樣嗎？ 混亂的年代 在最近這幾年，您是否也有感覺到幾件事情，在軟體技術蓬勃發展的現代，各種流程開發的方法如雨後春筍般不斷湧現，從早期的 Waterfall 還有 SDLC/RUP/AUP/XP，或是近代的 Agile／Scrum／Kanban／LeSS 等等…每天都有新的框架 Framework 出現（尤其前端更是如此），軟體工程師不斷地追求新技術，似乎，不持續的學新技術，就會跟不上這個世界，某種程度來說，不能說不對，但是若陷入工具的迴圈裏面，那可能會浪費許多寶貴的時間。在專案裡面使用不適當的套件，可能會埋入一些隱憂，未來可能生成其他的技術債，浪費團隊的時間。 在軟體技術市場、需求、市場多變現代，我們在為我們的產品、與團隊選擇一個符合市場需求、使用者需求、團隊 Skills、客戶環境、考量未來乘載量、甚至需要搭配設計面、使用哪一種軟體架構的設計方法，這些都會是考量因子， 敏捷不是沒有門檻 『軟體開發沒有銀彈』這件事，我已經在各個不同的企業端提過數次，以我自身的經驗也深深地認為，其實敏捷是有門檻的，怎麼說呢？在國外，真的導入敏捷成功的團隊，其實，團隊成員本身都已經沒技術上的問題，或者，應該這樣說，就是本身對於軟體開發架構、實作技術、Design Pattern，甚至舉凡包括版本控制系統 Version Control 的使用（延伸閱讀： 關於團隊使用 VSTS/TFS 原始碼控管的 - 三兩事 ）、個人的工作管理、各種 Work Items 的 Tracing Tool，專案管理工具的使用等，更不要說團隊開發共同規範其實都已經以一定的水準了，而他們推行敏捷，純粹只是要解決『人』的問題而已。 而所謂的『人』的問題，不外乎就是，『溝通』、如何有效的溝通？團隊間的協同工作，各成員主動的管理風險、彼此之間的信任、並且團隊成員有一定的靈活度，這得從文化著手， 當你團隊的技術到達某一定的門檻之後、再談敏捷 由上圖（一）所示，企業或開發團隊要進行敏捷時的軟體架構 與 人之間的關係，圖中所要表達的是，當你要進行敏捷（文化）時，您得在基礎架構規範、也就是，即便團隊之間...

前言 看著保哥 與 Bruce 都有整理一份屬於自己的軟體開發清單，於是乎，便也想來整理自己多年來所累積起來的軟體開發清單，未來，此內容也會不斷的擴充期工具內容。 圖片來源： https://yourdolphin.com/supernova/developers#SAM 開發 IDE 工具類： 不用說，Visual Studio 2017 一定會列出來，我也會不斷的升級 XD Visual Studio Code Visual Studio for MAC (如果你有 MAC 作業環境一定不要錯過) LINQPad 如果是 C# 開發者，一定不要錯過此工具，LINQPad 也是我第一個願意花錢購買的工具之一 Visula Studio 擴充套件類： Productivity Power Tools for Visual Studio 2017 MyORMWizardExtension - <= 我自己開發的 (笑) ==> 之前撰寫過 介紹文 Power Command for Visual Studio BuiltinCmd - 一個與 Visual Studio 整合較為完整的 Console Prompt Command 工具 Web Essentials 2017 - 如果你是使用 Visual Studio 的網頁開發人員一定會使用到的工具 (強烈推薦) Advanced Installer for Visual Studio Open Command Line OzCode - 推薦一定要用的 VS 偵錯工具 Suppercharger - 非常好用的 VS IDE 編輯器增強工具 (Edit Line Color, Style, Tooltips 等，看 Code 不會那麼辛苦 ) Snippet Designer ReSharper 我的 Visual Studio 擴充套件開發工具： Visual Studio Extensibility SDK - 透過 Visual Studio Installer 安裝擴充功能即可 Visual Studio Project System Extensibility - 如果你對於 Visual Studio 的專案系統，也就是 Project System Extensibility 興趣...

前言 最近，經由前前公司的同事介紹下，他目前所處的單位有一個教育訓練的需求，該需求是這樣的： 一、團隊中有許多人從 notes 轉換到.NET開發不久，目前工作為 SA ，但是對於從 SA 工作到 SD 的銜接總是有點卡卡的。 二、團隊中現有 SD 對於 ASP.NET MVC 的開發不甚了解，希望藉由課程能夠順便讓其了解在 .NET 平台上能夠做到那些事情 (泛指在 Architecture Design 上，.NET 平台上能提供什麼？) 三、但是聽眾中大部分為 SA，所以希望能從系統分析開始講，一路到設計、實作，希望是一個一條龍的課程。 四、加上目前團隊正在大量地使用 UML 作為系統分析的 notations，所以，希望系統分析 SA 的課程的部分已 UML 為主。 恩，所以此課程名稱最便成為：『ASP.NET MVC 與（SA 系統分析／SD 系統設計）與 OOAD/UML 軟體系統開發課程』，課程名稱非常長吧？沒錯！XDDDD 而且內容非常 非常 非常硬….. 因為課程必須使用真實的例子，最好是客戶目前實際地 Case，而且要從 SA 開始 (教如何繪製 Use Case + Domain Class Diagram + Sequence Diagram)、到 SD 該如何讓 UML 與平台 & 語言有關？MDA 是怎麼回事等，所有繪製的 UML 圖型必須能夠與程式撰寫銜接上喔，因為許多人會畫圖，但是，你畫的圖能寫程式嗎？多數人是不清楚的，而剛好，我對於 UML 中的 SA 與 SD 如何銜接，剛好有些研究，而且最近五年來我手上的所有專案均是這麼做的！我所畫的圖型絕對可以直接產 Code，而且非常非常的清楚，對我而言，這樣的設計方式我已經行之有年，於是我很爽快地就答應了這一次的企業內訓課程，雖然這個課程真的非常硬，哈哈，我說非常硬的原因是，在這十天的課程過程中，到最後一天，我必須帶著學員真的撰寫出一個線上房屋貸款申請系統！要可以申請，對你沒聽錯，課程結束，要真的把一個系統做出來…. 這就是我說非常硬的原因。不過，還好，我做到了！哈哈 對本文內容目前已錄製成線上課程： 決戰 OOAD 系列課程 、有興趣的讀者，可參考： 課程連結 進階使用案例分析技巧 在上一篇文章中『 從使用者需求，談架構設計 』我提到了軟體專案的核心架構必須由使用者需求出發，因為...