架構漫談 讀後感

2022-08-23 01:27:12 字數 2328 閱讀 5362

下面對漫談架構的每一章進行乙個總結

一)第一篇:講的是到底什麼是架構,

在我看來:就是

把一整體劃分為不同角色,

各自完成自己的部分

,最後有機的融合在一起

。然後通過乙個早期的例子來籠統地概括他的出現。

在最早期,每個人都完全獨立生活,衣、食、住、行等等全部都自己搞定,整個人類都是獨立的個體,不相往來。為了解決人類的延續的問題,自然而然就有男女群居出現,這個時候就出現了分工了,男性和女性所做的事情就會有一定的分工,可是人每天生活的基本需求沒有發生變化,還是衣食住行等生活必須品。但是一旦多人分工配合作為生存的整體,力量就顯得強大多了,所以也自然的形成了族群:有些人種田厲害,有些人製作工具厲害,有些地方適合產出糧食,有些地方適合產出棉花等,就自然形成了人的分群,地域的分群。當分工發生後,實際上每個人的生產力都得到了提高,因為做的都是每個人擅長的事情

(二)第二篇:講的是認識概念。架構實際上解決的是人的問題,

舉個例子,

看到乙個東西,比方說杯子,「杯子

」就是乙個名字,指代的看到的東西就是相,就是事物的相狀。我們一聽到「杯子

」這個詞,腦海裡就會浮現出乙個杯子的形象。而「杯子

」這個詞,是用來指代的是這個相狀的,叫做名。合起來就叫做「名相

」。每個概念

都是因解決問題而產生的,最後

我們把解決問題的解決方案,

命名了乙個名字

,這個名字就是概念。

(三)第三篇:講的

是識別問題。首先通過一則笑話:女主人公:老公,把袋子裡的土豆切一半下鍋。結果老公是把袋子裡的每個土豆都削了一半,然後下鍋。每個人都做了很多任務作,每個人都認為自己做的是對的,因此沒有乙個人對結果滿意。因為真正的問題沒有被發現,自然也就沒有被解決,那麼後續還得收拾殘局,還要繼續解決問題。事實上自己的工作並沒有完成,反而更多了。把原因歸結為溝通問題也是可以的,但對於解決問題似乎並沒有太多的幫助。因為要改進溝通,這也是乙個大問題。搞明白目標問題「是誰的問題,是什麼問題

」,當然也是需要溝通的。為了幫助自己更快的搞明白,首先要做的事是問正確的問題。架構師應該問的第乙個正確的問題就是:目標問題是誰的問題。

在專案開發階段,團隊之間必備的就是溝通,如果溝通不好,專案組就會問題百出。

(四)第四篇:架構切分。我們已經知道,隨著社會的發展,分工是必然的。每個人做著不同的工作,也可以說做著自己更為擅長的工作,各盡其職。這個背後的動力就是每個人自己的利益。每個人都希望能夠把自己的利益最大化。在這個模式下,每個人必須要捨掉自己的東西,才能夠得到更多的東西。牛頓第三定律也告訴我們想走必須留下點兒東西。

(五)第五篇:講的什麼是軟體。軟體的產生就是人類在計算機上有意無意地模擬人的行為。軟體早期是由程式設計師編寫的,提高了自己的生產力,慢慢軟體就變成了乙個獨立的行業。

從最初的

乙個人完成,也逐漸變成

多人分工

完成。(六)第六篇:架構要解決什麼問題。架構實際上是在量不斷的增大,超過了單台伺服器的容量,逐漸的分拆,同時導致超過單個人員的能力,工作人員不斷的增多,工作內容不斷的分拆形成的。這本身就是架構的意義所在。不管怎麼分拆,所達到的目標沒有任何變化,就是完成業務在計算機中的虛擬化。

(七)第七篇:給架構師實權。架構師是要去平衡別人的利益,甚至會調整別人的利益的。一旦架構師是全心全意的為別人的利益服務,自然而然的架構師就擁有了強有力的影響力,肯定會是乙個leader。但是只是民意上的

leader

是沒有用的,不能完全發揮架構師的能量。架構師必須是乙個組織的領導人,有權利調動這個組織的架構,才能夠更好的發揮架構師的作用,更好的把利益的調整落到實處。

(八)第八篇:如何寫好**。

作為乙個軟體工作者

,無論幹什麼

,編碼是必不可少的。我們真正想快速的完成**工作,就要克服自己對時間的恐懼,真正的去研究業務的問題。結合每個部署單元所承擔的責任,可以明確的拆分為兩個不同的責任:表達業務邏輯的**,對使用者提供訪問並儲存業務邏輯執行結果的**。

(九)第九篇:理清技術、業務和架構的關係:

技術是為了解決業務的問題而產生的,沒有了業務,技術就沒有了存在的前提。

有了更好的技術,效率更差的技術,就會慢慢的被淘汰,消失,一切都遵從人類的利益訴求 -- 也就是業務。有人會問,不用鑽木取火了,但是弓弦加速轉動木棍還可以用啊? 沒錯,因為弓弦轉動木棍這個技術,不是來生火的,是用來加速木棍轉動的,所解決的問題不一樣。但是兩種不同的技術,合理結合起來,會更好更有效率的解決業務問題

,在解決同乙個業務問題的前提下,更高效,更低成本的技術,會淘汰低效,高成本的技術。這是人類利益訴求所決定的。一般剛開始解決根本問題的技術(鑽木取火)的效率是比較低的,只是把不可能變成了可能

。然後就會有提高效率的需求出現,要求改進這個技術。這個技術的低效率部分就會被其他人(或者技術發明人自己)加以改進,這部分就會形成新的技術。

架構漫談讀後感

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

架構漫談讀後感

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

架構漫談讀後感

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