如何成为架构师？3条有效的实战经验
“
希望你看完這一篇，能充分認知和了解架構師，認知對了，事就好辦了。
01
架構師的準確定義
架構師的職責應該是立足于技術和業務之間的中間角色或者平衡點， 在針對業務深刻理解的基礎上，針對業務中存在諸多變數，挑選適合的技術架構和技術方案。
結合現有的技術團隊的水平與特點，選擇合適的技術架構進行落地和實現。
02
首要任務，技術的選型
當你做架構設計時，必然會面臨技術選型的抉擇，不同的技術方案，架構也可能完全不同。
比如架構后端語言選型，采用java語言開發，還是php語言，c#開發，ruby開發，還是python開發，還是groovy開發等。
為什么要選擇這門語言？這是重點，是業務需（能快速開發發布php），還是人員需要（java開發資源多），還是未來可拓展架構需要（.net大型網站全面轉型java，你還會繼續使用.net么），還是技術需要（python在網絡爬蟲以及未來人工智能的使用場景）…
再比如移動端選型，App是純原生開發，還是Web App，抑或Hybrid App？iOS開發，語言上是選擇Objective-C還是Swift？架構模式用MVC，還是MVP，或者MVVM？
很多技術架構的選擇沒有弄清楚，盲選選擇技術架構，不僅不有利于開發，更不有利于業務需要。
這里普遍犯錯的地方就在于大部分都是半桶水，以為按照網上的經驗就可以直接copy，直接搬磚過來，實則根本沒有這塊的經驗。
再舉一個例子，早期訪問量巨大的.net轉java，京東、攜程..等等，為什么要轉是一回事，怎么轉是另外一回事，再比如最近某一國內最大的游戲網站.net開發，現在要轉java，找了一批人，最后發現java領域精通的人，往往并不知道.net領域的問題，這就涉及到怎么轉，哪部分可以轉java，哪部分不能轉，而不是全轉，為什么？
所以，架構師在做每一個決定需要考慮諸多因素，再比如高效的技術選型需要很高的學習曲線，在工期與人員素質之間需要權衡。精妙的技術架構并不能解決業務的快速迭代和變化，技術架構都是后知后覺的，無法準確的預知業務層面的變更與方向，故只能是跟隨的角色，這樣就必然會面臨技術架構迭代和升級的需求，技術架構從來都不是建立了之后，就無需修改，可以承載各方的多重期望。
03
其次，業務理解和拆解能力。
這一項是架構師的勝負手，大部分做IT的朋友，對業務的理解和拆解能力是比較差的，總以為把技術選型，架構搭建，技術難點發展為最核心的架構師能力。
今天，借用優知學院再次重申，這樣的觀點是及其錯誤的。沒有商業，沒有訪問量，沒有增長，沒有業務需要，需要技術來干什么？關于這一點，很多同學不以為然，之所以技術這10年發展迅速，需要感謝互聯網的快速發展，否則我們都失業了。特別是這一波人工智能的發展，未來基礎性的開發人員肯定會銳減，為啥？根本不需要這么多開發人員，基礎性開發工作，可替代性太強了。
架構師需要深入理解業務，不管是業務的流程，還是整塊業務需求，甚至包括業務細節，你需要重點關注，這一點很多做需求評估的時候，架構師不參加也是極其錯誤的。
也有很多公司在架構升級的時候，架構師根本不懂業務，就開始獨立拆分，就開始上手，拜托，業務沒搞懂就上來拆解，這就跟醫生沒有臨床試驗就開始做手術一個道理。
總之，公司的架構師不懂業務，這就是扯淡。
作者：陳睿mikechen是互聯網產品技術總監（優知學院發起人），擁有10以上的互聯網產品&技術經驗，曾先后歷任淘寶架構師，百度研發經理，攜程定制旅游CTO，擅長java,高并發架構，敏捷開發，團隊管理，產品策劃，產品運營數據以及行業分析。
優知學院（youzhixueyuan.com），是IT人升職加薪進階站，BAT產品技術總監經驗分享平臺。如果您對職場進階、架構師進階、轉型產品運營、CTO進階興趣濃厚，有志成為IT職場TOP3，那么這一站您不容錯過！
你可能也喜歡:
總結
以上是生活随笔為你收集整理的如何成为架构师？3条有效的实战经验的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 论文浅尝 | 知识图谱的单样本关系学习
- 下一篇： 论文浅尝 | 时序与因果关系联合推理