搬家公告

現在 Gelis 新的文章會以點部落的為主，下面為新的網址：
http://www.dotblogs.com.tw/gelis/
兩處新舊文章都歡迎各位能夠多多支持。感謝各位啦 :)

留言

張貼留言

這個網誌中的熱門文章

再談XAML與WPF

圖片
撰文：吳俊毅 時間：2009/6/11 在筆者先前討論過XBAP應用程式後再一次回到WPF的主題，在這個章節中筆者要說明XAML與WPF之間的關係，讀者先往下看幾個主題。 1. 再談XAML 什麼是XAML呢，XAML是(eXtensible Application Markup Language)的簡稱，XAML發音為”zammel”，而XAML為一種標籤語言，關於這個部分市面上許多書籍都已經講過太多了筆者快速的帶過就好，簡單的說XAML承襲XML的Well-Format文件的所有特性，在這裡微軟透過XAML描述並呈現WPF應用程式的外觀，它可以設置.cs的後置檔，程式的事件與運算邏輯可由後置檔案完成，WPF可在<Window>標籤內的x:Class=”命名空間.類別名稱” 如下： <Window x:Class="WpfHelloWorldApp.Window1"> </Window> 當然XAML檔案不一定要有後置檔，如上程式若去除掉x:Class=”WpfHelloWorldApp.Window1” 的敘述即表示沒有後置檔案，而通常沒有後置檔的XAML程式碼通常稱為loose XAML(鬆散的XAML)，這種檔案通常只是將XAML當做文件來使用，如XPS Document或WF的Flow Document文檔等，而XAML檔案執行時會預先被編譯成BAML(Binary Application Markup Language)的二進位直接檔案，但它是一個副檔名為.g.cs的檔案，在使用正式版本的Visual Studio IDE工具後您通常無法在檔案總管中察覺這個檔案的存在，若您在InitializeComponent()點選右鍵a”移至定義”所看到的程式內容便是IDE工具(auto-generated)自動產生的BAML內容，它會在obj\Debug 下產生，而同樣是一個繼承Window的類別，只是會多實作IComponentConnector介面，在InitializeComponent() 中會透過System.Windows.Application.LoadComponent()方法將XAML的內容讀取進來，筆者擷取一段BAML範例內容如下： public partial class Window...
閱讀完整內容

AI 時代的軟體架構設計的進化之路（二）

圖片
AI 時代的軟體架構設計的進化之路（二） 文章目錄 前言 AI 對軟體架構設計的影響 如何讓 AI 來遵循 UML 軟體設計方法論 Methodology 的設計規則 把 Scenario 轉換為 prompt (精華篇) 結語 前言 在前一篇文章 【 AI 時代的軟體架構設計的進化之路（一） 】中，我們探討了 AI 對軟體架構設計的影響，當時，我解釋了軟體在時做過程中，系統分析與設計的過程是幫助我們工程師思考的一個重要過程，因為這個過程才能夠幫助我們客戶的需求合理或不合理之處、理解最佳的系統設計的 boundary 那個界線在哪裡？如何將目前的『需求』實作到最佳恰到好處？ AI 對軟體架構設計的影響 現階段的 AI 或 GAI 工具嚴格來說，都還僅限於副駕駛 Copilot 的角色，但是軟體在設計的過程中得執行許多決策，且軟體開發的過程中並不是只有撰寫程式，更多的是『溝通』、『協作』、『解決問題』，單純的撰寫程式可能只占整體軟體開發生命週期所有大小事情中不到 20% 的工作量，當然也還包刮了測試、部署、維運等工作。然而，大部分的工作均需要開發人員進行『思考』與規劃，但是規劃這件事情需要考量的不單就只是如何實作，可能也包括了『團隊成員Skills』、『客戶端執行環境』、『成本的限制與考量』、甚至是『如何與其他進行跨系統整合』、等...，而這些都是還是需要人來進行決策，與如何進行下一步的。 如何讓 AI 來遵循 UML 軟體設計方法論 Methodology 的設計規則 大約在 2025-08-15 左右，我開了一堂【AI 時代下的系統分析與設計】線上直播課程，課程大致上其實先前我的決戰 OOAD 系列課程 與 最新的 API Framework 框架開發V2 課程的延伸，雖然我會在課程中使用 AI 工具 GitHub Copiplot，但重點仍就放在軟體建構過程中的各個環節點，比如從需求訪談到需求的擷取、也就是系統分析/設計）的過程，只不過，我讓 AI 來介入系統分析與設計的過程的環節點，而不只是與 AI 來 Pair-Programming 而已，我這樣做的目的是希望幫助軟體開發者不要停止思考，我記得，最近有看見 Continuous Delivery 一書的作者 David Farley 似乎也提到說 Vibe Coding 是本年...
閱讀完整內容

常見的程式碼壞味道（Code Smell or Bad Smell）

圖片
常見的程式碼壞味道（Code Smell or Bad Smell） 圖片取自：https://www.slideshare.net/ElMahdiBenzekri/art-of-refactoring-code-smells-and-microservices-antipatterns 前言 究竟重複的程式碼要不要共用它？傳統的軟體開發上，重複的程式碼幾乎被視為罪惡的來源，但是它真的有多可怕？ 常見的 Code Smells The Dispensable （一些可有可無的） Lazy Class (冗員類別） 如果一個類很少使用它會增加代碼庫的複雜性，從而阻礙開發。這樣的類可能是不必要的，它的功能可以成為另一個類的一部分。 Data Class (只有資料的類別） 一個類別只有包含『資料』未包含Methods，也就是說並未包含行為，不具行為模式的類別代表該『實例』容易被【其他類別所操控】。 Duplicate Code (重複的程式碼) 如描述，這也是上次有分享在我的 FB 社團 軟體開發之路［德國資深架構師給新手的建議］ 中有產生非常熱烈討論，這在社團朋友提醒下想起 Refactor 重構一書裡曾提過 rule of three 法則， 這個法則的定義是這樣的，有時部分程式碼重複其實是允許的（不是說重複一定是是被允許的）而是在某些 Context 情境下，該程式碼有一段時間不會衍伸別的功能 或 需求一段時間不會異動、且如要將它 DRY 會產生的『複雜度』或『花費時間』遠高於預估的時間 或 不值得在目前這個專案的節骨眼上花費這個時間來做這件事，加上它 DRY 產生的複雜度偶後產生的維護成本【遠高於】不 DRY 的情況下的維護本，那麼，在這個時候，這個異動頻率【極低】的程式碼就不需要花費這個時間來 DRY 了！！ 因為重點在於，重構是需要『成本』的。(迷之音：DRY 是種抽象化阿~😎) 這讓我想起之前，大約在 2016 年左右，在 101 的樓上某金融業客戶，曾經做過一個專案，這個專案就是因為客戶 DMZ 環境的因素，我讓內網的 Webside 與 DMZ 的網站保留了部分重複的程式碼，因為這段程式碼終年不需要異動，我也懶得花這個時間，而我居然也忘了這記件事情了.. 哈哈 Orz 不過原歸正傳，我個人還是認為，其實適當...
閱讀完整內容