date
comments
categories
br#title
2020/3/14
true
軟體架構
架構
原則
5.7
軟體架構的三原則
前面說過成為架構師是每個程式設計師的夢想，但並不意味著把程式設計做好，就能夠自然而然的成為乙個架構師，優秀程式設計師和架構師之間還有乙個明顯的鴻溝需要跨越，這個鴻溝就是不確定性，對於程式設計來說本質上是不存在不確定的，對於同樣一段**不管誰寫的，不管什麼時候執行，執行的結果都應該是確定的，但是設計架構則不一樣，同樣乙個方案，a設計師認為應該這樣，b設計師認為應該那樣，看起來好像都是有道理的，即相比於程式設計來說，架構設計並沒有像程式語言那樣的語法來進行約束，更多的時候是面對各種可能性進行的權衡抉擇。
而一旦涉及到選擇，就很容易讓架構師陷入兩難的境地， 比如是要選擇業界最先進的技術，還是選擇團隊目前最熟悉的技術，如果選擇了最先進的技術後出了問題怎麼辦？如果選擇了目前最熟悉的技術，後續技術引進怎麼辦？ 是選擇google的angular的方案來做，還是選擇facebook的react來做安格拉，看起來很強大，但是react看起來更加靈活。
是選擇使用my sql資料庫還是mongodb資料庫？團隊熟悉my circle，但是曼谷地壁更加適合業務場景。 **的電商**架構很完善，我們要做乙個電商**，是否簡單的照搬**就可以了。 總之呢，這種類似的問題困惑非常非常的多，業務千變萬化，技術層出不窮，涉及理念也百花齊放，看起來很難有一套通用的規範，適用所有的架構場景。但是在研究了架構設計的發展歷史，多個公司的架構發展過程，例如qq，**facebook等眾多的網際網路公司架構設計後，還是能夠找到幾個共性的原則的。這幾個原則就是合適原則，簡單原則和演化原則。
合適原則的主旨就一句話，適合優於業界領先。
優秀的技術人員往往都有很強技術情結，他們往往希望能夠在自己的專案中展示自己的技術水平，秀技術——我也做乙個億級使用者的平台，在很多技術人員的心裡是根深蒂固的。
但是現實中大部分這樣想這樣做的，假如最後都可能以失敗告終。原因有如下幾個方面。
所以真正優秀的架構都是在企業當前人力條件業務等各種約束下設計出來了，能夠合理的將資源整合在一起，並發揮出最大功效，亦能快速落地。
主旨就是說簡單優於複雜。
在現實生活中很多東西都是越複雜，越精細會顯得技術越好，但在軟體架構這方面卻不是這樣的。在軟體領域結構複雜的系統，往往組成元件數量非常之多，同時這些元件之間的關係也非常的複雜。組建越多，關聯越多，那麼這些元件其中某個或者多個出現故障的可能性就大大提高，而且有時候修改乙個元件會導致關聯的所有的元件受影響。
另外在複雜系統中定位問題比簡單系統要困難的多，每個元件都有嫌疑，因此要逐一排查，其次組建間的關係複雜，有可能表現故障的元件並不是真正問題的根源。
複雜系統的內部邏輯往往也非常的複雜，邏輯複雜，幾乎會導致軟體工程每個的環節都有問題，比如說假如說**的將很多功能在乙個元件當中實現，那麼假如說某乙個程式設計師不小心改了一行**，就會導致整個**崩潰，這時候再想上去維護，然後找出問題恐怕是非常難的。 總之軟體結構和邏輯越簡單越好。
意思就是說一步步演化，遠遠強於一步考慮完所有的情況。 軟體架構和我們平常在日常生活中見到的架構是不一樣的，比如說我們平常見到的，建築物架構，古埃及的大金字塔，2023年前完成的，到現在也不會再改了，中國的長城幾百年前造完的，到現在還是當年的結構，美國的白宮也是原來的骨架，頂多外面刷一層漆。
但是軟體架構就不一樣了，比如說windows系統的發展歷史，從最開始的msdos到現如今的windows 10。你會發現，哪怕對比的是windows，一和windows8架構他們也是兩個完全不同的東西了。與此相同的是安卓的發展歷史也是這樣子，安卓6.0和安卓1.6的差異非常的大。
對比現實中的建築物架構，永恆是主題，而對於軟體來說變化才是主題。軟體架構需要根據業務的發展不斷變化。設計windows和安卓的人都是頂尖的天才，即便如此他們也不可能在2023年設計出windows8，不可能在2023年設計出安卓6.0。
所以在做軟體架構的時候，不要妄圖一步到位設，考慮到所有的方方面面，永遠都不用改，永遠都穩如磐石。
軟體架構設計其實更加類似於大自然設計，乙個生物通過氧化讓生物適應，環境逐步變得更加強大。
軟體架構同樣應該是類似的過程。
演化是在進行架構設計時，需要牢記這個原則，時刻提醒自己不要貪大求全或者盲目照搬大公司的做法，應該認真分析當前業務的特點，明確業務面臨的主要問題，設計合理的架構，快速的落地滿足業務需求，然後在執行過程中不斷完善架構，不斷隨著業務進行演化。
架構設計三原則
架構設計三原則 合適原則 合適原則宣言 合適優於業界領先 失敗原因 沒那麼多積累，卻想一步登天，是失敗的第二個主要原因 沒那麼卓越的業務場景，卻幻想靈光一閃成為天才，是失敗的第三個主要原因 沒那麼多人，卻想幹那麼多活，是失敗的第乙個原因 簡單原則 簡單原則宣言 簡單優於複雜 軟體領域的複雜性 結構的...
架構設計三原則
成為架構師，可以說是絕大多數開發者的夢想。但是這個過程並不是一件簡單的事情，如果簡單的話，意味著供過於求，就代表著不值錢了。在目前國內，架構師也算是乙個比較吃香的職業。對於年齡較大的小夥伴們，他們的選擇通常有這麼幾個?第一 繼續開發者之路，畢竟現在30多歲的資深工程師也不少 通常這些人，對於公司來說...
架構設計三原則
架構即決策。架構需要面向業務需求，並在各種資源 人 財 物 時 事 約束條件下去做權衡 取捨。而決策就會存在不確定性。採用一些高屋建瓴的設計原則有助於去消除不確定，去逼近解決問題的最優解。1 合適原則 架構無優劣，但存合適性。汝之蜜糖，吾之砒霜 架構一定要匹配企業所在的業務階段 不要面向簡歷去設計架...