結構化程式設計是三大典範中最早被提出的。
它由 Edsger W. Dijkstra 倡導，核心精神在於限制「直接的控制移轉」。
一、消除 GOTO：建立控制的秩序#
早期組合語言時代，程式設計師可以隨意使用 goto 語句跳轉指令。
這導致程式結構像義大利麵一樣混亂，無法被拆解與分析。
Dijkstra 發現，如果要讓程式能被人類大腦理解，我們必須限制控制流程。
他提出所有程式都可以（且應該）只用三種結構來建構：
- 循序 (Sequence)： 一行接一行執行
- 選擇 (Selection)：
if/else/switch - 迭代 (Iteration)：
do/while/for
- 拿走什麼： 無條件跳轉 (Unrestrained goto)
- 留下什麼： 一個有秩序、可預測的控制流程
二、架構上的意義：功能分解#
結構化程式設計對架構最大的貢獻，
在於賦予我們 遞迴分解（Recursive Decomposition） 的能力。
- 拆解大問題： 由於程式不再隨意亂跳，我們可將一個龐大系統，拆解成幾個高層次模組
- 層層向下： 高層次模組又可以拆解成更小功能，直到拆解成最底層函數
- 結果： 形成我們今天熟悉的「模組化」開發。無論系統多大，都能有條理地組織起來
三、科學與數學：證偽的力量#
Dijkstra 最初希望軟體能像數學被「證明（Provable）」是正確的（Euclidean hierarchy）。
但事實證明這在複雜系統中極難實現。
最終，軟體開發走向了 科學（Science） ，而非數學的道路。
- 數學： 追求證明一命題為 真（True）
- 科學： 追求證明一命題為 假（False）（可證偽性）。
我們透過實驗試圖推翻定律，如果推翻不了，就暫時相信它是對的
測試的本質：
Dijkstra 曾說：「測試只能證明程式有錯（Bugs），無法證明沒錯。」結構化程式設計讓我們將程式拆解成小單元，並撰寫測試案例（科學實驗）來試圖「證偽」它。
如果測試充分卻無法證偽（讓程式出錯），就認為該功能對當前目的是 足夠正確（Correct enough）
結構化程式設計不僅是寫 code 的規範，更是軟體架構中「功能拆解」與「測試驗證」的基石。
它讓我們能以科學方法，確保每個被拆解的小功能皆能正常運作。