Gelis 技術隨筆-部落格

前言 軟體開發本身是一個複雜的工藝過程，牽涉到各種領域技術，一般我們所聽到的軟體架構設計可能都只著重在軟體系統架構本身，比如：如何妥善的分工、如何解決開發上的各種問題、使用哪一種 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 所

前言 有在看小編部落格的朋友應該都知道，我有許多關於 Project Templates 相關的教學、投影片、分享部落格文章等，本次小編進行另一個客戶的的 C# Project Templates 專案時，卻發生一個詭異問題。 就是如上這個錯誤訊息，每當建立安裝好的這個新的 C# Project Template 時，專案建立過程中就會出現這個錯誤，這….. 是什麼詭異訊息？我從來就沒遇過啊？從以前建置 Visual Studio 2015 的 Project Templates 就從沒遇過這種情形，為一的差別只是目前使用的是 Visual Studio 2017，難道我踩到了 Visual Studio 2017 Extensibility SDK 的坑？  喔~ 不會吧，馬上搜尋一下 Google ，結果是，從沒有人遇過跟我相同的問題，一度還認為是專案目錄名稱太長，也許 VSIX 執行環境命令列長度限制，於是將整個專案複製到 D:\ 磁碟機下面還是一樣的狀況。 就在案情陷入膠著時，於是我將編譯完成的 VSIX 安裝檔直接解壓，查看其內容時有了驚人的發現… 這麼發現倒不是 Visual Studio Extensibility SDK 2017 有什麼 Bug，而是我發現了我驚人的失誤…. 什麼失誤呢？@@ 答案是，字打錯，什麼字打錯呢？看看下面的圖就知道了…… 在 C# Project Templates 裡，編輯 ProjectTemplate.csproj 檔案時，不管是需要編譯、不需要編譯的檔案均放置在 <ItemGroup> 節點下面，只是，在習慣上，我們會將不需要編譯的 Content 內容 (也就是<None>的項目)，放在另外的 <ItemGroup> 下，只是代表包含檔案的 Include 我不小心敲成了 Incluse 以至於引發這個作業失敗的錯誤訊息。   結語 這次問題的起因在於，我們若是編輯 .csproj 或是 .vstemplate 等原本由工具產生的檔案，對於 Visual Studio 而言，因為 Visual Studio 工具自行在 Maintain ，Visual Studio 工具不會料想到有人會去修改、甚至改錯了 Visual Studio 工具不認得的關鍵字，以至

關於規範這件事 還記得筆者先前曾經說過一句話： 軟體開發的問題一直都不在於『技術』、『工具』的不斷推陳出新。 而在於，你的做事方法有沒有想要推陳出新、有沒有想要『改變』而進步？ 因為世界永遠只會更進步、永遠都是自己在原地踏步！ RAD 無罪論 這讓我想起了很久以前，網路上曾紅極一時的一個討論，「RAD 無罪論」，當時因為 RAD （Rapid Application Development）工具，如：Borland Delphi、C++ Builder 開始盛行，網路上出現兩派人馬爭論著，究竟 RAD 的出現是好是壞 好的一方認為： 透過 RAD 工具，開發可省下不少的時間，也是 IDE 開發工具的趨勢，且使用 RAD 工具不代表就不需要瞭解底層運作細節。 壞的一方認為： RAD 工具使的一些初學者不需要瞭解底層運作細節，甚至不需要瞭解太多的OOP 物件導向概念、 Object Pascal 語法，就可以拼湊出一個應用程式，因此 RAD 工具會產生對於軟體開發一堆一知半解的工程師。 還記得當時一位 Delphi 書籍的作者：陳寬達先生，他在他的著作「Delphi 深度歷險」裡面記載了當時在 TANet 論壇上比較經典的討論，陳寬達先生將比較中肯的回覆記載在他的著作裡面，如下： 所以，這也就是說，不管是任何工具、技術，其實都跟你個人或團隊 進步 其實一點關係都沒有。 好比使用 RAD、IDE 工具、好用的精靈，不代表就不需要去瞭解底層的運作細節。 也就是說，其實重點都在「人」的身上。工具終究只是工具，就看你怎麼使用而已。 套句流行語： 這不是南北拳的問題，是你的問題。 另外，小編之前所開的課程「 架構設計好簡單系列 - 如何設計符合團隊的範本精靈 (Project Template) 」中，也不是只是教導各位如何建立 C# Project Templates 然後包進 VSIX Project 裡面這麼簡單而已，所教導的是， 如何制訂團隊共同規範 ， 注意 ， 是團隊共同規範 ，是的，我不斷的在課程中強調， 這是「團隊共同規範」的設計，不是只是設計「Project Templates」 ， 而且，我也再三的強調，這個 Project Templates 是在團隊共同規範成形後，也就是在團隊已經擬聚共識、具備共同開發規範

警語： 在使用 MyORMWizardExtensions 請斟酌使用，這是在團隊有共識的情況下、已有共同規範下減輕重複性工作使用 (這個重複性工作在於你的團隊已經有這些重複性工作的 Skill)，所以在使用前，請先參考小編先前撰寫、也有 PO 在軟體開發之路的文章「 導入團隊 Project Templates 樣版設計 - (首部曲) 」。 另外，如果您初學者，不代表您直接拿來使用，而可以不去了解它到底幫你產生什麼樣的程式碼，也就是說，對於你個人能力的提升，還是要能夠自行撰寫出該程式碼，甚至建立你們團隊的規範、程式碼的範本精靈，而不是只是使用別人建立的範本精靈。 先前筆者的課程「 架構設計好簡單系列 - 如何設計符合團隊的範本精靈 (Project Template) 」的重點 7. 一致性的團隊的開發規範 - Coding Standard (Programming Rule)，也是教您如何建立你自己團隊的規範，只是透過範本精靈來簡化工作。 為避免有人誤解，所以在此聲明。   前言 先前筆者在 Visual Studio Everywhere 台北場分享的「 團隊開發永遠的痛-談導入團隊開發的共同規範 」課程，與先前所開立課程「 [第二梯][台北 5/28 (星期六)] 架構設計好簡單系列 - 如何設計符合團隊的範本精靈 (Project Template) 」與的內容中所使用的 C# Project Templates 樣版，本文將介紹筆者自行開發的 Project Templates （以下簡稱為樣版），這個樣版現在已經被我包裝為Visual Studio 的擴充套件，也發佈到 Visual Studio Gallery 市集上，您可以在 Visual Studio Gallery 上下載、並安裝這個套件。 也可以直接從 Visual Studio 的擴充套件管理員下載安裝。   MyORMWizardExtensions 擴充套件說明 這個擴充套件目前發佈的版本只支援 Visual Studio 2017 ，下方筆者說明這個套件的功能、用途、以及使用方式。 在安裝了 MyORMWizardExtensions 擴充套件之後，您可以在你的 Visual Studio 2017 新增專案的是窗看到「MyORM Framework

前言 先前有一個客戶想要將現有的公司內部的 ASP.NET 網站佈上 Azure 的 Web App ，他們希望我能夠提供諮詢與協助，本篇文章是將這個網站轉換並放置到 Azure Web App 的經驗分享。   現有環境 Windows Server 2008 R2 ==> 顧名思義 執行在 IIS 7.5 ASP.NET WebForm 網站 .NET Framework 4.0 MS SQL Server 2008 R2   評估現有網站是否可以上雲端 看到上方的「現有環境」，相信讀者應該也注意到了這是一個 ASP.NET WebForm 所開發的網頁應用程式，但事實上移植到 Azure 並沒有差別，因為 Azure WebApp 也是提供 IIS 包含一個 AppPool 的執行個體，好比你在地端的 IIS 上開一個 IIS AppPool 來執行應用程式一樣沒什麼差別！   但是在 PaaS 上執行還是有一些限制存在，一般來說，要評估一個現有的網站是否可以上至雲端，我們會透過以下幾點來評估： Web Apps 僅支援連接埠 80 (適用於 HTTP) 和連接埠 443 (適用於 HTTPS 流量)的繫結，系統將會忽略不同的連接埠組態，並將流量路由傳送至 80 或 443 Web Apps 預設支援匿名驗證以及應用程式所指定的表單驗證 只有與 Azure Active Directory 和 ADFS 整合，才能使用 Windows 驗證，目前不支援所有其他形式的驗證 (例如基本驗證) Web Apps 不支援全域組件快取GAC，如果您的應用程式會參考部署至 GAC 的組件，就必須部署至 Web Apps 上的應用程式 bin 資料夾 Web Apps 不支援 IIS5 以前的相容性模式 應用程式集區 - 在 Web Apps 中，每個網站及其子應用程式都在相同的應用程式集區中執行 如果您的網站上有多個利用多個應用程式集區(AppPool)的子應用程式，請將它們彙總到具有通用設定的單一應用程式集區，或將每個應用程式移轉至個別的 Web 應用程式 Web Apps 不允許在平台上註冊 COM 元件，如果您的網站或應用程式使用任何 COM 元件，您必須以 Managed 程式碼予以重新撰寫，並與網站或應用程式一起部署這些元件 Web A