架構漫談讀後感

2022-08-01 05:39:13 字數 3263 閱讀 8151

今天按照老師的要求,以下是我得點點讀後感:

1.為了解決人類的延續的問題,自然而然就有男女群居出現,這個時候就出現了分工了,男性和女性所做的事情就會有一定的分工,有了分工之後,人們的效率得到了巨大的提高,所以這就產生了架構,也對這種現象總結了一些規律。

必須由人執行的工作(不需要人介入,就意味著不需要改造,也就不需要架構了)

每個人的能力有限(每個人都有自己的強項,個人的產出受限於最短板,並且由於人的結構限制,同時只能專注於做好一件事情,比如雖然有兩隻眼睛,但是只能同時專注於一件事物,有兩隻手,無法同時做不同的事情。ps. 雖然有少部分人可以左手畫圓右手畫框,但是不是普遍現象)

每個人的時間有限(為了減少時間的投入,必然會導致把工作分解出去,給擅長於這些工作的角色來完成,見2,從而縮短時間)

人對目標系統有更高的要求(如果滿足於現狀,也就不需要進行架構了)

目標系統的複雜性使得單個人完成這個系統,滿足條件2,3(如果個人就可以完成系統的提高,也不需要別的人參與,也就不需要架構的涉及,只是工匠,並且一般這個工作對時間的要求也不迫切。當足夠熟練之後,也會有一定的架構思考,但考慮更多的是如何提高質量,提高個人的時間效率)。

2.人們在處理問題的時候,都容易犯乙個很大的問題,那就是在描寫概念的時候缺乏主語。而我們大家都忽略這個主語,溝通的時候也都以為大家都懂得對方說的主語是誰,結果大家都一起犯錯誤。識別問題的乙個最大的前提就是要搞清楚:是誰的問題。這個搞清楚了,問題的邊界也就跟著確定了,再去討論問題才有意義。

所以為了更好的解決問題,我們要更好的理解概念的問題·,架構的問題,不然在一段時間忙完了發現自己做的是無用功,所以我們要明白什麼是主體。

3.我們要非常的清楚,所有的切分調整,都是對相關人的利益的調整。因為維護自己的利益,是每個人的本性,是在骨子裡面的,我們不能逃避這一點。在現在社會,每個人都希望能夠把自己的利益最大化,所以人們為了工作更加的具有效率,自然需要捨掉一些自己不擅長的東西,用自己擅長的東西去換取別人擅長的東西。因此當人們認識到要主動的去切分乙個系統的時候,毫無疑問,我們不能忘掉利益這個原動力。所有的切分決策都不能夠違背這一點,這是大方向。結合前一篇「識別問題」,一旦確定了問題的主體,那麼系統的利益相關人(用現代管理學語言叫:stakeholder)就確定了下來。所發現的問題,會有幾種情況:

某個或者某些利益相關人負載太重。

時間上的負載太重。

空間上的負載太重,本質上還是時間上的負載太重。

為了在切分系統的時候,更加的平衡我們需要要有著幾個原則:

必須在連續時間內發生的乙個活動,不能切分。比如孕婦懷孕,必須要10月懷胎,不能夠切成10個人乙個月完成。

切分出來的部分的負責人,對這個部分的權利和義務必須是對等的。比方說媽媽10月懷胎,媽媽有權利處置小孩的出生和撫養,同樣也對小孩的出生和撫養負責。為什麼必須是這樣呢? 因為如果權利和義務是不對等的話,會傷害每個個體的利益,分出來執行的效率會比沒有分出來還要低,實際上也損害了整體的利益,這違背了提公升整體利益的初衷。

切分出來的部分,不應該超出乙個自然人的負載。當然對於每個人的能力不同,負載能力也不一樣,需要不斷的根據實際情況調整,這實際上就是運營。

切分是內部活動,內部無任怎麼切,對整個系統的外部應該是透明的。如果因為切分導致整個系統解決的問題發生了變化,那麼這個變化不屬於架構的活動。當然很多時候當我們把問題分析的比較清楚的時候,整個系統的邊界會進一步的完善,這就會形成螺旋式的進化。但這不屬於架構所應該解決的問題。進化的發生,也會導致新的架構的切分。

在切分時候,這其實也就是乙個建模的過程,為了把大問題分解成小問題,減少人們的負擔量,使人們都更有效率的完成自己的工作。

4.  在初期,軟體使用二進位制編寫的,從硬體到軟體,成本都非常的高。隨著半導體技術的進步,硬體的成本越來越低,效能越來越高,甚至出現了摩爾定律:當**不變時,積體電路上可容納的元器件數目,約每隔18-24個月增加一倍,效能提公升一倍。軟體方面,為了簡化難度,開始採用彙編,進一步出現了類似於人類的語言的高階語言,這使得人類可以用類似於人的語言來和計算機溝通。軟體工程師慢慢越來越多,開發軟體的成本也越來越低。計算機就好像是乙個只需要電,不需要休息的人,可以無休無止的工作。人們越來越願意把原來只有人才能做的事情,交給計算機來做。結果就導致軟體越來越豐富,能夠做的事情也越來越多,成本也越來越低。隨著軟體的規模的變大,做好乙個軟體也變得越來越難了。早期的程式設計師寫程式,主要是為了幫助自己研究課題。這些程式設計師熟練了之後,提高了自己的生產力,並發現還可以幫助別人寫程式,慢慢軟體就變成了乙個獨立的行業。

所以軟體工程師就是實現這個模擬過程的關鍵人物,他必須先理解人是怎麼在日常生活中完成工作的,才能夠很好的把這些工作在計算機中模擬出來,軟體工程師本身的培養就比較難,同時行業知識也要靠時間的積累,這樣就遠遠超出了軟體工程師的能力了。所以軟體開發就開始有分工了。

軟體實際上就是把現實生活模擬到計算機中,並且軟體是需要在計算機的硬體中執行起來的。要做到這一點需要解決兩個問題:

1.業務問題

2.計算機問題

這就是軟體比較複雜的地方,涉及到軟體本身的業務體系,和所虛擬的業務體系。根據以上的分析,所生成的架構,究竟那些算是軟體架構呢?

軟體因為流量增大而分拆成不同的執行單元,在不同的機器上部署所形成的架構,屬於軟體架構。

每個執行單元為了讓不同角色的人,比如前端,業務,資料儲存等能夠並行工作,所分成的**架構,也屬於軟體架構。

所以當我們說軟體架構的時候,我們一定要講清楚,究竟說的是部署的架構,還是**的架構。軟體架構的落地,需要軟體的組織架構和流程來保障,離開了這個,軟體架構是一句空話。

當我們真正專注於別人的問題的時候,我們自己的理想,抱負,對技術的追求都不算什麼了。這個時候就會真正的開始思考,別人究竟有什麼問題。架構師是要去平衡別人的利益,甚至會調整別人的利益的。一旦架構師是全心全意的為別人的利益服務,自然而然的架構師就擁有了強有力的影響力,肯定會是乙個leader。但是只是民意上的leader是沒有用的,不能完全發揮架構師的能量。所以架構師必須是乙個組織的領導人,有權利調動這個組織的架構,才能夠更好的發揮架構師的作用,更好的把利益的調整落到實處。所以很多公司設了很多架構師的職位,但是並不具備調動組織架構的權利,那麼這個架構師的職位一定是形同虛設。架構師只能夠通過建立某些流程來行使架構師的權利,比如強制架構review,反而會造成很多內部不必要的衝突,最終都會導致這些流程流於形式,得不償失。反過來,具備架構師能力的組織領導人,一定是乙個很好的領導,這個組織一定是很健康向上的,因為每個人的權利和義務就是比較均等的。並且這類領導對於組織成員權利和義務的對等狀況會非常的敏感,會及時的調整組織架構,在問題發生之前就解決了。這樣這個組織就會具備更好的抗壓能力,能夠更好的為這個組織的客戶服務,這個組織的成員內心一定都是比較平衡的,每個人的能力都能夠得到比較好的發展。當然讀者可能又會說,這不是管理學的東西嗎? 是的,但也是架構的問題。所有架構的核心就是組織架構。或者也可以這樣說,乙個合格的組織領導人,一定必須是乙個合格的架構師。

架構漫談讀後感

應老師的推薦閱讀了由資深架構師王概凱 kevin 執筆的系列專欄 架構漫談 9篇文章遞進地講述了 討論什麼是架構 怎樣做好架構 軟體架構如何落地 如何寫好程式等問題,文章生動形象多次舉通俗的例子讓本來生澀的知識變得更加容易理解,感觸頗多。對這系列文章印象的較深的一點是 一直在挖掘一些本質的東西,對一...

架構漫談讀後感

花了一周的時間利用課餘的閒散時間,總算看完了王概凱的架構漫談,這九篇部落格從相對全面的角度對架構進行了概述。自己也對架構有了更深一層的認識。感覺作者在部落格裡提到的對架構的理解對我們初學者來講幫助其實很大。架構其實就是根據要解決的問題,對目標系統的邊界進行界定,然後對目標系統按某個原則進行切分,接著...

架構漫談讀後感

這學期新開設了軟體體系架構這門課,學這門課之前架構漫談的九篇部落格進行了閱讀,對這門課以及架構設計進行了初步的認識與了解。通過對這幾篇部落格的閱讀,首先需要明白什麼是架構,在最早期,每個人有自己的生活方式,人與人之間相互獨立,不相往來,隨著慢慢的發展,男女共同生活,也就出現了各自的分工,有的人做這個...