想成為移動端架構師需要會安卓和IOS應用開發的能力嗎？

哲學家常思考的問題：" 我是誰？"" 我從哪里來？"" 要到哪里去？不只是哲學家，我想每個人都有自己對這三個問題的認知。

如果我們要成為架構師，我們自己要面臨的三大問題：

找準自己定位：我是誰？在哪里？

怎樣做好架構師：我要做什么？

如何搭建架構師知識體系：我該怎么做？

這里面就是做事方法論：目標（我要做什么），方法（計劃）（我該怎么做）, 執行/行動

1、架構師定義

什么是架構師，這個聊架構話題時永恒的問題。每個公司對架構師的定位也有所不同，因為不同公司所處的階段，業務模式，應用場景也都不一樣。對架構的要求也不一樣。

在初創公司的野蠻生長階段：業務場景和需求邊界很難把握，有時候根本不需要架構師，產品需要快速迭代和變現，需求頻繁更新，這個時候需要的是快速實現。當然如果公司成長以后，這個階段就是欠下很多技術債，埋下很多坑，如果人員流動很頻繁，后期系統維護成本是非常巨大的。

在公司成長穩定階段：業務模式和應用場景邊界都已經比較清晰，這個時候最需要架構師需要架構師能對線上業務進行模塊劃分，系統拆分重構，并做好相關高可用的措施，以保證系統的穩定，安全、高效地運行。

不同的行業，對架構師的要求也不同，比如電商業務和AI領域，從架構到業務場景，完全是兩個物種。

在百度百科里面這么定義： 系統架構師是一個既需要掌控整體又需要洞悉局部瓶頸并依據具體的業務場景給出解決方案的團隊領導任務。具體來說是一個確認和評估系統需求，給出開發規范，搭建系統實現的核心構架，并澄清技術細節、掃清主要難點的技術人員。主要著眼于系統的“技術實現”。因此架構師應該是特定的開發平臺、語言、工具的大師，對常見應用場景能馬上給出最恰當的解決方案，同時要對所屬的開發團隊有足夠的了解，能夠評估自己的團隊實現特定的功能需求需要的代價。系統架構師負責設計系統整體架構，從需求到設計的每個細節都要考慮到，把握整個項目，使設計的項目盡量效率高，開發容易，維護方便，升級簡單等。

架構師實際上就是軟件的總體設計師。打個通俗的比方比如某個工程總設計師，類似三峽工程的總設計師。

架構師的形成一定是在實踐中積累起來的，而并非上了幾次培訓班，讀了幾本書就可以成功的，架構師是在工程實踐中培養出來的!

2、架構師作用/職責

架構師在整個軟件系統開發過程中都起著重要的作用，并隨著開發進程的推進而其職責或關注點不斷地變化。

1）、按軟件開發過程維度來說：

需求階段：軟件架構師主要負責理解和管理非功能性系統需求，比如軟件的可維護性、性能、復用性、可靠性、有效性和 可測試性等等，此外，架構師還要經常審查和客戶及市場人員所提出的需求，確認開發 團隊所提出的設計;

架構設計階段：架構師負責對整個系統架構設計，制定開發規范、開發計劃，指導整個開發團隊完成這個計劃。

開發階段：架構師則成為詳細設計者和代碼編寫者的顧問，并且經常性地要舉行一些技術研討會、技術培訓班等;

測試和交付階段：協調做好相關測試和部署。

維護階段：軟件架構師就開始為下一版本的產品是否應該增加新的功能模塊進行決策。

2）、按職能維度：

1 確認需求

架構師要懂得用戶需求，理解用戶真正想要什么，這使得架構師必須要和分析人員不斷溝通，反復確認需求規格說明書，以此來保證他精準清楚用戶需求。

項目經理劉先生在受訪時說：「架構師會與很多人溝通，例如開發人員，例如我們項目經理，有時甚至是用戶本身。架構設計的目的很明確，目的是什么呢？挖掘用戶需求。」

2 系統分解

在架構師認可需求規格說明書后，架構師已明確用戶需求是是什么，這時候便看架構師的分解能力了。

系統分解包括縱向分解和橫向分解：

橫向分解是對系統分解成不同的邏輯層，確定層與層之間的關系。是指基于技術架構層次進行的人員角色分工和任務分解。常見的分層：

應用層：主要負責具體的業務邏輯處理

服務層：提供可復用的服務

數據層：負責數據的存儲和訪問

分層注意事項：①必須合理規劃層次邊界和接口；②禁止跨層次的調用及逆向調用。

縱向分解是將不同的功能和服務分割開來，包裝成高內聚低耦合的模塊單元，有助于軟件開發和維護，還便于不同模塊的分布式部署，提高網站的并發處理能力和功能擴展能力。

3 技術選型

在系統分解后，架構師會最終形成軟件整體架構，接下來，架構師的職責是技術選型。

前端到底用瘦客戶端還是富客戶端呢？數據庫是用MySQL還是MSSQL又或是Oracle呢？架構師張先生在接受采訪時說，在了解用戶需求后，分解完系統后，技術選型是非常重要的環節，提出各個方向，我再進行評估。不過，很多人都以為架構師是有決定權的，其實不是，架構師沒有拍版的權力，決定由項目經理來做。

架構師在技術選型階段會提供參考信息給項目經理，項目經理再從預算、進度、人力、資源等各方面情況來權衡，最終確認。

4 制定技術規格說明

如前文調查顯示，架構師在項目開發過程中是「靈魂人物」，并且要具備協調組織能力和懂得人員分工。

在制定技術規格說明階段，架構師要協調起所有的開發人員，架構師通常會用技術規格說明書與開發人員保持溝通，讓開發人員能從各個視角去觀測、理解他們負責的模塊或者子系統，確保開發人員能夠按照架構意圖實現各項功能。

3）、關注點：

?方向規劃：有想法和技術展望目標，制定短期目標

?架構設計：集思廣益來設計，歸類總結，根據討論結果制定規范。設計不僅僅是技術相關（業務流程，業務方向，模塊劃分組合，框架設計，流程紕漏等），設計出來還是需要實施的。

?技術攻關：疑難技術點攻關，將問題集中化解決，提供平臺化解決方案以及選型決策。

?解決疑難問題：發現各類型問題（不僅僅是技術），通過規范，演講，繪圖等方式解決隱患。

?互動溝通：部門之間溝通，開發之間溝通，產品之間溝通，市場溝通，溝通后產出圖形化文檔及設計。

?關注點：秩序，統一，規范，穩定，高效

架構是要靠團隊做出來的

?保持和架構的溝通，架構通過團隊的溝通總結出方向

?隊員經常提出自己碰到的問題，并分享給大家，思維碰撞促進發展

?產品經常提出設想和規劃，能夠使得架構符合未來發展需求

?運維經常提出隱患及分析，能使得架構快速拆分模塊

?定期做總結歸納以此分析問題，解決問題

?團隊成長、就是每個人的成長、每個人成長眼界自然增長

?團隊的成功、就是產品的成功，產品的成功就是公司的成功

公司的成功可以給你加光環，但光環不代表自己的能力代表經歷

3、架構師分類

其實架構師就是個title，每個公司稱呼都可能不一樣，和架構概念一樣。

軟件架構師：

軟件架構師是軟件行業中一種新興職業，工作職責是在一個軟件項目開發過程中，將客戶的需求轉換為規范的開發計劃及文本，并制定這個項目的總體架構，指導整個開發團隊完成這個計劃。主導系統全局分析設計和實施、負責軟件構架和關鍵技術決策的人員，比如這些架構師的title可能是JAVA架構師、Python架構師、LAPM架構師等等。

web架構師：

web架構師是網站系統、功能、模塊、流程的設計師，架構師，好比是高樓大廈的設計人員，通常一座大廈在建之前，都先由設計師將藍圖描繪出來，包括其形狀、結構、尺寸、材料等等，然后建筑工程師帶領工人們按照藍圖將大廈一層一層地建起來

架構師也要看在什么樣的公司，中小公司很多架構師都是全能的。通常公司規模和體系越大，分工會越細：大體可以這么分類：

解決方案架構師：與客戶探討業務需求，將業務、市場，與技術、產品結合起來，為客戶提供解決他們需求的方案。比如阿里云針對大客戶都有解決方案架構師。

系統架構師: 也稱應用架構師。最終確認和評估系統需求，并將業務轉換為技術，為研發人員制訂核心框架與技術規范 為研發工作澄清技術細節并掃清技術障礙 。服務器負載，可靠性，伸縮，擴展，數據庫切分，緩存應用

平臺架構師:這里的平臺其實包括兩個平臺，一個是系統平臺，也就是負責搭建多個系統整合的系統應用平臺；另外一個其實是基礎平臺，是專門負責搭建基礎技術平臺；兩者其 實區別蠻大，也經常容易被從業人員混亂。舉個簡單例子，金蝶有平臺架構師一職，但是金蝶BOSS應用和金蝶中間件兩者招聘的對象和技術要求是截然不同的。

業務架構師：業務架構其實已經開始脫離技術層面了，但是它要求架構師有跨越多系統的大局觀，去整合和組織不同系統的技術平臺與交互模式。其實這個職位的未來也就是CIO了。 主要內容：理解業務，梳理模型，設計模式，接口，數據交互。

網絡架構師:過去，我們可能聽的最多的是網絡工程師。不錯，一個優秀的網絡架構師必須有足夠的網絡技術基底，并且它的關注點也是系統的基礎架構。比如說如果搭建并優化集群環境，如果構建基于云計算的系統應用與部署等等。它對于像淘寶、騰訊這樣的互聯網公司是極其重要的。

移動架構師:移動互聯網的迅猛發展橫向和縱向都細分出了很多新的職責和崗位，移動架構師的職責和作用日益重要，既要整體和全局考慮整個前后端的軟件系統架構，又要重點深入移動客戶端的架構設計的方方面面，既要有跨平臺思維，又要拿捏好原生和混合開發的尺度，另外移動應用的特點，導致移動架構師必須要比傳統系統架構師更加注重非功能性的質量屬性。

前端架構師:這也是移動互聯網的迅猛發展而細分出來的新的職責和崗位，這里的前端特指網站開發中的前端，主要考慮前端呈現層的設計（HTML/CSS/JS/AJAX/RIA/…），跨瀏覽器設計等等。

大數據架構師：比如某些公司做大數據處理，需要理解業務，并通過大數據相關技術來實現。

4、架構師具備素質能力

? 精通某項技術，能夠從本質上類比，觸類旁通其他技術

? 對等所有技術，只有合適和不合適，沒有喜歡和不喜歡。

? 視野開闊，了解不同技術的優缺點。知道使用某項開源技術實現某項業務需求，能夠辨別重復造輪子。

? 精通設計模式，但又不泛用。

? 把系統拆分成多個子系統或模塊。模塊之間盡量松耦合，使得原先串行的開發任務變得可以并行發展。

? 能清楚系統的瓶頸在什么地方， 不斷定位技術難度，開發進度，性能，內存等個方面的瓶頸。不斷調整骨干力量解決瓶頸，在風險爆發之前消除隱患。

? 能做好前瞻性設計，預判到需求可能產生的變化。

架構師團隊內做的事情

?溝通能力：各個方面都要了解，人人想法及規劃都要知道，了解產品思想，用了什么方法實現的

?組織能力：組織推動各種技術的改進及功能的完善

?談判代表：左右兩難的時候的調解人

?設計模塊及業務：通過圖形化設計發現開發后才會發現的業務問題

?成本規劃：通過過往經驗評估成本及步伐

?愿望收集：不斷收集建議及愿望，一步步實現

?傳播布道：不斷參與行業交流，提高理論及技術知識科普分享團隊

5、架構師職場攻略

《大型網站技術架構+核心原理與案例分析》總結：

架構師需要處理好個人、團隊、公司的利益。需要不斷的在工作中發現問題，解決問題，提升工作經驗，知識技能和核心競爭力。擴大自身影響力，達成工作績效。

1、發現問題，尋找突破

即使在一流的技術團隊，也有數不清的問題，團隊人員已經習慣這些積重難返的問題，而且解決問題投入產出比不大。例如：

1）數據庫線程池存在安全漏洞。

2）版本管理混亂。

作為一個新人，從局外旁觀者的視角看待，自然發現很多問題。如果新人急于表現自己，證明自己，往往是事與愿違，四處碰壁。因此新人要先融入團隊，和團隊共進退，等熟悉情況，了解問題深淺，再尋找突破口，擇機而動。

2、提出問題，尋求支持

1) 把“我的問題”表述成“我們的問題”：

人們都不喜歡問題，問題意味著麻煩。當人們聽到你說，“我遇到一個問題的時候”，下意識的遠離你的問題。 如果需要他們的支持，就想辦法把你的問題變成他們的問題，是他遇到了問題，而你來幫忙解決。

既然你也是團隊一員，問題表述為“我們的問題”。

1) 給上司提封閉式問題，給下屬提開發式問題：

上司一般是做決策，因此給上司提問需要給出建設性的方案或者建議，然后希望得到他的支持，給上司提問：“你覺得A和B哪個方案更好？”

給下屬則相反，用開放式的問題啟發他去思考，尋找創新的解決方案。“元芳，這個問題你怎么看？”

3) 指出問題而不是批評人:

如果遇到問題，不要責問他為什么出現問題，而是說問題的緊迫性和解決的優先級。

4）用贊同的方式提出問題：

如果人們遇到：“你這里有問題”可能會本能自我保護而拒絕你的建議。

而如果這么說“我非常贊同你的方案，但是我有個小小的建議”。

3、解決問題，達成績效

在解決我的問題之前，先解決你的問題：

適當的逃避問題：比如我去開個會，回來再回答的你問題。

做好以下幾點，基本離你說的移動架構師不遠了

選，Java后臺還是客戶端開發？

Java跟C、C++、PHP、Python等一直較勁，在當前的現實中，也穩坐編程語言榜首

面向對象的思想在應用開發領域占主導，Java往往成為其代名詞

Java技術的人多，一直以來也有大公司資助，所以發展一直不錯，進入了良性循環

從企業的角度來說，找Java后臺的人相對比較容易

后臺被認為是技術核心，而客戶端，被認為技術含量不高

貪省事，讓Java后臺的架構師順便來一下客戶端幾個人就好了，這可能是有些企業負責人自然而然的想法

客戶端技術和后臺技術的側重點完全不同，連編程語言都不同。Java能統一后臺開發；但是從目前的趨勢看，雖然客戶端也在強調統一，不過語言肯定不是Java

Java后臺的人跟用戶離得太遠，與產品人員溝通，那真是雞同鴨講

如果產品真的是為了給用戶用，那么選客戶端背景的人員做移動架構師要好一點。

客戶端是IOS，android，還是JS，根據企業喜好來選吧。根據本人經驗來說，當然是IOS啦。智能手機這么熱，是誰帶起來的？從編程體驗，程序美感來說，誰的最出色？只要干過移動開發的人，這幾個問題都是不言而喻的

作為移動架構師，要重點注意的三個問題

架構師作為中層管理，直接領導一般是總監了。技術加管理的綜合職位，在技術和管理上面的思路，跟總監要保持一致。這方面是最重要的。如果這點做不好，趁早換地方，不讓對自己，對總監，對企業都不好。有兩種情況需要注意：一種是跟總監合作很好，但是總監自己要換地方；這里，最好和總監一起走，能遇到一個好領導不是一件容易的事。另一種是空降一個總監過來，但是兩人想不到一塊去。這個時候就有點糾結，離開嘛，感覺舍不得，前面的付出要泡湯；留下嘛，感覺又很別扭。這種情況，需要加強溝通，調整自己，努力使合作更順利一點。否則，還是要走，畢竟胳膊擰不過大腿，估計大家都懂的。

跟周邊部門的合作要做好，特別是產品和測試，運營也要注意一下。否則，將會導致很多稍大公司的部門墻。

跟具體的開發人員也要搞好關系。管理的本質是自己不干活，但是團隊的整體效率要更高。這點如果做不好，最直接的影響就是團隊的績效不高，團隊缺乏凝聚力，團隊氣氛壓抑。這在很多公司都有發生。

如何與總監CTO合作好？

從思想上認識到，兩者是利益完全一致者。總監為架構師拓展上升空間，而架構師將總監的規劃切實落地。

保證足夠的溝通，可以約定一個固定溝通機制，比如每2周一次。讓雙方在思想上保持同步和一致。

如果CTO也是客戶端技術出生，那么架構師可以多探討一些技術經驗，將CTO的一些技術構想落到實處，同時自己也能在技術上獲得提升。

如果CTO是Java后臺技術出生，那么CTO盡量授權，架構師側重在設計思路，技術可行性，技術風險等較高的層面內容。

架構師應該帶著方案和CTO溝通，講清楚AB方案的優缺點。可以讓CTO來下決心，就算是架構師下決策，也要獲得CTO的認可。

如果意見出現分歧，最好的方式是先擱置，等條件成熟了，很可能意見會趨于一致。如果不能等，只要CTO的意見不是太離譜，還是按照CTO的意見執行比較好。如果有十足把握，自己的方案更好，那么也要得到CTO的許可和諒解，否則千萬不要這么做。

如何與周邊部門合作好？

產品經理一般不懂技術。架構師的作用就是幫他解決這個問題。在理解了需求之后，要進行技術可行性分析。從技術的角度，提出改善意見。在不改變整體方案的前提下，修改設計，方便實現。這就需要產品經理和架構師的合作。

與后臺架構師搞好合作，從后臺到實現，整條鏈路太長，一個人管不過來，需要兩人好好合作，共同把好技術關。

測試，要當作開發的朋友看待，是自己人。可以考慮讓測試人員在“自測”階段介入，幫助開發人員提供測試案例。

運營，關系稍微遠了一點。關鍵點是及早介入，不然，到臨上線了，要加入一對的運營需求，就可能影響產品投放時間了。

總之，和周邊部門，應該以合作為主，及早溝通，將風險消滅在反生之前。

如何與團隊成員溝通

移動開發團隊人數不多，但是角色和開發語音多。有IOS，android，還有JS和Java網關。

如果一個角色超過3個人，那么就應該設置一個TeamLeader，進行授權

對于自己擅長的技術，要分一兩個任務給自己，和兄弟們一起戰斗。中層人員需要在一線。

對于自己不擅長的技術，可以采用“結對編程”的方法，逐漸進入角色。程序基本是相同的，還是能夠理解和參與討論的。

對于幾個Leader，要重點溝通，在大方向上保證思想一致，給他們空間，協助他們做出成績。

重點注意團隊的正能量以及活躍的氣氛，人不是機器。和諧的氛圍比冰冷的制度和懲罰要好得多。

記好團隊的功績和成果，提高團隊成員集體榮譽感，將奮斗目標引導到“自我實現”上來。

關于技術

整體上是一專多能

以IOS技術為主，跟上蘋果的節奏，隨時學習新技術。深度技術按照需求來。

Object-C為主，畢竟在用，并且成熟度高。

Swift也要學，這是蘋果的未來。

Java要優先學，android和后臺都要用到

JS也要學，最近H5勢頭比較猛

總之，架構師是一個綜合素質的體現，打鐵還需自身硬，能解決問題，或者能帶動周邊的人解決問題，才是關鍵，至于職位、位置，這只是一種職業稱謂，你牛逼了，還在乎別人稱你架構師，還是其他的嗎，技術是硬實力，情商是軟實力，君子性非異也，善假于物也。自個體會。