結構化程式設計
Dijlstra 很早就認識到程式設計是困難的，任何複雜的城市都包含太多細節，人腦無法幫忙管理。Dijlstra 的解決方案是運用數學原理的證明 (proof)。認為可以像數學家那樣使用層次結構來證明程式是對的。他發現 goto 語句的某些使用方式會阻止模組遞迴地被分解成越來越小的單元，會導致無法使用分而治之 (divide-and-conquer) 的方法來進行合理的證明。
Böhm 和 Jacopini 證明了所有的程式都可以使用三種結構建構出來：
- 循序 (sequence)
- 選擇 (selection)
- 迭代 (iteration)
這個卓越的發現：
構成可證模組的控制結構就是「可建構所有程式的控制結構」的最小集合。
1968 年，Dijlstra 發表了一篇「Go TO 被認為是有害的」。現在，我們都是結構化的程式設計師，雖然不一定是你選擇的。只是因為我們的語言無法讓我們選擇使用無條件直接轉移控制。
哭哭，又被拔掉一個能力了（笑ＸＤ
功能分解
結構化程式設計允許將模組遞迴地分解成可證明的單元。你可以把一個大規模的問題陳述，分解成高級別的功能，這些功能可以在分解下去…
曾有正式的證明
但是證明重來沒有被完成過。歐幾里德定理層次從來沒有被真實建立起來。當然，正式的歐幾里德風格的數學證明並不是唯一策略，另一個非常成功的策略是科學方法
這段不是很懂ＱＱ，感覺是要描述如果要真的證明程式是對的，應該要有一篇論文等級的數學證明。
依靠科學
科學與數學在根本上是不同的，因為科學的定理和定律無法用證明來表達其正確性。這就是科學定理和定律的本質：他們是可證偽的 (falsifiable)，但不是可證明的。科學並非是要證明陳述是正確的，而是要證明陳述是錯誤的
數學是要證明「可證明陳述是真實的」。相反地，科學是要證明「可證明陳述是虛假的」。
測試
測試顯示了錯誤的存在，而不是沒有錯誤。經過充分的測試後，這些測試可以讓我們認為程式對我們來說是足夠正確的。這種證明不正確的方式只能用於可證的程式。一個不可證的程式(例如，無限制使用 goto)不能被認為是正確的，不管他被進行過多少次測試。
如果這些測試不能證明他們是不正確的，那麼我們就可以認為這些功能對於我們的目標來說是正確的
總結
正式能建立「可偽證的程式設計單元」的能力，使得今天的結構化程式設計變得有價值。在架構層面上，「功能分解」是我們最佳的實戰技巧之一。
原來我們寫得那麼開心的結構化程式是這樣來的呀ＸＤ。不過實務上，測試很難寫的很完整，當然會擔心漏掉什麼，但漏掉了就補上去，下次再發生錯誤的機率就會降低了！
