架構漫談讀後感

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

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

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

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

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

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

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

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

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

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

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

時間上的負載太重。

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

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

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

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

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

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

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

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

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

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

1.業務問題

2.計算機問題

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

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

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

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

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

架構漫談讀後感

架構漫談讀後感

架構漫談讀後感

架構漫談讀後感

相關推薦