為什麼結構化程式設計、面向物件程式設計、軟體工程、架構設計最後沒有成為軟體領域的銀彈
為什麼結構化程式設計、面向物件程式設計、軟體工程、架構設計最後沒有成為軟體領域的銀彈？
從計算機語言開始講，一步一步的概述和講解，最終會有一個結論，大家往後看，即可明白。
1.機器語言(1940年之前)
機器語言，直接使用二進位制碼0和1來表示機器可以識別的指令和資料。
比如0100011111000010101,請問你知道是什麼意思嗎?反正我是不知道。
當然了，不可否認的是機器語言是最底層與CPU直接互動。
機器語言之所以沒有流行下來，原因三個方面:
(1)太難讀了;
(2)太難寫了;
(3)太難改了(萬一因為0和1之間位置偏差導致程式出錯，那真的會讓人哭死);
當然了，機器語言並非沒有優點，它的優點就是快，天下武功唯快不破。
2.組合語言(20世紀40年代)
為了解決機器語言太難寫了、太難讀了、太難改了等三個缺點，於是，組合語言應運而生。
例如:
機器語言:1000001001000111111
組合語言:mov ax,bx
相比機器語言來說，組合語言要清晰的多。比如mov是移動(move）,ax和bx是暫存器的代號。
組合語言解決了機器語言難讀難寫難改的缺點，當然了，它也有它的不足，比如我們必須精確地瞭解和熟悉計算機底層知識。
關於計算機知識的書，有一本比較通俗的讀物，但是也不算是通俗，那本書的名字叫做《計算機文化》
對於計算機的基礎知識描繪十分系統和詳細，建議大學生或者是開發經驗比較穩固但是計算機基礎知識欠缺的朋友可以看看，我就時不時翻閱一下，這本書，我對此的閱讀方法是:
(1)有選擇的閱讀，不要從頭開始翻(我第一次讀的時候，差點讀著就睡著了，因為覺得太過乏味，後來有選擇的看看，基本翻完了70%);
(2)你可以嘗試快速從頭開始翻，感興趣的可以花點時間仔細看看，不感興趣的，直接跳過;
總而言之，每個人都有每個人獨特的閱讀方式。
關於這本書的章節大概，我列出一下，大家可以做個參考。
一共十二章:
第一章 計算機和數字基礎知識
A部分:一切數字事物
B部分:數字裝置
C部分:數字資料顯示
D部分:數字化處理
E部分:密碼安全
第二章 計算機硬體
A部分:個人計算機基礎知識
B部分:微處理和記憶體
C部分:儲存裝置
D部分:輸入和輸出裝置
E部分:硬體安全
第三章 計算機軟體
A部分:軟體基礎知識
B部分:辦公套件
C部分:軟體安裝和升級
D部分:購買軟體
E部分:安全軟體
第四章 作業系統和檔案管理
A部分:作業系統基礎知識
B部分:現代作業系統
C部分:檔案基礎知識
D部分:檔案管理
E部分:備份安全
第五章 區域網
A部分:網路構建基礎
B部分:有線和無線技術
C部分:網路安裝
D部分:檔案共享
E部分:無線安全
第六章 因特網
A部分:因特網技術
B部分:固定因特網接入
C部分:行動式和移動因特網接入
D部分:因特網服務
E部分:因特網安全
第七章 Web和電子郵件
A部分:Web技術
B部分:搜尋引擎
C部分:電子商務
D部分:電子郵件
E部分:Web和電子郵件安全
第八章 數字媒體
A部分:數字聲音
B部分:點陣圖圖形
C部分:向量圖形和三維圖形
D部分:數字視訊
E部分:數字版權管理
第九章 計算機產業:歷史、職業和道德
A部分:計算機歷史
B部分:計算機產業和IT產業
C部分:計算機專業人員的職業
D部分:職業道德
E部分:工作區安全和人體工程學
第十章資訊系統的分析與設計
A部分:資訊系統
B部分:系統分析
C部分:系統設計
D部分:實現和可維護
E部分:企業資料安全
第十一章資料庫
A部分:檔案和資料庫概念
B部分:資料管理工具
C部分:資料庫設計
D部分:SQL
E部分:資料庫安全
第十二章計算機程式設計
A部分:程式設計基礎知識
B部分:過程化程式設計
C部分:面向物件程式設計
D部分:說明性程式設計
E部分:安全程式設計
A、B、C、D、E部分還會再細分，至少四個小節，這本書按照我的那種讀法，兩週就可以讀完，不過每天平均可能至少要保持一個小時的閱讀。
組合語言的優缺點:
優點：佔用記憶體少、執行速度快、易讀懂。
缺點：可移植性差。
3.高階語言(20世紀50年代)
高階語言，它是在低階語言的基礎上，採用接近於人類自然語言的單詞和符號來表示一組低階語言程式，使程式設計變得更加簡單，易學，且寫出的程式可讀性強。
高階語言的優缺點：
優點:
(1)高階語言接近演算法語言，易學、易掌握，一般工程技術人員只要幾周時間的培訓就可以勝任程式設計師的工作；
(2)高階語言為程式設計師提供了結構化程式設計的環境和工具，使得設計出來的程式可讀性好，可維護性強，可靠性高；
(3)高階語言遠離機器語言，與具體的計算機硬體關係不大，因而所寫出來的程式可移植性好，重用率高；
缺點:有些高階語言寫出的程式執行效率並不高。
4.第一次軟體危機與結構化程式設計(20世紀60年代~20世紀70年代)
高階語言的出現，解放了程式設計師，但好景不長，隨著軟體的規模和複雜性的增加，20世紀60年代中期開始爆發了第一次軟體危機，典型的表現:
軟體質量低下、專案無法如期完成、專案嚴重超出預計支出等。
結構化程式設計概念，參考百度百科:
其概念最早由E.W.Dijikstra在1965年提出的，是軟體發展的一個重要的里程碑。它的主要觀點是採用自頂向下、ofollow,noindex">逐步求精 及模組 化的程式設計方法；使用三種基本控制結構構造程式，任何程式都可由順序、選擇、迴圈三種基本控制結構構造。結構化程式設計主要強調的是程式的易讀性。
結構化程式設計的主要特點是拋棄goto語句，採取自頂向下、逐步細化、模組化的指導思想。結構化程式設計本質上還是一種面向過程的設計思想。
通過結構化程式設計，將軟體的複雜度控制在一定範圍內，從而從整體上降低軟體開發的複雜度。結構化程式設計是20世紀70年代的軟體開發潮流。
5.第二次軟體危機與面向物件(20世紀80年代)
結構化程式設計的流行在一定程度上緩解了軟體危機，然而隨著硬體的快速發展，業務需求越來越複雜，以及程式設計應用領域越來越廣，第二次軟體危機開始到來。
第二次軟體危機的根本原因還是在於軟體生產力遠遠跟不上硬體和業務的發展。第一次軟體危機的根源在於軟體的邏輯變的非常複雜，而第二次軟體危機主要體現在軟體的“擴充套件”變得非常複雜。結構化程式設計雖然能夠緩解軟體邏輯的複雜性，但是對於業務變化帶來的軟體擴充套件卻無能為力，軟體領域迫切希望找到新的銀彈來解決軟體危機，在這個背景下，面向物件思想開始流行起來。
對於面向物件程式設計定義，引用百度百科:
面向物件程式設計(Object Oriented Programming)作為一種新方法，其本質是以建立模型體現出來的抽象思維過程和麵向物件的方法。模型是用來反映現實世界中事物特徵的。任何一個模型都不可能反映客觀事物的一切具體特徵，只能對事物特徵和變化規律的一種抽象，且在它所涉及的範圍內更普遍、更集中、更深刻地描述客體的特徵。通過建立模型而達到的抽象是人們對客體認識的深化
面向物件程式設計思想，現在仍然也很流行，不過據說目前領域驅動設計在不少公司正在實施中，我對這個領域驅動設計不是特別明白，目前用的比較多還是面向物件程式設計，因為我使用的程式語言是Java,Java是一個面向物件的程式語言。
6.軟體架構
早在20世紀60年代，戴克斯特拉就涉及軟體架構這個概念，但是軟體架構真正的流行卻是在20世紀90年代開始的，由於在Rational和Microsoft內部的相關活動，軟體架構的概念開始越來越流行。
軟體架構的定義，引用百度百科:
軟體架構是一個系統的草圖。軟體架構描述的物件是直接構成系統的抽象元件 。各個元件之間的連線則明確和相對細緻地描述元件之間的通訊。在實現階段，這些抽象元件被細化為實際的元件，比如具體某個類或者物件。在面向物件 領域中，元件之間的連線通常用介面 來實現。
軟體體系結構 是構建計算機軟體 實踐的基礎。與建築師 設定建築專案的設計原則和目標，作為繪圖員 畫圖的基礎一樣，一個軟體架構師 或者系統架構師 陳述軟體構架 以作為滿足不同客戶需求的實際系統設計方案的基礎。
軟體架構出現有其必然性，通常都是解決某種語言或者設計思想帶來的問題，比如軟體架構所解決的問題有三個(針對大規模系統而言)
(1)系統規模大，內部耦合嚴重，開發效率低;
(2)系統耦合嚴重，牽一髮動全身，後續修改和擴充套件困難;
(3)系統邏輯複雜，容易出現問題，出現問題後很難排查和修復;
綜合上述六個方面，我們可知，從機器語言、組合語言、高階語言、面向結構程式設計、面向物件程式設計、軟體架構，可以理解為優秀的進化，也可以理解為基因突變，基因突變有好有壞，每一次基因突變取決於所處的環境，人如此，程式語言或者相關的程式設計或架構亦如此。這就是我最終的觀點和想法。
最後再針對這個問題:為什麼結構化程式設計、面向物件程式設計、軟體工程、架構設計最後沒有成為軟體領域的銀彈？
我的觀點是:所處的環境不用，適用範圍也就有了限制，一句話，物競天擇，適者生存。當然了，一句話概述還遠遠不夠。程式語言只是一個方面的體現。
同時還有軟體工程方法也同樣再變化，從最早期的瀑布模式、迭代、敏捷到現在先進的devops。從結構化程式設計、面向物件程式設計、軟體工程、架構設計最後沒有成為軟體領域的銀彈問題出發，你仔細想想，從多個方面考慮，以我個人的觀點歸納如下:
(1)程式語言的體現，化繁為簡;
(2)軟體工程的體現，從瀑布、迭代、螺旋、devops,追求的目標是快速、高效、能夠適應不斷的變化;
(3)框架的變化，框架從過去的重量級到現在的輕量級，比如以java為例，過去的EJB，現在的Spring;
(4)專案管理工具，從CVS到SVN再到Git，或者可以說在沒有CVS、SVN、Git之前手動合併程式碼;
(5)測試的變化，手動測試到自動化測試
(6)應用變化，單體應用到微服務。
諸如這樣的例子有很多，歡迎大家留言。
本文除了自己的看法之外，所參考文獻和資料如下:
《從0到架構師》之架構的歷史背景
《計算機文化》
百度百科