Gelis 技術隨筆-部落格

雜談：軟體設計中 Cross-Cutting Concerns 的重要性 圖（一）、Cross-Cutting Concerns 跨領域關注點 前言 什麼是 Cross-Cutting Concerns 跨領域關注點？我比較少專注談論這個主題，事實上，這不是什麼很新的技巧，也不是什麼狠了不起的高端技術，只不過，我認為有些設計技巧是這樣，看似不難，不過要真的能在專案、實務上的軟體架構中均衡的實踐，那就有一定的難度。 實踐部分，常見的手法即是 AOP, Aspect Oriented Programming 後面都簡稱 AOP，而這個技巧在 .NET C# 上就有多種實踐手法，這個早在 2014 年時，我替竹科某廠所設計的 Web API Framework (net451) 的框架裡，就充分利用這個技巧來將系統服務，像是 Logger (紀錄)、Exception Handlers (例外處裡機制)、Notification/SMS (通知) 等等的實作 與 商業邏輯分開。實作方法我們稍後來說明。 什麼是 Cross-Cutting Concerns 跨領域關注點 這其實是軟體開發上，一直存在的普遍問題，這問題在傳統階層式架構上也存在，我發現訪間有些文章扯進了 Clean Architecture 整潔架構，事實上不管你使用哪一種架構， 這類跨越不同層的程式碼卻還是得因為某些 None-function 的需求，得相依某些底層服務的問題，其實一直存在 。 通常在設計系統時，關注點分離，讓我在實際進行開發時，只需要專注在某一個模組/Layers 而不需分散注意力在其他的模組或者不同層次的位置上，且開發完成，不需考量各層彼此如何介接，因為每一層早已經定義好彼此互通所使用的協定與溝通的方法，像是 MVC 即是類似的框架。 回到跨領域關注，在軟體的開發上，尤其在企業商業邏輯的開發上面，在程式碼的實作上，我們知道程式碼當然是越簡單、行數越少越好，再說 SRP 也告訴我們一個元件、一個 Method 最好只有一種被修改的理由越好維護，只不過實際的程式碼。為了寫 Logger，為了實作驗證等，往往一定會與底層相關套件或模組相依，總還是會有部分程式碼讓這一個被修改的理由中，相依著其他外部組件、套件，這些在 Clean Architecture 裡，應該屬於 Infr...

軟體架構設計原則：導論 我說明一下，為什麼會有這篇文章？因為最近，我正在籌備一個全新的課程，這門課算是我多年來在企業端顧問 + 也包括帶團隊做專案，也包含了幾次替企業客製化 API Framework 框架的相關實作經驗的體現。 記得，好幾年前我分享過一堂關於【 您的軟體架構構敏捷嗎？ 】的課程，這堂課程其實就是在告訴你，實務上進行開發時，沒有什麼開發的需求得要完全的想清楚、完全得清楚該怎麼做 + 或者是得完全的分析清楚後，才能進行程式碼的開發與撰寫。在敏捷的環境裡面，你沒有一項任務是進行所謂的軟體架構設計，但是你卻還是得進行當下適當的架構設計，這其實還蠻抽象的，但是你不應該在這個抽象預想、或者設計太多未來不太會用到、或者是根本不會用到的抽象設計在裡面，因為太多的設計一部分也又回到瀑布式的時代，難道你得全部分析完，才能開始寫程式？ 但.. 最近我也有篇文章【 為什麼我說在撰寫程式之前，還是先做個簡單的分析比較好？ 】說明，撰寫程式之前，還是先做個簡單的分析比較好？所以，那到底，我一開始要分析，還是不分析呢？答案是：你要做基本的抽象分析，但是只是做應該做的部分，什麼是目前應該做的部分？這其實需要蠻多相關的經驗，也沒有實際的標準答案，方早在與蔡煥麟老師互動時【FB 連結： https://www.facebook.com/share/p/PdntjirACrAvVhmw/ 】，我腦袋也迸出許多這些年來的設計與經驗感想出來 XD 圖（一）、DDD 戰術建模 - 建置 API 服務 通常，我們在進行系統開發時，會進行部分抽象的設計，在敏捷裡，我們可能會以價值為最優先考量來進行設計，但這個設計裡面，我非常喜歡 DDD 的 Core Domain 的概念，我不講過多的技術、也不希望有過多的平台設計或者框架的影子在裡面，我只希望先 Focus 在這個領域 (Domain) 裡面就好，因此，在藉由 Clean Architecture 的 Plug-In 的架構裡，我就可以先避免掉其他無用的抽象設計，也因此可以幾乎避免掉爾後的疊床架屋的設計出現。 圖（二）、先前小弟一堂課【利用物件導向五大設計原則 S.O.L.I.D. 來建立強固的軟體系統】的部分截圖 在不久前，約今年初，我也在企業授一堂課，關於透過 SOLID 建構六角架構的課程，這一堂課的主要內容其實也不是在...

從 Semantic Kernel 談 AI 浪潮下的開發人員的挑戰 圖片來源：https://blockcast.it/2023/03/22/will-chatgpt-replace-blockhcain-developers/ 前言 近年來，從前年 2022年11月30號 ChatGPT 推出以來，可說席捲整個世界，生成式 AI 將取代你的工作一詞不斷的在新聞媒體版面、各行各業、甚至你生活周遭出現，不亞於當年 iPhone 的推出，但我覺得更甚於此，因為 AIGC 的出現，讓我原先不看好的 LLM 大型語言模型原來能夠 Pre-Trained 到這樣的地步，類神經網路居然能將自然語言（NLP）的處裡，表達做到基本邏輯推演甚至通過圖靈測試的地步，這讓許多人、各行各業、開發人員都燃起盞明燈。而取代之說，也如雨後春筍般地湧現，是好是壞大家不僅開始思考各種因應的對策與方法。但趨勢通常都不可檔，只能去理解它、瞭解它、利用它、接受它、擁抱它、未來它會成為我們生活周遭的一部份。 在 AI 浪潮下，開發人員面對的是什麼？ 最近我一直在思考一個問題，在生成式 AI 的浪潮下，這對開發人員有什麼影響？我個人的看法是，開發人員未來要生存只會越來越難，我們得先做好充足的準備，但凡事總是有一體兩面，因為生成式 AI 有可能會使的基本的工具與技能不再重要？像是比較細微的工作，也就是粒度比較小的工作，像是翻譯這一段文字、為這個 Method 撰寫測試等等，以及一些需求明確，能夠以自然語言完整表達的（內容/Code）產生的工作可能都可以由生成式 AI 來完成即可。 但前面提到凡事都是一體兩面的，目前的 AI 以上下文來預測下一個字詞，這目前仍然可能有幻覺，也就是開發人員還是得做最後生成的內容的把關的動作，只是善用 AI 是能夠大大增加生產力，而開發人員可以更完全專注在（商業需求/業務需求 or 藥物目標）上。 對軟體產業的影響 當工具與技能不再重要？？其實這句話這樣說，其實也不太對，以前我們常說，替客戶開發專案使用的程式語言或是技術不重要，重要的是要能夠完全的達成客戶的期望。 因為，在人工智慧開始蓬勃發展的現代，如果 AI 能夠完成你的軟體架構的基礎樣貌，可能是 Class/Design Patterns 屬於客戶端自然語言生成的部分，也許有 50%-60% 我們可以不用關心...

為什麼我說在撰寫程式之前，還是先做個簡單的分析比較好？ 我們可以從討論中獲得共識，但你跟你的需求獲得共識了嗎？ 前言 上個禮拜，我在公司對新人進行教育訓練，我依舊按照我原來進行訓練的步驟開始，先了解主題與內容，也就是新人想學習得內容？比如是前端？或者是後端的開發等等。接著是新人的程度到哪裡？如果假設我是要教 C# 與 ASP.NET Core MVC 的開發，那麼我得先調查新朋友是否已經撰寫過 C# 以及對 OO (Object Oriented) 了解的程度到哪裡？再來，就是從我們一般進行專案開時，所所有會使用到的技術來排定學習的優先順序，當然了，也考量學習的新朋友目前所擔任的角色。 學習是需要被客製化的 再回到本文想要講述的重點，因為每一個人的基礎都不同，已經熟悉的技術內容都不同，所以經過客製化的訓練內容也會有些不同。 而我們現在談的是軟體專案開發，既然是專案開發，那麼開發的內容(產出的內容程式碼)是來自於使用者需求，所使用的技術只不過是幫助我們去勾勒出『使用者』需要的『成品』（也就是成運作+並達成使用者標的與期望解決的問題）的軟體最終成果（也許是網站 Web／APP／..Others）， 也就是說，使用何種技術只不過是種手段，但是你有沒有 Catch 到使用者真正的期望與需求那可能是另外一件事情。 在真的開始寫程式之前，建議還是做個簡單的分析吧！ 在開始之前，我隨口問了一下新朋友，你知道 OOAD 嗎？就是也可以拆解開來分別談 OOA/OOD ？ 結果新朋友告訴我，她只有聽過 OOP 而已，沒有聽過 OOA 與 OOD? 我聽到之後非常的驚訝，因為這位新朋友再來公司之前去恆逸上過課而已，也許已程式開發為主的課程並不會提及這些，也有可能軟體開發內容層面範圍較廣無法全面提及也是實屬正常。 我告訴她，其實在台灣目前的產業裡，也不太重視分析／設計這兩個階段，但是我個人反而比較重視這想個階段，但並不是說我不重視使用的技術 & 軟體架構設計，因為使用哪一種軟體架構設計／Patterns 是來自你的『使用者需求』，像是幾年前，我曾經寫過一篇文章：『 從使用者需求、談軟體架構設計 』這篇文章所講述的內容一樣，一切都是來自你的需求。 而有部分 Bug 亦是從需求而來，而從需求而來的 Bug 往往最難修改，可能得翻掉架構也說不定。 圖（一）、從需...

如何透過 Github Copilot 來增加開發人員生產力 前言 從去年開始 ChatGPT 的出現，短短的時間瘋迷全球，許多 AI 取代人類、取代各種工作的資訊與消息不斷湧現，說 2023 是 AI 的元年一點都不為過！連我看見 ChatGPT 3.5 的撰寫程式碼的能力都讓我睜目結舌 & 啞口無言，當下甚至心想，我的工作要被取代了嗎？連 GPT 3.5 撰寫程式碼的速度都比我還快。 圖（一）、最流行的 ChatGPT-4 Plus 付費版 之前 NVIDA 的執行長曾說過一句態人尋味的話： - AI 的 iPhone (智慧手機) 時代來臨 我想有經歷過 Pocket PC 的年代應該會知道，比 iPhone 還早，約 2003 年左右，微軟與 Motolora 都有推出所謂現在的智慧手機，只不過在當時是不這麼稱呼，因為它是由所謂的掌上型電腦發展而來，早期部分稱作 PDA (Personal Digital Assistant) 當時的掌上型電腦原型機大概長這樣，這是微軟的 Windows CE 如下圖： 圖（二）、Windows CE 圖（三）、早期 HP 推出的 Pocket PC for Windows CE     上面這張是 HP 推出的 Pocket PC。 圖（四）、iPAQ   這台 iPAQ 是筆者 20 多年前相當嚮往的機型。 回到主題，為什麼說是『AI 的 iPhone (智慧手機) 時代來臨』呢？其實如上方所提，相同的東西 2003 年即出現過，但是紅不起來，一個是 Pocket PC/SmartPhone 的設計理念來自於掌上型電腦，這是敗筆，也可以說，它就是做得太像『電腦』，好似縮小版的 PC，操操作起來也好似 PC 那樣複雜，一般使用者在沒有特別的指導下並無法自我學習並上手，只會覺得這是專業人士才有辦法使用，有距離感，也就是鎖定目標市場太小，這也是最大的敗筆，所以當然也沒有發展出自己的生態，因為所有的應用全由開發商自己去思考，而不是由市場需要來導向，這又是另一個敗筆。因為它鎖定的用戶是商用市場，而但是又不是由市場的生態來去左右應用的發展，而這些都是賈伯斯後來發現的商機與成功的契機。 後來 iPhone 的 UI 重新設計與包裝下，人性化的操作與設計，甚至讓一般不懂電腦的人...

淺談 Code-Review 前言 最近，有些朋友也在談論 Code-Review 以及 Code-Review 所遭遇到的困難等，今天我就來談談我自己對 Code-Review 的一些初淺的看法。 近年來我在各中小型企業執行顧問工作，有 API Framework 客製化的框架開發、也有 Redis 導入工作、也有日常維護（專案開發技術顧問角色/Trouble-Shooting/專案軟體架構設計角色/單元測試顧問/教育訓練.../etc），而不管我執行哪一種工作，協助解決 Bug 也好，很多時候的第一件事就是與該團隊成員一起 Code-Review，先來看看程式碼，了解出現問題的 Source Code，這是再稀鬆平常不過的事情了，今天，我就來分享我在各大企業，許多團隊實際進行顧問時的 Code-Review 所看到的一些現象，並分享給各位。 實務上 Code-Review 以我個人的經驗我覺得可以區分為以下兩種： 非正式的 Code-Review： 什麼叫做『非正式的 Code-Review』呢？以往，我在帶團隊做專案時，不管是我與同仁 pair-programming 時，或者相互討論需求時，我們會同時進行 Code-Review，這時你會說這也算？對!!! 我認為，當然算，當然有些決議會記錄下來在下一次正式討論時與團隊同步，但是我個人非常重視這個過程，而且這些討論一樣是在『有團隊開發共同規範的基礎下』進行的。這些通常在位子上就可以進行。 非正式的 Code-Review 其實也有己的進入點（其實非正式場合我不建議用 Code-Review 做為內容表達方式，一來讓人覺得它就是要來噹我的會議、二來就是有犯了什麼錯，所以準備被指正等。） 1). 當 Junior 工程師對需求有問題時  2). 當 Commit 的 Source 或 Pull 下來的 Source 有問題時  3). Merge 出錯時 以上 3). 點我統一說明，非正式場合不建議大費周章發會議通知 + 找所有人一起參與，一來花費過多時間也沒有效率，專案開發是分秒必爭的，本來就不建議有過多的浪費（敏捷也告訴我們要減少浪費）使用最少的資源，與該需求相關人等討論即可，甚至在位子上花 10-20 分即可進行，我個人是建議不要超過 30 分鐘。 Merge 出錯通...

軟體架構設計：有『題』（二）- 為X宏網路售票系統加入 API First 網站 前言 在上一篇文章〔 軟體架構設計：有『題』- API 設計原則以『線上售票系統為例 〕裡面，我們幾乎在 LINQPad 上完成了一個線上購票的雛形，而這一次，一個部分是我們會再持續的建模的過程中補足一些上一次的缺失部分、第二部分則是加入網站設計部分，而這個網站會使用先前我在某客戶端所開發的 API Framework 框架為基底來設計，除了完全支援 >NET 6 外，這個框架封裝的許多在 Clean Architecture 裡屬於 Infrastructure 的部分，包括 【Role Security Access Controll Layer】與【Notification】以及【Log】等功能，更細部的部份我們下面再來談。 持續的建模 針對上一次，我們在X宏網路售票系統中用 UML 所呈現的 DDD 的 Domain Modeling 與 對照 Scenario 可以發現幾個小缺失。 (1). 加入 ShowTime 的 ValueObject (2). 建立 SeatReservation 實體的 Create 方法 (3). 調整 ConcertVenue 音樂會場地物件實作 另外，也針對 Application Services 的 購票作業 Reservation 方法調整程式碼邏輯，因應票卷 Ticket 由 Ticket.Create 方法來產生，並需要傳入（訂位代號：ReserveID; 場次：ShowTime） 程式碼中使用的術語，完全參照 Domain Modeling 與 事件風暴 中所精練出的通用語言 (Ubiquotius Language)，以確保程式碼完全可以對照領域模型，建模的過程也完全可以撰寫程式碼，並確保在最短的週期裡完成程式碼的設計與修改。 程式碼調整如下： Domain Layer 的程式碼 public interface IAggregateRoot { } public class Entity { } public abstract class ValueObject { } // 票卷實體 public class Ticket: Entity, IAggregateRoot { ...

軟體架構設計：有『題』- API 設計原則以『線上售票系統為例』 前言 先前，我有篇文章是以讀過【Get Your Hands Dirty on Clean Archiecture】後的心得感想，這本書的中文名稱是：【Clean Architecture 實作篇：在整潔架構上弄髒你的手】，讀完這本書大約是去年 2022/10 月左右，也是我當時在開發 API 新版框架大爆發的時候，書中給我不少的啟發，在配合實際的專案開發的實作經驗 + 框架設計所需要的框架設計便引入六角架構的設計方式，藉以改良原有的舊版的框架，而這篇『 軟體架構設計：無題 ( http://gelis-dotnet.blogspot.com/2022/08/blog-post.html )』中便是以完整的〔六角架構 (Hexagonal Architecture)〕並加以解釋如何在六角架構中落實單元測試 Unit Test，這些都是我讀完書後，實際落實在專案上的實際做法 + 分享。 當時的六角架構 + Unit Test 的範例程式在這： https://github.com/wugelis/AdapterInOutLayerSapmle 上次是無題，今天，我以一個X宏線上售票系統為例子，我們從頭到尾地的，Step By Step 的來介紹，這個 API 售票系統的建置過程，而這裡，我也會搭配 『API 設計原則』一書裡的一些做法，也就是說，這裡開發的 API 會使用 API First 的設計樣式，因為這裡的 API 設計的出發點為該企業、在這個商業模式上所能夠提供之『商業能力』回出發點考量，而不是過往傳統的單一客戶(UI)思維的客製化模式考量，所謂的 API First 是轉向為產品化思惟的導向模式，如此也才能發揮 API 在市場上的價值，這也才是 API First 的思維模式。 需求來源 圖（一）、線上售票系統需求 今天的需求來源，是一個線上售票系統，先前我曾在專案中製作過一個售票系統的雛形，這裡我就拿這個範例來以 DDD 來進行戰略建模，並搭配使用我在新竹顧問時所開發的新版 API Framework 來實作並支撐這個售票系統 API 的 Infrastructure Layer，沒錯，所以言下之意，我們以 DDD 來驅動這個售票系統 API 的開發，所以這裡的 Core...

為什麼開發人員總是會產生過度設計的程式碼？ 問題的來源 什麼是過度設計？開發人員為什麼會過度設計？過度設計與預先設計有什麼關係？過度設計是最終導致的結果，而預先設計無非是想讓軟體的程式碼撰寫落在刀口上，減少時間的支出來產生可交付的程式碼。但是這件事情好像沒這麼簡單？即便談需求的是我，我還是會有過度設計的程式碼產生，為什麼回如此呢？但這樣真的完全不好嗎？ 會產生過度設計可能有以下幾個原因。 分析時間過久 以前筆者曾提過傳統的瀑布式容易造成分析時間過長，最終就導致過度的設計而不自知，撰寫程式碼時因為關起門來寫，一些就是 3 個月或半年，脫節的需求產出的程式碼可能大部分不是客戶要的，這也是種過度設計，只是大部分設計出不正確的程式碼。 這會產生比較嚴重的反效果，一個是因為需求的脫節，即便抓回方向，但錯誤的設計已經使系統長歪，要修復往往非常的耗時耗力，甚至打掉重練比較快的情況也可能發生。 搞不清楚客戶說什麼 所謂隔行如隔山，軟體公司常只接針對特定領域的專案，或熟悉的領域進行客製化，好比筆者10幾年前曾待過專接流通業的 SI 公司，突然接金融電信領域的專案通常前 1-2 個失敗機率極高，為什麼，因為不熟悉這個產業的通用語言。然而這樣的接案就是極高的風險，筆者甚至分享以前遭遇到的經驗，曾經有同行求救於我們公司，他們因為不熟悉該領域硬是接下後無法收尾，而求助於我們公司熟悉金融領域的部門，當然，最後我們也沒有答應協助收這個爛攤子。 所以，Gelis 認為，搞清楚客戶說什麼常重要，在三地確認客戶腦袋的想法也很種要。 需求不明確 有可能需求訪談客戶主事者不在，或者具備決定權剛好不在、又或者客戶因為處於新員交接、正在熟悉此業務，所提需求自然諸多漏洞 + 沒想清楚。這筆者就曾遇過客戶端兩位經理在訪談會議時爭吵需求執行內容，讓在場的廠商非常傻眼，很想請他們去廁所打一架看誰贏了，我就做哪一個需求。 或者純粹是使用者想太多，想變更需求。或者自己搞不懂自己想要什麼，這比較常見。 也有可能開發團隊最後自己腦補，產生了一些設計，結果最後又不同於客戶確認的規格內容，這也是種過度設計，因為你設計了一堆不需要的架構內容。 如此一來，程式碼修修改改，不產生技術債都難。 保留設計 這接續前面的需求不明確，就因為需求不明確，所以開發人員就做了許多『預先設計』的保留，...