寫在前面
2019悄悄溜走一半，不管是離別的憂愁，仍是成長路途的艱辛，都在心中滾燙。php
距離上一篇文章已經好久了... 懶惰的博主不能將這一切歸結於個人時間、個人規劃、個人工做，只能怪本身懶......正所謂學如逆水行舟，不進則退，不進到最後就只能退了。前端
今天突發一些關於架構的感悟，執筆記錄下來。java
軟件架構的出發點
軟件架構是一個軟件系統開發生命週期中最前端的部分，也是最關鍵、最核心的部分。它決定了後續代碼的走向；可以決定項目的走向；有時候甚至可以決定一家公司的生死。軟件架構的成功要素，有不少點，這些點的一兩個或更多個，組成了不一樣級別的業務系統或用戶系統：python
*1 可靠性c++
*2 安全性安全
*3 可伸縮性架構
*4 可定製化app
*5 可擴展性框架
*6 可維護性工具
*7 用戶體驗
*8 可快速迭代性
面向用戶的系統，用戶體驗 、快速迭代、安全、可靠 ，這四點必不可少，這些點圍繞着的基礎的技術選型、管理模式、規則、流程，也就跟着對應的權重的不一樣去分配了。
假如公司A須要作一個工具app，xx計算器、或xx記事本。 想要得到市場承認，它的架構就須要大約 ： 30% 用戶體驗 、20%快速迭代、 10%可靠。按照這個權重的分配去管理架構的技術選型、管理模式等等。一個工具app的安全性作的無懈可擊，是不會獲得市場承認的；一個電商網站的安全性可靠性不能保證，會被市場所拋棄。
又假如公司B有一個對內的管理系統，想要正確的結果，首先就得保證 可快速迭代性 ，業務天天都在變化，相反的用戶體驗、伸縮、安全、可靠，均可以相對不那麼迫切。
經過可快速迭代性迅速迭代可定製化需求和可擴展性需求提高了用戶體驗，用戶體驗的提高帶動用戶量的增加，則對可靠性、可維護、安全性、可伸縮性提出了更高的要求。
上面是我想要表達的，軟件架構的出發點，是項目所處的市場的需求決定的。需求是什麼，決定了架構是什麼。
架構是難以更改的。是的，架構是很是難以更改的，若是你的項目已經推出市場了，除非重頭來過，承受完全重構帶來的陣痛。這裏每每要面臨更嚴峻的考驗，例如人事處理：有不少c++開發，想要轉java，或有不少php開發，想要轉python；再例如架構的改弦更張勢必要有加班的，埋頭苦幹一個月，再走一遍來時的路~
舉個栗子：TDD ，TDD本質過程就是要貫穿從需求分析、設計、編碼、測試、整個研發過程。它實際上是需求驅動，逐個知足每一個的需求。 TDD的核心就在於把需求分析,設計,質量控制量化的過程，在編寫測試用例時就能夠規避、重構、設計需求的架構。TDD其實就是一個以需求驅動的架構模式、開發模式。
或許你已經在作相關的架構處理了，或許你已經吃到了一些苦頭，這個理論或許能夠幫助你認識到，要根據市場需求來制定合適的架構，推導合適的架構細節。要慎重。既不能夠過分設計，也不能夠設計不足，這把量尺是：市場需求。
架構以人爲本
架構設計必需要考慮人在其中的重要因素，合適的人作合適的事情。一個好的架構，首要的就是要考慮所在團隊的人的狀況，咱們每每傾向於抓技術層架構，忽略了怎麼將合適的人放到合適的位置，已有的團隊人員能不能合理的在架構中發揮應該有的做用。
抽象的處理、框架的引進很重要的一點是，如何解決人員素質、想法、環境的不一致。框架經過封裝複雜的東西，簡化業務的複雜程度，讓對應的人可以專一對應的事情。抽象經過能夠被共同理解的概念，簡化複雜的內部處理邏輯，將人的目標聚攏在一塊兒。
軟件架構應該以人爲本，將最高效的人放在最高效的地方可以取得最大化的成果，架構設計也就必須考慮人的因素。
例如咱們有一個5人團隊作一個項目，團隊成員比例大約是： 1個leader ， 2 個核心， 2個實習，在設計這個項目的架構的時候，你必需要考慮的是，如何設計能把2個核心成員的力量放在合適的地方，如何設計能讓2個實習成員可以完成既定的任務。 假如將2個核心與2個實習放在一塊兒看待，過不了多久會出現一個狀況，核心成員感受作的東西技術含量過低，實習成員可能感受東西難、累、趕，久而久之，項目會頻繁面臨人員變動。
咱們傾向於集中精力作技術層架構，而不是人員層架構方面工做的主要緣由，不是由於技術更重要，而是由於技術更容易作。人際交往是很複雜的，而且就效果而言歷來都不會是很明晰和清楚的，可是它們比工做的任何其餘方面都更重要。寫代碼並不是只是寫代碼而已，而是與人有關——須要理解的東西包括那些人是誰，他們能做出什麼貢獻和須要什麼東西，以及是多數派仍是少數派等，諸如此類。「若是你把架構重點放一部分在人員安排的身上，那麼就會發生更好的事情。
從人的角度衍生出的信息的交互
信息的交互實際上是軟件開發過程當中須要重點關注的事情。信息的完整性、真實性，影響着開發過程當中風險的暴露。風險則決定了項目的成功與否，因此我認爲它是架構其中的一部分，它經常被人忽略，由於它既不屬於技術，也不屬於人員，更像管理工做，但其實它也跟架構有明顯的關係。
軟件項目的風險無非體如今如下四個方面:需求、技術、成本和進度。任何信息的不對等都有可能致使需求完成有誤、技術設計偏離、成本過大、進度延遲。怎麼樣規劃合理的信息交互、制定合理的反饋機制是架構須要考慮的問題之一。
總結和感悟
架構的目的是貼合市場需求指定合理的技術規劃、人員規劃、信息交互規劃，架構是不只僅侷限於技術層面的。一個軟件架構師，你須要統籌全局，深刻了解需求，瞭解業務的走向，瞭解技術的價值所在。也須要制定或迎合人員的搭配，制定信息交互的流程。
核心觀點
就是不能夠忽略市場需求在架構設計中的力量，
更不能夠忽略人在架構處理中所佔的比例大小。
過分關注技術自己是一個本末倒置的行爲。
這是我現階段比較深入的感悟，執筆記錄，也是最近吃的教訓的結果。個人觀點不必定正確，感謝你們觀看，若有疑問，歡迎留言。