Gelis 技術隨筆-部落格

前言 前一篇文章中『 從使用者需求、談架構設計 』，筆者以一個房貸線上申請系統的例子，關於一個從使用者需求、來談架構設計的一個比較實際的例子，當時，筆者以 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 系列課程 、有興趣的讀者，可參考： 課程連結 進階使用案例分析技巧 在上一篇文章中『 從使用者需求，談架構設計 』我提到了軟體專案的核心架構必須由使用者需求出發，因為...

前言 軟體開發本身是一個複雜的工藝過程，牽涉到各種領域技術，一般我們所聽到的軟體架構設計可能都只著重在軟體系統架構本身，比如：如何妥善的分工、如何解決開發上的各種問題、使用哪一種 Design Pattern 來解決問題、如何快速開發等等，只不過，真正有用的軟體是對客戶有用的軟體、能替客戶解決問題的軟體，才是真正有價值的軟體。 如果，您有非常妥善的軟體架構設計、並整合的 CI／CD 自動化整合測試部署、交付流程，也整合了 Containers 等相關技術，但是 CI／CD 過去卻不是使用者所想要的軟體，那你頂多只是做到了可快速的不斷的交付軟體直到客戶滿意為止，但，如果一開始的需求方向就錯誤了，那就不是 CI／CD 自動化整合測試部署、交付流程所能夠解決的問題，因為你的核心架構可能都需要重新翻寫。 當然，並不是說上述架構設計、自動化測試整合部署流程不重要，架構設計、自動化測試整合部署流程固然很重要，只是，相形之下，做出客戶需要的軟體，後續的各種軟體架構設計、自動化測試作業也才有真正的價值。 關於軟體架構設計 事實上，真實世界中的軟體架構設計應該必須由使用者需求出發，正確收集到使用者的需求，也才能夠正確地做出最佳的架構設計，就專案而言，所以，如果您在分析、與紀錄使用者需求所使用的方式，能與開發團隊相同，且一致的語言 (透明化)，這一致的語言可能還包括，你在分析階段所以使用的 notations 表示法，甚至到您開始做系統設計 (System Design) 所使用的 Architecture documents 、甚至 implement 所定義的 （Programming rule/Coding Standard）等，都在這個的範圍內，也可以說，如果您分析工具如果是建築於團隊開發的共同規範之上，那麼不管你們是團隊進行內部溝通（SA對SD／SD對PG），或是與使用者溝通，都可以將 Gap 降至最低。 在我自己的開發團對裡，我們取用 UML 部分的圖形與 notations 來使用，若您運用的恰當，它可以幫助你在分析使用者需求時，釐清、切割清楚什麼是使用者最關心的，因為，這其實都會與你之後的架構設計息息相關。 為什麼我這麼說呢？ 我下面分幾點為各位說明： (1). 在進行架構設計時，如果要避免「過度設計」，使用 UML 的 Boundary 可明確規範出哪些是系統內、哪...

圖片取自： https://www.cmoney.tw/notes/note-detail.aspx?nid=55243 前言 關於這篇文章，其實早在前年就想要動筆了，只是，一個忙了起來，就是一整年，也沒時間動筆，加上私人生活中的忙碌更是不可開交。 為什麼會有這篇文章呢？其實是，最近幾年，不管是在工作環境也好，或是在私人聚會中也好，不時的有人問我：Gelis 阿～看你能夠將興趣當能工作真好 (或工作剛好是你的興趣真好)，... 恩... 其實，在這個世界中，工作永遠不會剛好是你的興趣，你的興趣也不會剛好是你的工作的！什麼意思？為什麼我這麼說呢？我從一個故事開始說起好了。 來龍去脈 還記得還在之前公司時，公司有一次來了兩個新人，這兩個新人都是在資策會就業服導中心學習程式相關課程半年後來到公司的，他們都是滿懷著對於程式設計就是他們發揮理想、創造力的理想工作而去上課，程式語言對他們而言，就是個有趣的東西。來公司不久，當然，立刻 involve 到專案中。這過程中，就一如以往，有開發上的問題我請他們來問我，有些技術熟悉度的問題，我便出 labs 讓新人練習。很快的，三個月過去了，我看他們若有功能做不出來，下點苦工，就算遲交也可以交出功能，還算免強過關，只要再努力點就好。 在這個時候，其中一位跟我說，他不想做了... 我問他： 為什呢？ 他說： 他覺得程式設計不是他當初想像的那樣？... 我好奇的問：怎麼說呢？ 他說：程式要看文件SPEC，可是有時大家都很忙，都沒有人可以告訴她 SPEC 的意思，他又看不懂，另外程式也很趕，程式跑不起只能自己上網查(後來才發現他程式其實似乎沒那麼熟)當初上完課信心滿滿，來一個月後信心變重挫，不知跟怎麼走下去～他覺得軟體工程師的工作不是他想的那樣.... 於是我便接著問：那... 你當初覺得軟體工程師的工作是怎麼樣的呢？ 他想了很久，說：就是... 我也不知道耶～... 就是，應該剛開始會有人帶你寫程式，但是感覺上在這裡什麼都要靠自己... 有時面對客戶開會還會被客戶罵.. 可能我不適合軟體工程師這一行吧！....我也不知道該怎麼說 (開始吱吱烏烏) 我告訴他：不管什麼行業，在社會上工作你不可能每件事情都要別人從頭做一遍給你看你才能自己做，很多事情都是做中學，慢慢成長，並感受其中的樂趣，沒有人一開始就什麼都知道、什麼都會，...

前言 最近做 ASP.NET MVC 內部教育訓練時，因為同仁問的一個看似很蠢的問題，但是卻讓我發現一個我從來壓根子就不會想過，要在 {ID} 裡面傳遞的 primaryKey 的內容居然包含句號 ".”，因為眾所皆知，句號在 Url 裡面，應該是保留字元，且 RFC 3986 規範中定義了在 Url 裡面那些是保留字，如果URL中使用到了這些保留字，這時候就需要使用 UriEncoding 將其編碼為「 %HEXHEX 」的形式。 MVC 的 Route 中 {id} 中包含句號的問題 事情是這樣的，課堂中，實作一個 MVC 基本表單，包含清單與 (CRUD) 等 View 畫面，於是撰寫的假資料來測試從 List 到 Details 的畫面。 由於為求簡單，所以 ViewModel 只有兩個欄位：EmpName、Title，於是我將 EmpName 充當 ID 使用，傳入到 Details 畫面，因此我們直接修改 MVC 的範本如下： 但是，當程式執行後，並在這個畫面點選了這個 ActionLink 後，卻出現如下 404.0 Not Found 我發現，學員傳入的 id 為 gelis.wu，也就是說，當中有一個句號 “.”，但是我們不是有將 id 的內容用 UrlEncoding 包起來嗎？後來爬文了一下，才想起來，就是以 HTTP 所使用的 application/x-www-form-urlencoded 的編碼規則來說，字符"a"-"z"，"A"-"Z"，"0"-"9"，"."，"-"，"*"，和"_" 都不會被編碼，也就是說 gelis.wu 會照實丟出去，這些東西真的太久沒用就會忘，因為長久以來心中總是會有一種根深蒂固的觀念就是，從開始接觸 HTTP 到現在，應該都沒改過這些東西，應該都一樣，但有時就因為這種想法，導致類似問題都認為，這理所當然地而未加以細心思考，但是，事實上，除了 EmpName=test2 與 test2 可以導向到 Details 畫面之外，如果 EmpName 包含句號，就是不能執行，為什麼 II...

前言 最近接觸一些開發團隊，發現還是有許多團隊雖然已經導入 TFS 或 VSTS (以下都簡稱為 VSTS)，但是仍然只是將 VSTS 當作 Source Control 使用而已，不要說 PM 或 PO 沒有將 WBS 或是 Task(後面都簡稱為 Task) 鍵入 VSTS 中的 Work Items 外，就算有鍵入 Work Items ，也沒有強制要求團隊成員 Check-In Policy (簽入原則)，將完成的程式碼簽入 VSTS 的時候，關聯相關的工作項目 Task 。 如果開發團隊連最基本的原始檔管控、Work Item 、工作管理等都沒有做的完善，而原始檔管控又算是軟體專案開發最基本功的部分，如果連基本功都無法落實的話，那麼，後續的 Agile/Scrum... 其實都不用談了。 引發的問題、隱憂 筆者先前，有許多文章在探討團隊開發、個人工作管理與共同規範的關係與問題，這也是筆者先探討 問題、隱憂的原因，因為撇開團隊所使用的開發方法、合作模式 Agile/Scrum/CMMI 等方式不談，因為流程在這邊並不是重點，但是工作若沒有被有效管理，你如何掌握每一個工作項目所花的工時、無法掌握每一個工作項目的工時，更不要說你想要掌控團隊成員中，每一個人手上有哪些工作，有那些已經完成、那些正在進行中、哪一些還未開始，以及哪一些工作由哪一位成員進行 (工作分派狀況)。 在以前，大約十多年前，2005 年左右，當時 TFS 還未盛行，當時筆者的公司、訪間的軟體開發團隊會使用 EXCEL 來控管團隊的工作進度，當時，一樣控管得很好，只是會有幾個缺點， 團隊成員要另外開啟 EXCEL 與其他成員共享 Sheet，每天Update工作 主管要引導團隊成員 Update EXCEL 內容 主管對團隊成員間，要花比較多的溝通成本 團隊成員之間，要花比較多的溝通成本，討論程式碼 (因為 EXCEL 內的說明無法直接與程式碼相關連) 使用 EXCEL 管理專案當然不是不好，以前的開發人員這樣管理專案，不也管理得很好，相信很多讀者心裡是這樣想著，沒有錯，但是 (有但書)，開始有使用者回饋 (進入 UAT) 階段， 團隊成員 A 簽入的程式碼究竟是為了某個 Task 而修改、或是因為從某個原始 WBS 展開的 工作項目，User 測過後有 Bug 所...