悠然亂彈 我的架構觀

2021-09-23 20:56:13 字數 2487 閱讀 7822

既然是亂彈,當然就不能全用正理推斷,因此文中有文不對題的,思維混亂的都屬正常範疇,大家諒解則個。 

架構,是乙個神秘也是乙個普通的詞彙。 

曾幾何時,君不見現在架構師就像雨後春筍似的,忽如一夜春風來,千樹萬樹上面結的都是架構師,不管是招聘的,不管是應聘的,動輒就是資深架構師,高階架構師云云。

有的人說,架構是搞一堆時髦的大家不理解詞彙,最好是一堆一堆的英文縮寫,網上有的,網上沒的,就象華為似的,任你是國內的國外的,沒有縮寫詞詞典管叫你寸步難行,然後再弄一大堆理論出來,然後架構就有了。 

有的人說,架構是設計出來的,最好是把soa,esb,jca,設計模式,架構模式, 執行模式,分層模式,多n個layer,弄m個tier,讓本來清楚點的不清楚,讓不清楚的更不清楚,然後畫一系列的圖,從大到小逐層細化,看懂大的再看中的,看懂中的再看小的,看懂小的,大的已經忘記了。 

有的人說,架構是闖出來的,啥子思想,啥子體系,算個屁,偶就厲害,一陣亂拳開啟去,架構自然就出現了。 

有的人說,架構是重構出來的,再好的設計,到後面也會變形,如果沒有及時的重構,就會走樣,從正方形,變成長方形,從長方形變成平行四邊形,最後不行了,再重新來過,搞乙個新的輪迴。 

還有許多許多的牛人,說了n多nb的理論,都有各自己的理解,看看都是正確的,就是學不會,弄不懂,抓不實。 

總而言之,言而總之,看了許多,學了許多,還是弄不靈清。今天自不量力來亂彈一下我在做tiny過程的中架構觀,供大家無事之時揮揮板磚鍛鍊一下身體,疏通一下筋骨。

1. 方** 

方**這個東東,看了的人都覺得比較虛,其實我也一直覺得比較虛,但是在許多次的實踐之後,才慢慢對這一點有了比較深刻的理解。沒有方**指導下的架構,實際上就像是沒有長眼睛的蒼蠅一樣,撞到**到**,最後一般來說,做的東西都是缺少體系性的。有的地方可能很強,有的地方可能又比較弱。有的地方有不足,需要進行補充的時候會發現對現有的有嚴重的衝突。甚至在後面,連自己的方向也沒有了,感覺這樣也行,那樣也行,實際上卻是這樣也有問題,那樣也有問題。總而言之方**對於體系性思維及整體性思考是非常重要的。 

2.設計原則 

設計原則在於你的框架中最優先考慮的原則有哪些,它有可能是具體的功能需求(一定是重要的全域性影響性的需求,比如:配置需要統一配置,並且要有配置訂閱與發布機制),也可能是非功能需求,但是對於整個框架都有約束及限制作用(比如:減法原則,讓程式設計師會最少的知識,就可以開展工作;比較dyr原則,永遠不要做重複的事情),同時保證你的路線是在朝既定的路線圖前進。缺少設計原則的架構,在最後,就會表現為特點不清晰,內部矛盾比較嚴重。 

3.範圍的確定 

作為乙個架構或框架來說,包含的內容可大可小,東西可多可少,深度可深可淺,如果沒有範圍的確定,可能在乙個問題上就會變成乙個深不見底的坑,再也跑不上來。 

4.框架的分解 

啥東西只要一上公升到框架的級別,一般來說就會複雜許多。框架的構建是乙個系統工程,一般來說它不是乙個人或幾個人可以完全搞得定的。參與的人也各有各的優勢與缺點,因此讓合適的人做合適的事情就是最好的選擇了。因此,要把整個大的系統及框架,分解成小的問題領域,在小的問題領域中,只考慮自己這部分的問題並給出最佳方案。各個小的領域與模組都有好的解決方案並有乙個相當不錯的實現方案的話,就為後續的框架奠定了深厚的基礎。當然,每個小的問題領域都要在介面及擴充套件性方面有深入分析、論證,在區域性要力求最優解,當然,一定要遵守前面說的設計元則。 

5.框架的整合 

框架的整合方面最後採用整合層最薄的原則進行,也就是說,整合成只管進行不同模組之間的黏合,本身不做具體的業務處理。比如:你提供了乙個外掛程式框架,最好外掛程式框架中只做把普通模組**包裝成外掛程式的**,但是不要參與業務邏輯的處理。這樣就即保證高內聚與低耦合,又可以進行多模組協作。 

那可能有的朋友就要問了,你亂彈了這麼多,你在tiny框架中是怎麼做的呢?tiny框架在構建之初就構想了下面的路線圖與設計原則和理念,並在下在趄這個方向前進。

tiny的路線圖 

tiny的設計原則

•約定優於配置

–通過約定減少**及配置量

•減法原則

–從技術經理、技術骨幹到開發人員,工作量範圍與內容越來越少

•下級服從上級原則

–開發人員無條件服從技術骨幹,技術骨幹無條件服從技術經理

•自動組裝原則

–復用資產,由框架進行自動組裝,避免大量的系統配置

•dry原則

–讓各個軟體相關參與者不要做重複的事情

•配置集中原則

•模組化原則

•抽象與實現分離原則 –

與各種開源與商業平台有良好的整合能力

tiny的設計理念

•使用靈活,可以整個使用它,也可以只用它的乙個或幾個部分

•學習成本低,上手容易

•核心的穩定性,核心部分使用盡量少的第三方框架及包

•方便的外延性,不影響對第三方框架的使用

•現有資產的可延續性,不管以前有什麼軟體資產,只要願意,都可以方便的整合、復用

•易於知識積累,真正做到越用越強

•易於集群與水平擴充套件,能做到不間斷提供服務

我的架構觀 架構未來的發展

最近看了一些架構方面的帖子,包括京東的 支付寶的,加上之前各種微服務,大平台,彈性化等各種架構詞彙,在大腦裡相互衝撞,一時間感覺不知所云,思維被各種概念牽引著,有點慌亂。當然這不是我想要的狀態,於是運用曾文正公的處世之道 立足當下,化繁為簡 回到架構的三個哲學問題 1.何為架構?2.它從 來?3.它...

我的組長觀(領導觀)

大家如何看待你的直接領導,包括你的team leader?你對你的領導是如何期望的?6月底我換了一下工作地,工作崗位也隨之變化,從北方有回到了南方,從自己熟悉的開發領域進入了完全陌生的測試領域。其實測試也沒有什麼,測試也是開發。所謂的完全陌生是指這種完全沒有章法的測試而已 1 工作安排不會事先溝通,...

我的朋友觀

其實,我這個人看待朋友的觀點很簡單。就是他夠不夠哥麼!究竟如何才能判斷乙個人夠不夠你哥麼呢?這也很好判斷,我的理論就是,如果你哥麼身上有100塊錢,而你向他借錢的時候,他能借給你50元,就可以說明他夠你哥麼了。如果他能借你60,70,甚至是全部借給你,那就說明他把你看的比他的生命還重要。而這樣的人,...