基礎架構 架構發展史簡析

1、定義

1）最早的軟體開發使用的是「機器語言」，直接使用二進位製碼 0 和 1 來表示機器可以識別的指令和資料

1）機器語言的主要問題是三難：太難寫、太難讀、太難改

1）組合語言又叫「符號語言」，用助記符代替機器指令的操作碼，用位址符號（symbol）或標號（label）代替指令或運算元的位址

1）為了解決機器語言編寫、閱讀、修改複雜的問題，相比機器語言來說，組合語言簡單明瞭

1）組合語言雖然解決了機器語言讀寫複雜的問題，但本質上還是面向機器的，因為寫組合語言需要我們精確了解計算機底層的知識

2）除了編寫本身複雜，還有另外乙個複雜的地方在於：不同 cpu 的彙編指令和結構是不同的。

1）可以簡單理解為用人們更易理解的方式編寫程式。

1）可以概括為解決組合語言所面臨的問題

2）與組合語言相比，讓程式設計師不需要關注機器底層的低階結構和邏輯，而只要關注具體的問題和業務即可

3）通過編譯程式的處理，高階語言可以被編譯為適合不同 cpu 指令的機器語言

1）隨著軟體的規模和複雜度的大大增加，出現了諸如軟體質量低下、專案無法如期完成、專案嚴重超支等問題。

1）結構化程式設計本質上還是一種面向過程的設計思想，採用「自頂向下、逐步細化、模組化」的方法

2）結構化程式設計的主要特點是拋棄 goto 語句，採取「自頂向下、逐步細化、模組化」的指導思想

1）第一次軟體危機的根源在於軟體的「邏輯」變得非常複雜

2）結構化程式設計將軟體的複雜度控制在一定範圍內，從而從整體上降低了軟體開發的複雜度，從一定程度上緩解了軟體危機

1）軟體工程不是銀彈，無法**軟體危機，只能在一定程度上緩解軟體危機

1）物件導向是相對於面向過程來講的，物件導向方法，把相關的資料和方法組織為乙個整體來看待，從更高的層次來進行系統建模，更貼近事物的自然執行模式

1）第二次軟體危機主要體現在軟體的「擴充套件」變得非常複雜

2）結構化程式設計雖然能夠緩解軟體邏輯的複雜性，但是對於業務變化帶來的軟體擴充套件卻無能為力，在此背景下物件導向思想開始流行

1）物件導向和軟體工程一樣，物件導向也不是銀彈，而只是一種新的軟體方法而已。

1）第一次軟體危機引出了「結構化程式設計」，創造了「模組」概念

2）第二次軟體危機引出了「物件導向程式設計」，創造了「物件」概念

3）之後「軟體架構」開始流行，創造了「元件」概念

1）「模組」「物件」「元件」本質上都是對達到一定規模的軟體進行拆分，差別只是在於隨著軟體的複雜度不斷增加，拆分的粒度越來越粗，拆分的層次越來越高

1、想要深入理解乙個事物的本質，最好的方式就是去追尋這個事物出現的歷史背景和推動因素。

2、 回顧軟體開發進化的歷史，以及軟體架構出現的歷史背景，從歷史發展的角度，深入了解架構設計的本質

3、 推薦《人月神話》

[1] 李運華. 從0開始學架構[m]. 極客時間, 2018.

前端架構發展史

最初，前端是沒有架構的，因為功能簡單的 毫無架構可言。通過乙個簡單的jquery庫操作dom就能完成的工作，無需複雜的設計模式和 管理機制，也就不需要架構來支援起應用。前端開發的發展歷史分為以下幾個階段 一旦前端應用需要從後端獲取資料，就意味著前端應用在執行時是動態地渲染內容的，這便是model 模...

Android架構簡析

mvp架構及開發模式 mvc or mvp pattern whats the difference?android中的mvp 譯 android開發中的mvp架構 首先，讓我們思考下為什麼在android開發中如此迫切地需要乙個清晰的架構。該段摘自 大全第二版 避免建立神類。避免建立無所不知，無所...

讀出歷史的架構 架構師讀史

最近一直在進行架構師培訓，不是培訓別人，而是公司組織的，接受外面講師的培訓。在學習的過程中，不斷思考，一直覺得架構思維，作為一種思維方式。注意 架構是一種思維方式，是分析解構，尋找這個世界的變與不變的科學方法。總想著架構思維，即然可以用來分析事物的架構，那麼歷史呢，每乙個歷史事件，難道不可以利用架構...