dijkstra很早就得出的結論是:程式設計是一項難度很大的活動。一段程式無論複雜與否，都包含了很多的細節資訊。如果沒有工具的幫助，這些細節的資訊是遠遠超過乙個程式設計師的認知能力範圍的。而在一段程式中，哪怕僅僅是乙個小細節的錯誤，也會造成整個程式出錯。
dijkstra提出的解決方案是採用數學推導方法。他的想法是借鑑數學中的公理、定理、推論和引理，形成一種歐幾里得結構。dijkstra認為程式設計師可以像數學家一樣對自己的程式進行推理證明。換句話說，程式設計師可以用**將一些已證明可用的結構串聯起來，只要自行證明這些額外**是正確的，就可以推導出整個程式的正確性。
既然結構化程式設計正規化可將模組遞迴降解拆分為可推導的單元，這就意味著模組也可以按功能進行降解拆分。這樣一來，我們就可以將乙個大型問題拆分為一系列高階函式的組合，而這些高階函式各自又可以繼續被拆分為一系列低階函式，如此無限遞迴。更重要的是，每個被拆分出來的函式也都可以用結構化程式設計正規化來書寫。
一詞為理論基礎，在20世紀70年代晚期到80年代中期出現的結構化分析與結構化設計工作才能廣為人知。
通過採用這些技巧，程式設計師可以將大型系統設計拆分為模組和元件，而這些模組和元件最終可以拆分為更小的、可證明的函式。
大部分人不會真正按照歐幾里得結構為每個小函式書寫冗長複雜的正確性證明過程。
沒有幾個程式設計師會認為形式化驗證是產出高質量軟體的必備條件。
形式化的、歐幾里得式的數學推導證明並不是證明結構化程式設計正確性的唯一手段。
科學和數學在證明方法上有著根本性的不同，科學理論和科學定律通常是無法被證明的，譬如我們並沒有辦法證明牛頓第二運動定律f=ma或者萬有引力定律f=gm1m2/r的二次方是正確的，但我們可以用實際案例來演示這些定律的正確性，並通過高精度測量來證明當相關精度達到小數點後多少位時，被測量物件仍然一直滿足這個定律。但我們始終沒有辦法像用數學方法一樣推導出這個定律。而且，不管我們進行多少次正確的實驗，也無法排除今後會存在某一次實驗可以推翻牛頓第二運動定律與萬有引力定律的可能性。
這就是科學理論和科學定律的特點:它們可以被證偽，但是沒有辦法被證明。
最終，我們可以說數學是要將可證明的結論證明，而與之相反，科學研究則是要將可證明的結論證偽。
dijkstra曾說過」測試只能展示bug的存在，並不能證明不存在bug」，換句話說，一段程式可以由乙個測試來證明其錯誤性，但是卻不能被證明是正確的。測試的作用是讓我們得出某段程式已經足夠實現當前目標這一結論。
軟體開發雖然看起來是在操作很多數學結構，其實不是乙個數學研究過程。恰恰相反，軟體開發更像是一門科學研究學科，我們通過無法證偽來證明軟體的正確性。
結構化程式設計正規化促使我們先將一段程式遞迴降解為一系列可證明的小函式，然後再編寫相關的測試來試圖證明這些函式是錯誤的。如果這些測試無法證偽這些函式，那麼我們就可以認為這些函式是足夠正確的，進而推導整個程式是正確的。
結構化程式設計正規化中最有價值的地方就是，它賦予我們創造可證偽程式單元的能力。
這就是為什麼現代程式語言一般不支援無限制的goto語句。更重要的是，這也是為什麼在架構設計領域，功能性降解拆分仍然是最佳實踐。
無論在哪乙個層面上，從最小的函式到最大的元件，軟體開發的過程都和科學研究非常類似，它們都是由證偽驅動的。軟體架構師需要定義可以方便地進行證偽(測試)的模組、元件以及服務。為了達到這個目的，他們需要將類似結構化程式設計的限制方法應用在更高的層面上。
《架構整潔之道》之函式式程式設計
函式式程式語言中的變數是不可變的。為什麼不可變性是軟體架構設計需要考慮的重點呢？為什麼軟體架構師要操心變數的可變性呢?答案顯而易見 所有的競爭問題 死鎖問題 併發更新問題都是由可變變數導致的。如果變數永遠不會被更改，那就不可能產生競爭或者併發更新問題。如果鎖狀態是不可變的，那就永遠不會產生死鎖問題。...
《架構整潔之道》之程式設計正規化總覽
結構化程式設計是第乙個普遍被採用的程式設計正規化 但是不是第乙個被提出的 由edsger wybe dijkstra於1968年最先提出。與此同時，dijkstra還論證了使用goto這樣的無限制跳轉語句將會損害程式的整體結構。結構化程式設計正規化歸納 結構化程式設計對程式控制權的直接轉移進行了限制...
《架構整潔之道》之元件聚合
軟體復用的最小粒度應等同於其發布的最小粒度。從軟體設計與架構設計的角度來看，復用 發布原則就是指元件中的類與模組必須是彼此緊密相關的。也就是說，乙個元件不能由一組毫無關聯的類和模組組成，它們之間應該有乙個共同的主題或者大方向。從另乙個角度來看，這個原則就沒有那麼簡單。因為根據該原則，乙個元件中包含的...