從0開始學架構03《感悟》

讀《架構設計的歷史背景》這一篇文章，發現架構的發展史就是在不停的解決問題，解決了當前問題，之後又會引出新的問題，好像就是不停的迭代一樣，但是任何一個解決方案出現都會經歷一段時間，時間的長短和業務發展等是密切相關的，如果業務上不去，那公司肯定不會花大力氣在這些方面做優化或者重構的。

我們先回顧一下架構出現的歷史背景：

1.機器語言

直接使用二進位碼0和1來表示機器可以識別的指令和數據。

存在的問題：太難寫、太難改、太難讀

2.彙編語言

又叫符號語言，用助記符代替機器指令的操作碼，用地址符號或標號代替指令或操作數的地址。

彙編語言解決了機器語言讀寫複雜的問題，但本質上還是面向機器的，因為彙編語言需要我們精確了解計算機底層的知識。例如：CPU指令、寄存器等。編程本身很複雜，還有另外一個複雜的地方在於：不同CPU的彙編指令和結構是不同的。因此也需要編寫多套程序。

3.高級語言

程序員不需要關機機器底層的低級結構和邏輯，而只要關注具體的問題和業務即可。

第一次軟體危機和機構化程序設計

隨著軟體規模和複雜度的大大增加，第一次軟體危機爆發，典型的表現有軟體質量下降、項目無法如期完成、項目嚴重超支等（人月神話），出現「軟體危機」一詞，提出「軟體工程」來解決危機，但是只能緩解軟體危機，不能根除。此時「結構化程序設計」被提出，採用自頂向下、逐步細化、模塊化的方法，將軟體複雜度控制在一定的範圍內，從而從整體上降低了軟體開發的複雜度。

第二次軟體危機與面向對象

軟體生產力遠遠跟不上硬體和業務的發展。主要表現軟體的擴展變得非常複雜。面向對象被提出，但是跟軟體工程一樣，面向對象也不是銀彈，而只是一種新的軟體方法而已。

隨著軟體系統規模的增加，計算相關的演算法和數據結構不在構成主要的設計問題，當系統由許多部分組成時，整個系統的組織，也就是所說的「軟體架構」，導致了一些列新的設計問題。

軟體架構出現在大公司，並且開始流行，為啥出現在大公司呢？

1.系統規模龐大，內部耦合嚴重，開發效率低；

2.系統耦合嚴重，牽一髮動全身，後續修改和擴張困難

3.系統邏輯複雜，容易出現問題，出問題後很難排查和修復；

縱觀這個發展的過程就是為了找到解決問題的銀彈，而採取了各種措施，最終經過各種演變出現了架構這個東東，這個過程中變化是唯一的不變，所以我們尋找的銀彈是不會存在的，除非沒有變化，沒有變化軟體肯定是不符合業務發展的，遲早會被淘汰，因此軟體就是變化和複雜的結合體，軟體的價值就是保證業務的響應力，提供給客戶一流的服務，我們才有年底的分紅、年終獎。其實在實踐中我們都會出現各種妥協不管是技術還是業務都會出現選擇性的放棄或者採取折中的方案來做事情，這個過程其實就是尋找一個新的平衡點，既滿足客戶需求也在有限的開發資源情況下完成任務。