架構漫談讀後感

這九篇文章的題目分別是這樣的：「什麼是架構」、「認識概念是理解架構的基礎」、「如何做好架構之識別問題」、「如何做好架構之架構拆分」、「什麼是軟體」、「軟體架構到底解決什麼問題」、「不要空設架構師這個職位，給他實權」、「從架構的角度看如何寫好**」、「理清技術、業務和架構之間的關係」；

「什麼是架構」這篇文章在第篇就解答了我作為一名懵懂學生的疑惑：我們跟者老師學習架構，到底架構是個什麼東西呢，它能給整個專案帶來什麼好處或者起著什麼作用呢？王概凱先生在他的第一篇文章中（按照個人的理解）是這樣說的：在了解什麼是架構之前我們先要了解為什麼會產生架構；那就是當一群人或者乙個專案組同時工作的時候，由於每個人的能力是有限的，而且每個人的專長是有所不同的，所以為了達到資源利用最大化，我們需要對現有的資源進行重新的分配，然後獲得任務的個體與其他的個體進行有效的溝通，共同完成乙個目標。王概凱先生這樣總結架構產生的原因

「為什麼？

」真正明白

「為什麼

」的工程師，才可能成長為乙個合格的架構師。幾乎所有與軟體有關的職業和著作都要求對乙個問題的解決，那就是「問題

」，這不是文字遊戲，而是實實在在的關鍵所在。但是怎麼弄明白「問題

」呢？首先就要找到問題的主體，因為架構是和人分不開的，雖有問題的主體往往就是問題的物件

——人。乙個問題，物件不同，即主體不同，主體不同所帶來的解決方式也很可能不同，不同的解決方法，其中的絕大部分往往就不是最讓人滿意的解決方法了，因為我們沒有搞清楚這到底是誰的問題。　

找出了問題，我們就可以去解決問題了，怎麼去解決？不同的個體構成乙個整體，那這個作為整體的問題也需要分成不同的個體到每乙個個人身上。在分解的過程就產生了怎麼去分解的問題。切分的調整即是對個人利益的調整，說到切分和利益，就想到乙個老師講過的故事：一群人分粥，怎麼分才最公平。當然有很多選項，也可聽者自行發揮，這裡就直接說老師的答案了——讓乙個人來為大家分粥，分粥的人最後取粥，這或許不是最好的答案，卻已經是很好的結果。分粥的人想要得到的更多，但是如果給別人分的少的話，別人就會抱怨他，給別人分的多了，自己就又少了，於是就產生了大家都認可的公平。切分的過程有捨才有得

讀到第四篇文章「如何做好架構之架構切分」的時候感覺這個題目有些怪異--架構不就是乙個整體的東西嗎，這還能切分？然後我看到了作者這樣的回答：雖然在識別出問題的根本所在之後會解決很多的問題，但是總是有問你還是解決不了得，那就需要做調整，那麼就必須要有所動作，做相應的調整。這個調整就是架構的切分。原來是這樣，那架構切分既然是為了解決問題，南無架構切分到底是為了解決什麼問題還有架構應該怎樣切分才算是合理呢？作者又有了這樣的回答：切分是為了達到調整利益的目的，調整整個專案的運作之中產生的時間和空間上利益衝突的問題以此達到利益的最大化。作者在本章的組後部分作出了總結：

架構的切分的導火索是人的負載太重。架構的切分實際就是對 stakeholder 的利益進行切分或合併，使得每個stakeholder 的權責是對等的，每個 stakeholder 可以為自己的利益負責。架構切分的最終結果都會體現在組織架構上，只有這樣才能夠讓架構落地並推進。架構切分的結果一定是乙個樹狀，這也是為什麼會產生分層。層數越多溝通越多，效率越低，分層要越少越好。盡可能變成一顆平衡樹，才能讓整個系統的效率最大化。這樣看來矛盾基本上是可以通過架構切分來解決的啦。

架構師應該承擔起解決業務問題的這個角色來，專注於business domain和軟體本身的架構，讓技術人員致力於為業務在計算機中跑起來而努力。只有把這兩者很好的結合起來，才能更好地完成業務的目標，才會讓軟體更好地服務於大家。最終一定會得到乙個很好的軟體架構，令軟體開發團隊和業務部門都能夠很好地開展工作並降低成本。

架構漫談讀後感

架構漫談讀後感

架構漫談讀後感

架構漫談讀後感

相關推薦