發表文章

目前顯示的是 4月, 2023的文章

在 .net core 中實現AOP

圖片
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

使用IoC與DI有何意義? (五) 透過設定實現注入

圖片
這一篇文章,照說應該接在之前寫過的 這篇 之後。但沒想到是,上一篇已經是 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 CI CD Pipeline中直接發送LINE通知訊息

圖片
這是一個我很久以前就想實現的功能。 儘管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

圖片
趁著假日,今天來談談『使用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