IT [碎碎念] 關於軟體開發 - 學習之路

IT [碎碎念] 關於軟體開發 - 學習之路閱讀全文


from 點部落-gelis 技術隨筆 http://ift.tt/1Go5tW5

留言

張貼留言

這個網誌中的熱門文章

再談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 是本年...
閱讀完整內容

軟體工程師 - 成長的 10 個階段

圖片
軟體工程師 - 成長的 10 個階段 前言 先前，我在 Study4 小聚 #6 分享的一場關於軟體工程師 & 架構設計的養成之路，在該議程中，我分享了軟體工程師的 10 個階段（你的階段如有雷同、應該是...純屬巧合。XDDD） 哪 10 個階段？ 我將軟體工程師的成長依序分為 10 個成長階段，因為隨著技能的提升，你該擴充的 不會只是只有軟體開發技術，溝通與協作能力尤其重要 ，也像是『康威定律』中所提到的， 你的軟件的設計 & 或系統設計本質上反映了企業的組織機構。系統各個模塊間的介面的設計，也反映了企業各個部門之間的信息流動和合作方式，這些技能再進行軟體架構設計時也息息相關 ，團隊在進行模組設計時需要頻繁的溝通，這些、都是是否能將軟體做好的關鍵因素。 如 Logo 圖片，我依序說明每個階段的成長歷程。 1). 初始開發階段、熟悉 Programming/Developer 階段（PM/PO/SD 給規格後加以實作出來），並能夠藉由 模仿 來學習。這是剛進入軟體產業的學習階段。 2). 此階段代表已懂得透過重構來讓程式碼有基本的可維護性 、已能熟用 DRY (Don't Repeat Yourself)，進入這個階段代表已經有基本的程式語言的基礎， 應付 Programming/Developer 日常 工作 上的需求基本上沒什麼太大的問題。 3). 這裡的專案收尾代表對於專案開發已經有某些程度的認知、掌握度。我所提的掌握度在於了解『技術債』的產生緣由 與 危害，在 Programming/Devloper 層面懂得透過 S.O.L.I.D./Design Patterns 解決問題 並 開始能夠 自我學習 + 自我成長 。 4). 我這裡用『紀錄』 代表能運用所學 + 將使用者需求運用 〔邏輯思考〕 與 〔抽象化〕 轉化為程式碼 + 並能 自我成長 將經驗保存下來。我認為這是跨越只是（寫程式／實作）進入另一個門檻的重要經驗與歷練。 這個階段花費的時間會較長一點，時間長短取決於個人歷練、經歷、學習的環境與工作內容。 5). 此階段含括上面所有技能，並能夠與〔團隊〕和〔客戶〕 溝通 與 協作 、並產生出〔產品〕。而所謂的協作代表，不只自身技術所長能應付本身開發工作工作所需，亦能帶領團隊解決軟體專案的大小事務、也能夠替...
閱讀完整內容