.NET Walker

AOP（Aspect-Oriented Programming，剖面導向程式設計）是一種軟體開發方法論，其主要目的是將商業邏輯(Business Logic)和橫切關注點（Cross-Cutting Concern, 例如 Logging, Permission , Exception Handling…etc.）分離出來，進而使系統更加職責清晰、易於維護和擴展。 在AOP中，橫切關注點被稱為切面（Aspect），切面是一種跨越多個物件和方法的模塊化程式碼，用來實現特定的橫切關注點。在AOP中，我們可以將切面應用(Apply)到一個或多個類或方法上，從而實現這些類或方法的橫切關注點。 AOP的主要概念是，若能將橫切關注點從主要商業邏輯(Business Logic)中分離出來，即可達到降低耦合、提高軟體重用性的效果。 舉例說明 首先來整理一下這個命題，我們知道AOP想把Business Logic和Infrastructure Logic做一個切割，達成cross-cutting concerns的獨立性，但這樣講很抽象，具體情境是什麼呢？ 看底下這一段code: using System ; namespace testAOP { class Program { static void Main ( string [ ] args ) { //建立BMIProcessor物件 BMIProcessor BMI = new BMIProcessor ( ) ; BMI . Height = 170 ; BMI . Weight = 70 ; //計算BMI var ret = BMI . Calculate ( ) ; //顯示 Console . WriteLine ( $ "BMI : {ret}" ) ; Console . WriteLine ( "Press any key for continui

這一篇文章，照說應該接在之前寫過的 這篇 之後。但沒想到是，上一篇已經是 2020年的事情! 這連載也間隔太久了，哈。 在理解了DI的原理，並且知道注入的做法之後，我們繼續往下看，如果要動態實踐注入，該如何進行? 先前我們看到的程式碼中的注入，都是修改 program.cs 中的 AddTransient 來進行的，例如: serviceCollection . AddTransient < ISalaryFormula , SalaryFormula > ( ) ; 但如果我們想對 ISalaryFormula 這個介面，動態注入實作的類別，但不想改程式碼，可以怎麼做呢? 沒什麼複雜的，就是使用設定檔 appSettings.json，例如，我們可以建立這樣的配置： { "MyServiceConfig": { "MyServiceType": "consoleDI.SalaryFormula" } } 其中以字串描述了一個類別的路徑(NameSpace.ClassName)，例如: “consoleDI.SalaryFormula” 如果要額外描述在哪一個組件(.dll)內，路徑則是 “NameSpace.ClassName, DllName” 有了設定之後，我們在主程式中，加入讀取該設定的程式碼(底下7-12行): public class Program { //這裡才是真正的進入點 main static void Main ( string [ ] args ) { //讀取appsettings.json中的設定，決定用哪一個類別實作 IConfiguration config = new ConfigurationBuilder ( ) . SetBasePath ( Directory . GetCurrentDirectory ( ) ) . AddJsonFile ( "appsettings.json" , optional : false )

這是一個我很久以前就想實現的功能。 儘管Azure DevOps的Pipeline本身可以搭配WebHook，依照監聽的事件掛上各種通知，但相對來說比較不直覺，如果能夠在 Pipeline 中，直接透過某個Task來發送LINE通知，會方便很多。 使用的情境很廣，你可以在自動化建置(Build)或佈署(Deploy)的過程中，將成功與否的狀態，直接通知某一個群組或個人(主管、團隊Leader)，並且留下紀錄。 我們採用 LINE Notify 最主要的原因是 – 迅速、免費。 LINE 這個 App 在台灣幾乎每台手機上都有安裝，沒有人沒有LINE。速度甚至比簡訊還快，所以作為通知方式是相當有效的。 申請 Token 來發送 LINE Notify 訊息 要發送 LINE Notify 訊息，其實很簡單。 任何人(只要你有LINE帳號)，都可以到底下網址 https://notify-bot.line.me/ 免費建立一個 Token ，即可透過程式碼以自動化的方式發送訊息到你的LINE帳號，或是你指定的群組。 建立 LINE Notify Token 的方式如下： 如果要發送到群組，記得要將 LINE Notify 這個帳號邀請進入群組中，將來，訊息會透過統一的 LINE Notify 帳號發到你的 App 中，收到時類似底下這樣。參考上面的影片，下圖中的【test20230408】，就是你在建立權杖時候設定的名稱。 而自動化發送訊息方式，原本得透過 Rest API，相關的文件在底下: https://notify-bot.line.me/doc/en/ 寫程式當然比較麻煩，筆者為 LINE Notify 做了一個 Azure DevOps Task，有了 LINE Notify Task之後，就可以直接在 Azure DevOps Pipeline 中發送。 使用 LINE Notify Task 現在，你可以透過使用該 Task 直接在Pipeline中發送訊息: 該Task安裝位置如下: https://marketplace.visualstudio.com/items?itemName=tw-developer.LineNotify 你可以透過上面位置來安裝到組織中。 安裝好之後，即可直接在Pipeline

趁著假日，今天來談談『使用AI(ChatGPT)對PR進行code reivew』這個話題。 這次我們談的code review，是指… 開發人員針對feature branch要merge回主線(master)前，所發出的PR(Pull-Request)，在該PR中，常常會指定團隊中特定的資深開發人員(或Leader)，針對修改的部分(就是PR所關聯的change內容，也就是feature branch中的commit)所進行的code review。 過去，這一段基本都採人工在送出PR之後進行的，請看底下這個GitHub Flow的圖： 一般來說，這個code review動作發生在上面框出的這一段。 後面那隻松鼠是什麼呢? 這邊是指PR-CI，也就是PR所觸發的CI Pipeline，一般而言，我們會在這個Pipeline當中，針對差異部分(這次PR修改的部分)做靜態程式碼掃描(code analysis)、單元測試(UT)…等動作，這個動作和上面框出的code review，往往會同步(甚至提前)進行。 如此一來，人工code reivew的時候，如果發現PR-CI的build沒過(或是UT沒過)，那根本不用繼續 review 了，直接退回重改即可。 而現在我想談的『使用AI(ChatGPT)對PR進行code reivew』這個部分，就是採用ChatGPT(嚴格來說是Azure Open AI API)對於PR中差異部分的(這次PR修改的部分)進行 自動化code review 。 如何觸發自動化code review 由於ChatGPT的出現，我們可以透過AI對程式碼進行code review，而在Azure DevOps當中，只需要加入一個套件即可，該套件位於: https://marketplace.visualstudio.com/items?itemName=tw-developer.GPTPRReviewer 是一個免費套件。(但當然你OpenAI API呼叫多了是要錢的) 自動化code review，主要是針對PR中修改的部分，而非所有的程式碼，這很合理，否則每次CI Pipeline就會跑亂久了。針對差異掃描，並且頻繁簽入，才是正解。 也因此，你必須先具備底下條件: 設計一個在PR進行時，會被觸發的P