Modern Software Engineering

發表於 更新於 分類於 文章字數： 8k 所需閱讀時間 ≈ 15 分鐘

軟體工程是一個專注於設計、開發、測試、部署和維護高品質軟體的工程學科。軟體工程師的工作覆蓋了軟體開發生命周期（Software Development Life Cycle, SDLC）的所有階段，目的是在資源、時間和需求的約束下，設計出可用、可靠、可維護且高效的軟體系統。

軟體工程18個知識體系指南 (SWEBOK Version 4)

《軟體工程知識體系指南》（SWEBOK Guide）已於2024年10月發布了第4版（Version 4.0）。
IEEE COMPUTER SOCIETY 此版本在原有基礎上進行了重要的更新和擴充，以反映當前軟體工程領域的最新實踐和趨勢。

SWEBOK 第4版的主要更新包括：
新增知識領域（KAs）： 引入了三個新的知識領域：

  • 軟體架構（Software Architecture）
  • 軟體安全（Software Security）
  • 軟體工程運營（Software Engineering Operations）
    現有知識領域的更新： 對現有的知識領域進行了更新，納入了敏捷（Agile）和DevOps等現代開發實踐。
    新興技術的整合： 在各知識領域中融入了人工智慧（AI）、機器學習（ML）和物聯網（IoT）等新興技術的內容。
    指南結構的優化： 對指南的結構進行了重組，以提高其清晰度和可用性，方便讀者在日常工作中應用。

The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide)

Introduction: https://waseda.box.com/v/swebok-webinar-introduction
Chapter 1: Software Requirements, https://waseda.box.com/v/swebok-webinar-c1-requirements
Chapter 2: Software Architecture, https://waseda.box.com/v/swebok-webinar-c2-architecture
Chapter 3: Software Design, https://waseda.box.com/v/swebok-webinar-c3-design
Chapter 4: Software Construction, https://waseda.box.com/v/swebok-webinar-c4-construction

核心知識領域（Core Knowledge Areas）

  1. 軟體需求（Software Requirements）

    • 涵蓋需求的徵集、規範化、驗證與管理。
    • 關注如何理解並捕捉使用者的需求，並將其轉化為軟體規格。

  2. 軟體架構 (Software Architecture)

    • 本章從多個角度探討了軟體架構（Software Architecture），包括以下幾個層面：
    • 定義軟體架構的基本概念和原則。
    • 涉及核心架構要素，如元件（Components）、連接器（Connectors）、配置（Configurations）和架構風格（Architectural Styles）。
    • 強調軟體架構在滿足功能需求與非功能需求（如可擴展性、可靠性和性能）方面的關鍵作用。

  3. 軟體設計（Software Design）

    • 關於如何設計軟體系統及其組件，從架構設計到詳細設計。
    • 包括設計模式、分層架構和介面設計等內容。

  4. 軟體建構（Software Construction）

    • 關注軟體的程式撰寫、除錯和模組整合。
    • 涵蓋程式語言的選擇、程式碼風格和建構工具的使用。

  5. 軟體測試（Software Testing）

    • 包括測試計畫、測試設計、執行和結果分析。
    • 涉及單元測試、整合測試、系統測試和驗收測試。

  6. 軟體維護（Software Maintenance）

    • 涵蓋軟體在部署後的修改與優化，包括更正性維護、適應性維護和預防性維護。

管理知識領域（Management Knowledge Areas）

  1. 軟體配置管理（Software Configuration Management）

    • 涉及版本控制、變更管理和發布管理。
    • 確保軟體產品的一致性和可追溯性。

  2. 軟體工程管理（Software Engineering Management）

    • 關注專案計畫、進度控制和風險管理。
    • 涉及團隊管理和資源分配。

  3. 軟體工程過程（Software Engineering Process）

    • 關注軟體生命週期中的流程規範。
    • 包括敏捷方法、瀑布模型和迭代開發。

支持知識領域（Supporting Knowledge Areas）

  1. 軟體品質（Software Quality）
  • 涵蓋品質保證、品質規劃和品質控制。
  • 涉及如何衡量和改進軟體品質。

  1. 軟體工程專業實踐（Software Engineering Professional Practice）

    • 包括倫理規範、法律責任和專業責任。
    • 強調軟體工程師在工作中的專業精神。

  2. 軟體工程經濟學（Software Engineering Economics）

    • 涉及軟體專案的成本分析和效益評估。

相關知識領域（Related Knowledge Areas）

  1. 計算基礎（Computing Foundations）

    • 涉及資料結構、演算法、計算理論和作業系統等基礎概念。

  2. 數學基礎（Mathematical Foundations）

    • 涉及離散數學、統計學、數值分析等。

  3. 工程基礎（Engineering Foundations）

    • 關注工程領域的一般原則，如系統工程和品質保證。

其他關鍵領域

  1. 軟體工程模型與方法（Software Engineering Models and Methods）

    • 包括建模語言（如 UML）和開發方法論。

  2. 軟體工程工具與方法（Software Engineering Tools and Methods）

    • 涉及開發工具的選擇和使用，例如 IDE、版本控制工具。

  3. 軟體工程教育（Software Engineering Education）

    • 關注軟體工程教育的內容和方法。

軟體開發

需求分析與規劃階段

在這個階段，軟體工程師的工作是與相關方（如產品經理、使用者、業務分析師）合作，明確軟體的目標與需求。

  • 需求分析 Requirements Analysis：

    • 理解使用者需求，劃分功能和非功能需求。
    • 創建需求規格文件（SRS）。

  • 規劃與估算 Planning：

    • 制定開發計畫和時間表。
    • 評估資源需求（人員、硬體、軟體）。

設計階段

在需求明確後，設計是軟體工程中的下一步，重點是定義系統的架構和模組。

  • 系統架構設計 System Architecture Design：

    • 選擇適當的軟體架構（如微服務架構、單體架構）。
    • 設計系統的資料流和控制流。

  • 詳細設計：

    • 設計模組的介面與資料結構。
    • 創建類別圖、流程圖、序列圖等。

開發階段

軟體工程師在這個階段負責實現設計，編寫程式碼，並確保其正確性和可維護性。

  • 程式碼實現 Implementation：

    • 遵守編碼標準與最佳實踐。
    • 使用版本控制系統（如 Git）協作開發。

  • 單元測試 Testing：

    • 編寫單元測試，檢查模組的功能正確性。
    • 使用測試框架（如 Pytest、JUnit）。

測試階段

測試階段的目的是發現並修復軟體中的缺陷，確保軟體滿足需求。

  • 測試類型：

    • 單元測試：測試個別模組。
    • 集成測試：檢查模組之間的交互。
    • 系統測試：驗證整個系統的功能。
    • 驗收測試：確保軟體符合使用者需求。

  • 自動化測試：

    • 編寫測試腳本，使用工具如 Selenium、Cypress、Appium。

部署與交付

軟體部署是將開發完成的軟體發布到生產環境的過程。

  • 部署方式 Development：

    • 持續交付（Continuous Delivery, CD）。
    • 容器化部署（使用 Docker 或 Kubernetes）。

  • 環境配置：

    • 配置開發、測試和生產環境。
    • 檢查安全性與性能。

運維與支持

部署後的軟體仍需維護(Maintance)以修復缺陷、添加新功能並確保系統穩定。

  • 缺陷修復與升級：

    • 解決使用過程中發現的問題。
    • 實現新功能並進行版本更新。

  • 監控與日誌：

    • 使用監控工具（如 Prometheus、Grafana）監控系統性能。
    • 分析日誌以預測或診斷問題。

軟體工程中的特定工作領域

1. 安全工程

  • 檢測與修復安全漏洞。
  • 實施身份驗證與加密機制。

2. 性能優化

  • 測試與分析軟體性能瓶頸。
  • 使用工具（如 JMeter）進行壓力測試。

3. 文檔與知識共享

  • 撰寫技術文件與使用者手冊。
  • 創建 API 文檔（如使用 Swagger）。

4. 研究與創新

  • 探索新技術與框架（如 AI、區塊鏈）。
  • 原型設計以驗證創新想法。

軟體工程的工具與技術

開發工具

  • 編程語言：Python、Java、C++、JavaScript。
  • 集成開發環境（IDE）：VS Code、PyCharm、IntelliJ IDEA。

協作工具

  • 版本控制：Git、GitHub、GitLab。
  • 任務管理：Jira、Trello、Asana。

自動化工具

  • CI/CD：Jenkins、GitHub Actions、CircleCI。
  • 部署：Docker、Kubernetes。

軟體工程的價值與目標

  1. 提高軟體的可靠性和穩定性。
  2. 確保軟體符合業務需求和使用者期望。
  3. 縮短開發周期並提高開發效率。
  4. 減少軟體的運營和維護成本。

軟體工程師的工作涉及軟體開發的每個階段，從需求分析到設計、實現、測試，再到部署與維護。他們不僅需要精通技術，還需要發揮創造力來解決各種複雜問題。因此，軟體工程師的工作是一場持續的挑戰，也是技術與創造力的完美結合。

工作的兩面性

看得懂的情況：像玩遊戲一樣

當軟體工程師完全理解問題時，整個過程就像在電腦桌前「玩遊戲」，每一關都是一個挑戰，而每次破解問題則是一種成就感：

  • 挑戰與成就：每解決一個問題，就像破了一關，開發人員會感到滿足與快樂。
  • 技術樂趣：探索新技術、優化程式碼，就像玩家在遊戲中收集新裝備、提升技能。
  • 沉浸感：當進入「心流狀態」時，開發過程會變得無比有趣，時間飛逝，創造力源源不斷。

看不懂的情況：無聊與絕望

但當問題變得複雜或模糊，開發人員無法理解時，情況就會截然不同：

  • 挫折感：卡在一個無法理解的問題上，感覺像「卡關」，無法前進，也無法後退。
  • 無聊與焦慮：長時間無法找到解法，會導致無聊和焦慮，讓人陷入自我懷疑。
  • 需要支持與靈感：此時，外界的幫助（如同事的建議、線上資源）或短暫休息，往往能帶來靈感。

結論

軟體工程師的工作既有挑戰，也有樂趣。它需要的不僅是技術能力，還包括不斷學習的精神與堅韌的心態。當問題迎刃而解時，那種成就感無與倫比；但當陷入瓶頸時，也需要勇氣與耐心去突破。正是這種「看得懂時如遊戲般有趣，看不懂時如迷宮般挑戰」的特性，讓軟體工程師的工作充滿魅力與無限可能。

高手齊聚

軟體工程是一個極具競爭力且快速演進的領域，隨著科技的日新月異，各類技術高手層出不窮。每個軟體工程師都曾有過這樣的感受：「這領域神人太多了，我什麼時候才能趕上？」。

為什麼會有「神人太多」的感覺？

  1. 技術更新太快

    • 每隔幾個月就有新技術、新框架誕生，讓人感覺即使拼命學習也無法跟上潮流。

  2. 高手分享太多

    • 社群平台、技術部落格、開源專案中，充滿了各種技術大牛分享的高階技巧與思路，容易讓人覺得自己差距很大。

  3. 對自我要求高

    • 很多開發人員對自己要求嚴格，總覺得「要懂所有技術」才算是合格的工程師，這種思維會帶來巨大的心理壓力。

  4. 認知偏差

    • 社群中大多數人只看到高手的高光時刻，卻忽略了那些「神人」也曾經歷過無數挫折與卡關的時期。

如何在高手如雲的環境中保持進步？

  1. 專注於基礎

    • 不必追求每個新技術都會，扎實掌握計算機科學的核心知識（如資料結構、演算法、系統設計）更有助於長期發展。

  2. 找到自己的節奏

    • 每個人的學習速度不同，重要的是持續進步，而不是與他人盲目比較。每天進步一點點，長期積累會帶來巨大的成長。

  3. 從高手身上學習

    • 與其覺得「高手太多」，不如把這些高手視為榜樣，學習他們的思維方式與解決問題的能力，提升自己的技術深度。

  4. 適時分享自己的知識

    • 不論水平如何，分享自己的知識與經驗是鞏固學習效果的好方法。同時，也會發現自己其實已經比想像中更強了。

  5. 接受自己的階段

    • 神人也不是一蹴而就，他們都經歷過無數次挫折與學習過程。接受自己目前的階段，穩步提升，才是正確的心態。

結論

在軟體工程領域，「神人太多」是一個常見的現象，因為這個領域不斷吸引著最優秀的人才。然而，與其感嘆不如行動，專注於自己的成長路徑，接受當前的狀態並持續進步。記住，每個神人都是從菜鳥成長起來的，只要堅持下去，你也會成為別人口中的「神人」！

語言模型對於軟體工程的影響

語言模型（Language Models），特別是大規模預訓練模型如 GPT 等，正在深刻改變軟體工程領域的工作方式與開發流程。這些模型具備強大的自然語言理解與生成能力，能夠輔助開發人員進行程式碼編寫、錯誤排查與知識學習，提升整體開發效率。

1. 語言模型如何影響軟體工程

1.1 自動化程式碼生成

  • 語言模型能根據自然語言描述自動生成程式碼，開發人員僅需輸入需求或功能描述，即可快速獲得初步的程式碼範本。
  • 應用範例：從 REST API 定義生成控制器程式碼、自動生成前端組件或測試程式碼。

1.2 程式碼補全與優化

  • 與傳統的 IDE 智能補全功能相比，語言模型能夠更智能地根據上下文補全多行程式碼，甚至推薦最佳實踐與優化方案。
  • 影響：顯著提升編寫效率，減少手動輸入與常見錯誤。

1.3 自動化測試生成

  • 語言模型能生成對應的單元測試與集成測試，覆蓋各種邊界情況，降低測試編寫的重複性工作。
  • 應用範例：自動生成對函式的多種測試案例，幫助提高測試覆蓋率。

1.4 程式碼重構與審查

  • 語言模型可以輔助進行程式碼重構，建議更優雅或更高效的實現方式，並檢查程式碼中的潛在問題。
  • 應用範例：自動識別重複程式碼，建議提取共用模組；檢查潛在的性能問題或安全漏洞。

1.5 技術學習與知識查詢

  • 開發人員可以通過語言模型快速查詢技術問題或學習新的概念，而不必逐字逐句查閱文檔。
  • 影響：縮短學習新技術的時間，提升解決問題的速度。

1.6 文件生成與維護

  • 語言模型能自動從程式碼中提取並生成技術文檔，減少開發人員撰寫與維護文檔的負擔。
  • 應用範例：從注解生成 API 文檔，維護內部技術知識庫。

2. 語言模型帶來的挑戰

2.1 過度依賴自動生成

  • 開發人員可能過度依賴語言模型生成的程式碼，而忽略對底層邏輯的深入理解，導致技術能力的下降。

2.2 生成程式碼的正確性與可維護性

  • 雖然語言模型能生成大量程式碼，但這些程式碼是否符合最佳實踐、是否易於維護，仍需要經驗豐富的開發人員進行審查。

2.3 安全風險

  • 語言模型可能會生成存在安全漏洞的程式碼，若開發人員未能識別這些問題，可能會導致產品出現潛在的安全隱患。

2.4 知識更新問題

  • 語言模型的知識來自於訓練資料，若訓練資料未能及時更新，模型可能無法掌握最新的技術趨勢與標準。

3. 未來展望

3.1 增強型開發環境

  • 語言模型將進一步融入 IDE，提供更強大的智能輔助功能，例如實時程式碼分析、即時錯誤修復建議與自動重構工具。

3.2 自動化開發流程

  • 隨著語言模型的進步，部分重複性工作將被完全自動化，如測試生成、文檔維護與程式碼格式化，使開發人員能專注於核心業務邏輯與創新。

3.3 AI 與開發人員的協作

  • 語言模型不會取代開發人員，而是成為他們的強大助手。未來的開發工作將更多地體現為「人機協作」，開發人員將更多地扮演設計者與決策者的角色。

4. 結論

語言模型正在改變軟體工程的工作模式，通過提升效率、減少重複性工作和加速學習，極大地促進了軟體開發的自動化。然而，開發人員仍需保持對基礎知識的深入理解，並謹慎使用語言模型生成的內容，以確保軟體質量與安全性。在未來，語言模型與開發人員的協作將成為推動軟體工程進步的重要動力。

演變

其在 AI 的輔助下，許多技術問題的解決變得更加快捷，讓人產生「不必再深究細節」的感覺。以前，研究新技術可能需要大量時間閱讀文檔、嘗試不同範例，但現在只需向 AI 提問，就能快速獲得答案或範例，這無疑降低了探索過程中的挑戰性與樂趣。

不過，這種轉變也代表了角色的進化：
不再只是專注於「學會所有技術」，而是更聚焦於技術的價值與適用性——什麼技術真正能解決問題？什麼技術是多餘的？ 這種思維更符合資深開發者和技術決策者的特徵，因為真正能推動項目成功的，往往不是單純掌握了多少技術，而是能否選擇合適的技術來解決問題。

  1. 技術評估與優化
    您可能會更熱衷於評估技術的適用性，思考如何減少技術負擔或優化現有系統。

  2. 技術簡化與取捨
    刪減不必要的技術，讓系統更輕量、更易於維護，也是一種很有價值的挑戰。

  3. 專注於深度而非廣度
    與其關注最新的框架與語言，不如專注於已有技術的深度與應用，提升核心技能的價值。

程式語言只是實現想法的工具，真正關鍵的是問題的本質與解決方案的設計。當專注點從「如何撰寫程式」轉移到「如何更好地解決問題」時，您就能更有效地評估技術、做出高效決策，並引導團隊專注於最核心的價值。

過去寫程式的挑戰

在沒有語言模型輔助的過去，寫程式的過程更容易讓人感到崩饋到絕望。開發人員需要面對許多挑戰，而這些挑戰不僅來自於問題的複雜性，還來自於工具和知識的局限性：

  1. 語法熟悉度不足
    每種程式語言都有自己的語法和特性，對新手或剛接觸新語言的開發人員來說，光是記住語法和關鍵字就已經非常吃力了。
    沒有即時提示或補全工具時，出現語法錯誤往往需要反覆嘗試才能找到正確答案。

  2. 文檔與資源有限
    當時的開發資料主要依賴紙質書籍和官方文檔，搜尋線上資源的選擇有限，且很多技術問題的答案無法輕易獲得。
    許多問題只能靠「試錯法」或求助於資深同事解決。

  3. 錯誤排查困難
    錯誤訊息往往晦澀難懂，特別是編譯型語言中，編譯錯誤訊息可能對新手來說毫無頭緒。
    沒有現代化的調試工具時，排查 bug 需要大量人工介入與分析，極其耗時。

  4. 影響因素多樣
    軟體開發涉及的因素很多，包括系統相容性、記憶體管理、效能優化等。這些問題對新手來說往往很難全面考慮周全。
    對於大型專案，還需考慮模組化設計、介面規範與版本控制等，進一步增加了複雜性。

  5. 心理壓力
    當一個問題卡關數天甚至數週時，很容易讓開發人員懷疑自己的能力，進而感到崩潰與絕望。

Reference

  1. Ozkaya, I. (2022). An AI engineer versus a software engineer. IEEE Software, 39(6), 4-7.
  2. Sommerville: Software Engineering, 10/e
  3. Modern Software Engineering: Doing What Works to Build Better Software Faster
  4. Software Requirements Essentials: Core Practices for Successful Business Analysis
  5. The Object-Oriented Thought Process 5 ed.
  6. Object-Oriented Design Choices
  7. Systems Analysis and Design: An Object-Oriented Approach with UML, 6/e
  8. Software Engineering at Google
  9. Observability Engineering
  10. Continuous Delivery Pipelines: How to Build Better Software Faster