老鐵們，大家好，相信還有很多朋友對于mvp架構(gòu)和mvc架構(gòu)和ssm框架與mvc的關(guān)系的相關(guān)問題不太懂，沒關(guān)系，今天就由我來為大家分享分享mvp架構(gòu)和mvc架構(gòu)以及ssm框架與mvc的關(guān)系的問題，文章篇幅可能偏長，希望可以幫助到大家，下面一起來看看吧！
mvp是什么單位
mvp的全稱為Model-View-Presenter，Model提供數(shù)據(jù)，View負(fù)責(zé)顯示，Controller/Presenter負(fù)責(zé)邏輯的處理。MVP與MVC有著一個(gè)重大的區(qū)別：在MVP中View并不直接使用Model，它們之間的通信是通過Presenter(MVC中的Controller)來進(jìn)行的，所有的交互都發(fā)生在Presenter內(nèi)部，而在MVC中View會直接從Model中讀取數(shù)據(jù)而不是通過Controller。
mvcmvpmvvm三種模型的區(qū)別
MVC、MVP和MVVM是三種常見的前端架構(gòu)模式，它們的區(qū)別如下：
MVC（Model-View-Controller）模型：
1.Model：數(shù)據(jù)層，負(fù)責(zé)處理數(shù)據(jù)和業(yè)務(wù)邏輯。
2.View：視圖層，負(fù)責(zé)展示數(shù)據(jù)和接收用戶操作。
3.Controller：控制器，負(fù)責(zé)協(xié)調(diào)Model和View，處理用戶操作和業(yè)務(wù)邏輯。
MVP（Model-View-Presenter）模型：
1.Model：數(shù)據(jù)層，同MVC模型。
2.View：視圖層，同MVC模型。
3.Presenter：負(fù)責(zé)協(xié)調(diào)Model和View，處理用戶操作和業(yè)務(wù)邏輯，與Controller不同的是，Presenter并沒有直接控制視圖，而是通過接口與視圖交互。
MVVM（Model-View-ViewModel）模型：
1.Model：數(shù)據(jù)層，同MVC模型。
2.View：視圖層，同MVC模型。
3.ViewModel：負(fù)責(zé)協(xié)調(diào)Model和View，處理用戶操作和業(yè)務(wù)邏輯，與Presenter不同的是，ViewModel通過雙向數(shù)據(jù)綁定（DataBinding）將View和Model綁定在一起，當(dāng)數(shù)據(jù)發(fā)生變化時(shí)，View會自動更新。
總體來說，MVC主要強(qiáng)調(diào)控制器的作用，MVP主要強(qiáng)調(diào)Presenter的作用，MVVM則主要強(qiáng)調(diào)雙向數(shù)據(jù)綁定的作用。它們各有優(yōu)缺點(diǎn)，應(yīng)根據(jù)具體場景選擇適合的模式。
想成為移動端架構(gòu)師需要會安卓和IOS應(yīng)用開發(fā)的能力嗎
哲學(xué)家常思考的問題："我是誰？""我從哪里來？""要到哪里去？不只是哲學(xué)家，我想每個(gè)人都有自己對這三個(gè)問題的認(rèn)知。
如果我們要成為架構(gòu)師，我們自己要面臨的三大問題：
找準(zhǔn)自己定位：我是誰？在哪里？
怎樣做好架構(gòu)師：我要做什么？
如何搭建架構(gòu)師知識體系：我該怎么做？
這里面就是做事方法論：目標(biāo)（我要做什么），方法（計(jì)劃）（我該怎么做）,執(zhí)行/行動
1、架構(gòu)師定義什么是架構(gòu)師，這個(gè)聊架構(gòu)話題時(shí)永恒的問題。每個(gè)公司對架構(gòu)師的定位也有所不同，因?yàn)椴煌舅幍碾A段，業(yè)務(wù)模式，應(yīng)用場景也都不一樣。對架構(gòu)的要求也不一樣。
在初創(chuàng)公司的野蠻生長階段：業(yè)務(wù)場景和需求邊界很難把握，有時(shí)候根本不需要架構(gòu)師，產(chǎn)品需要快速迭代和變現(xiàn)，需求頻繁更新，這個(gè)時(shí)候需要的是快速實(shí)現(xiàn)。當(dāng)然如果公司成長以后，這個(gè)階段就是欠下很多技術(shù)債，埋下很多坑，如果人員流動很頻繁，后期系統(tǒng)維護(hù)成本是非常巨大的。
在公司成長穩(wěn)定階段：業(yè)務(wù)模式和應(yīng)用場景邊界都已經(jīng)比較清晰，這個(gè)時(shí)候最需要架構(gòu)師需要架構(gòu)師能對線上業(yè)務(wù)進(jìn)行模塊劃分，系統(tǒng)拆分重構(gòu)，并做好相關(guān)高可用的措施，以保證系統(tǒng)的穩(wěn)定，安全、高效地運(yùn)行。
不同的行業(yè)，對架構(gòu)師的要求也不同，比如電商業(yè)務(wù)和AI領(lǐng)域，從架構(gòu)到業(yè)務(wù)場景，完全是兩個(gè)物種。
在百度百科里面這么定義：系統(tǒng)架構(gòu)師是一個(gè)既需要掌控整體又需要洞悉局部瓶頸并依據(jù)具體的業(yè)務(wù)場景給出解決方案的團(tuán)隊(duì)領(lǐng)導(dǎo)任務(wù)。具體來說是一個(gè)確認(rèn)和評估系統(tǒng)需求，給出開發(fā)規(guī)范，搭建系統(tǒng)實(shí)現(xiàn)的核心構(gòu)架，并澄清技術(shù)細(xì)節(jié)、掃清主要難點(diǎn)的技術(shù)人員。主要著眼于系統(tǒng)的“技術(shù)實(shí)現(xiàn)”。因此架構(gòu)師應(yīng)該是特定的開發(fā)平臺、語言、工具的大師，對常見應(yīng)用場景能馬上給出最恰當(dāng)?shù)慕鉀Q方案，同時(shí)要對所屬的開發(fā)團(tuán)隊(duì)有足夠的了解，能夠評估自己的團(tuán)隊(duì)實(shí)現(xiàn)特定的功能需求需要的代價(jià)。系統(tǒng)架構(gòu)師負(fù)責(zé)設(shè)計(jì)系統(tǒng)整體架構(gòu)，從需求到設(shè)計(jì)的每個(gè)細(xì)節(jié)都要考慮到，把握整個(gè)項(xiàng)目，使設(shè)計(jì)的項(xiàng)目盡量效率高，開發(fā)容易，維護(hù)方便，升級簡單等。架構(gòu)師實(shí)際上就是軟件的總體設(shè)計(jì)師。打個(gè)通俗的比方比如某個(gè)工程總設(shè)計(jì)師，類似三峽工程的總設(shè)計(jì)師。
架構(gòu)師的形成一定是在實(shí)踐中積累起來的，而并非上了幾次培訓(xùn)班，讀了幾本書就可以成功的，架構(gòu)師是在工程實(shí)踐中培養(yǎng)出來的!
2、架構(gòu)師作用/職責(zé)架構(gòu)師在整個(gè)軟件系統(tǒng)開發(fā)過程中都起著重要的作用，并隨著開發(fā)進(jìn)程的推進(jìn)而其職責(zé)或關(guān)注點(diǎn)不斷地變化。
1）、按軟件開發(fā)過程維度來說：
需求階段：軟件架構(gòu)師主要負(fù)責(zé)理解和管理非功能性系統(tǒng)需求，比如軟件的可維護(hù)性、性能、復(fù)用性、可靠性、有效性和可測試性等等，此外，架構(gòu)師還要經(jīng)常審查和客戶及市場人員所提出的需求，確認(rèn)開發(fā)團(tuán)隊(duì)所提出的設(shè)計(jì);
架構(gòu)設(shè)計(jì)階段：架構(gòu)師負(fù)責(zé)對整個(gè)系統(tǒng)架構(gòu)設(shè)計(jì)，制定開發(fā)規(guī)范、開發(fā)計(jì)劃，指導(dǎo)整個(gè)開發(fā)團(tuán)隊(duì)完成這個(gè)計(jì)劃。
開發(fā)階段：架構(gòu)師則成為詳細(xì)設(shè)計(jì)者和代碼編寫者的顧問，并且經(jīng)常性地要舉行一些技術(shù)研討會、技術(shù)培訓(xùn)班等;
測試和交付階段：協(xié)調(diào)做好相關(guān)測試和部署。
維護(hù)階段：軟件架構(gòu)師就開始為下一版本的產(chǎn)品是否應(yīng)該增加新的功能模塊進(jìn)行決策。
2）、按職能維度：
1確認(rèn)需求
架構(gòu)師要懂得用戶需求，理解用戶真正想要什么，這使得架構(gòu)師必須要和分析人員不斷溝通，反復(fù)確認(rèn)需求規(guī)格說明書，以此來保證他精準(zhǔn)清楚用戶需求。
項(xiàng)目經(jīng)理劉先生在受訪時(shí)說：「架構(gòu)師會與很多人溝通，例如開發(fā)人員，例如我們項(xiàng)目經(jīng)理，有時(shí)甚至是用戶本身。架構(gòu)設(shè)計(jì)的目的很明確，目的是什么呢？挖掘用戶需求。」
2系統(tǒng)分解
在架構(gòu)師認(rèn)可需求規(guī)格說明書后，架構(gòu)師已明確用戶需求是是什么，這時(shí)候便看架構(gòu)師的分解能力了。
系統(tǒng)分解包括縱向分解和橫向分解：
橫向分解是對系統(tǒng)分解成不同的邏輯層，確定層與層之間的關(guān)系。是指基于技術(shù)架構(gòu)層次進(jìn)行的人員角色分工和任務(wù)分解。常見的分層：
應(yīng)用層：主要負(fù)責(zé)具體的業(yè)務(wù)邏輯處理
服務(wù)層：提供可復(fù)用的服務(wù)
數(shù)據(jù)層：負(fù)責(zé)數(shù)據(jù)的存儲和訪問
分層注意事項(xiàng)：①必須合理規(guī)劃層次邊界和接口；②禁止跨層次的調(diào)用及逆向調(diào)用。
縱向分解是將不同的功能和服務(wù)分割開來，包裝成高內(nèi)聚低耦合的模塊單元，有助于軟件開發(fā)和維護(hù)，還便于不同模塊的分布式部署，提高網(wǎng)站的并發(fā)處理能力和功能擴(kuò)展能力。
3技術(shù)選型
在系統(tǒng)分解后，架構(gòu)師會最終形成軟件整體架構(gòu)，接下來，架構(gòu)師的職責(zé)是技術(shù)選型。
前端到底用瘦客戶端還是富客戶端呢？數(shù)據(jù)庫是用MySQL還是MSSQL又或是Oracle呢？架構(gòu)師張先生在接受采訪時(shí)說，在了解用戶需求后，分解完系統(tǒng)后，技術(shù)選型是非常重要的環(huán)節(jié)，提出各個(gè)方向，我再進(jìn)行評估。不過，很多人都以為架構(gòu)師是有決定權(quán)的，其實(shí)不是，架構(gòu)師沒有拍版的權(quán)力，決定由項(xiàng)目經(jīng)理來做。
架構(gòu)師在技術(shù)選型階段會提供參考信息給項(xiàng)目經(jīng)理，項(xiàng)目經(jīng)理再從預(yù)算、進(jìn)度、人力、資源等各方面情況來權(quán)衡，最終確認(rèn)。
4制定技術(shù)規(guī)格說明
如前文調(diào)查顯示，架構(gòu)師在項(xiàng)目開發(fā)過程中是「靈魂人物」，并且要具備協(xié)調(diào)組織能力和懂得人員分工。
在制定技術(shù)規(guī)格說明階段，架構(gòu)師要協(xié)調(diào)起所有的開發(fā)人員，架構(gòu)師通常會用技術(shù)規(guī)格說明書與開發(fā)人員保持溝通，讓開發(fā)人員能從各個(gè)視角去觀測、理解他們負(fù)責(zé)的模塊或者子系統(tǒng)，確保開發(fā)人員能夠按照架構(gòu)意圖實(shí)現(xiàn)各項(xiàng)功能。
3）、關(guān)注點(diǎn)：
?方向規(guī)劃：有想法和技術(shù)展望目標(biāo)，制定短期目標(biāo)
?架構(gòu)設(shè)計(jì)：集思廣益來設(shè)計(jì)，歸類總結(jié)，根據(jù)討論結(jié)果制定規(guī)范。設(shè)計(jì)不僅僅是技術(shù)相關(guān)（業(yè)務(wù)流程，業(yè)務(wù)方向，模塊劃分組合，框架設(shè)計(jì)，流程紕漏等），設(shè)計(jì)出來還是需要實(shí)施的。
?技術(shù)攻關(guān)：疑難技術(shù)點(diǎn)攻關(guān)，將問題集中化解決，提供平臺化解決方案以及選型決策。
?解決疑難問題：發(fā)現(xiàn)各類型問題（不僅僅是技術(shù)），通過規(guī)范，演講，繪圖等方式解決隱患。
?互動溝通：部門之間溝通，開發(fā)之間溝通，產(chǎn)品之間溝通，市場溝通，溝通后產(chǎn)出圖形化文檔及設(shè)計(jì)。
?關(guān)注點(diǎn)：秩序，統(tǒng)一，規(guī)范，穩(wěn)定，高效
架構(gòu)是要靠團(tuán)隊(duì)做出來的
?保持和架構(gòu)的溝通，架構(gòu)通過團(tuán)隊(duì)的溝通總結(jié)出方向
?隊(duì)員經(jīng)常提出自己碰到的問題，并分享給大家，思維碰撞促進(jìn)發(fā)展
?產(chǎn)品經(jīng)常提出設(shè)想和規(guī)劃，能夠使得架構(gòu)符合未來發(fā)展需求
?運(yùn)維經(jīng)常提出隱患及分析，能使得架構(gòu)快速拆分模塊
?定期做總結(jié)歸納以此分析問題，解決問題
?團(tuán)隊(duì)成長、就是每個(gè)人的成長、每個(gè)人成長眼界自然增長
?團(tuán)隊(duì)的成功、就是產(chǎn)品的成功，產(chǎn)品的成功就是公司的成功
公司的成功可以給你加光環(huán)，但光環(huán)不代表自己的能力代表經(jīng)歷
3、架構(gòu)師分類
其實(shí)架構(gòu)師就是個(gè)title，每個(gè)公司稱呼都可能不一樣，和架構(gòu)概念一樣。
軟件架構(gòu)師：
軟件架構(gòu)師是軟件行業(yè)中一種新興職業(yè)，工作職責(zé)是在一個(gè)軟件項(xiàng)目開發(fā)過程中，將客戶的需求轉(zhuǎn)換為規(guī)范的開發(fā)計(jì)劃及文本，并制定這個(gè)項(xiàng)目的總體架構(gòu)，指導(dǎo)整個(gè)開發(fā)團(tuán)隊(duì)完成這個(gè)計(jì)劃。主導(dǎo)系統(tǒng)全局分析設(shè)計(jì)和實(shí)施、負(fù)責(zé)軟件構(gòu)架和關(guān)鍵技術(shù)決策的人員，比如這些架構(gòu)師的title可能是JAVA架構(gòu)師、Python架構(gòu)師、LAPM架構(gòu)師等等。
web架構(gòu)師：
web架構(gòu)師是網(wǎng)站系統(tǒng)、功能、模塊、流程的設(shè)計(jì)師，架構(gòu)師，好比是高樓大廈的設(shè)計(jì)人員，通常一座大廈在建之前，都先由設(shè)計(jì)師將藍(lán)圖描繪出來，包括其形狀、結(jié)構(gòu)、尺寸、材料等等，然后建筑工程師帶領(lǐng)工人們按照藍(lán)圖將大廈一層一層地建起來
架構(gòu)師也要看在什么樣的公司，中小公司很多架構(gòu)師都是全能的。通常公司規(guī)模和體系越大，分工會越細(xì)：大體可以這么分類：
解決方案架構(gòu)師：與客戶探討業(yè)務(wù)需求，將業(yè)務(wù)、市場，與技術(shù)、產(chǎn)品結(jié)合起來，為客戶提供解決他們需求的方案。比如阿里云針對大客戶都有解決方案架構(gòu)師。
系統(tǒng)架構(gòu)師:也稱應(yīng)用架構(gòu)師。最終確認(rèn)和評估系統(tǒng)需求，并將業(yè)務(wù)轉(zhuǎn)換為技術(shù)，為研發(fā)人員制訂核心框架與技術(shù)規(guī)范為研發(fā)工作澄清技術(shù)細(xì)節(jié)并掃清技術(shù)障礙。服務(wù)器負(fù)載，可靠性，伸縮，擴(kuò)展，數(shù)據(jù)庫切分，緩存應(yīng)用
平臺架構(gòu)師:這里的平臺其實(shí)包括兩個(gè)平臺，一個(gè)是系統(tǒng)平臺，也就是負(fù)責(zé)搭建多個(gè)系統(tǒng)整合的系統(tǒng)應(yīng)用平臺；另外一個(gè)其實(shí)是基礎(chǔ)平臺，是專門負(fù)責(zé)搭建基礎(chǔ)技術(shù)平臺；兩者其實(shí)區(qū)別蠻大，也經(jīng)常容易被從業(yè)人員混亂。舉個(gè)簡單例子，金蝶有平臺架構(gòu)師一職，但是金蝶BOSS應(yīng)用和金蝶中間件兩者招聘的對象和技術(shù)要求是截然不同的。
業(yè)務(wù)架構(gòu)師：業(yè)務(wù)架構(gòu)其實(shí)已經(jīng)開始脫離技術(shù)層面了，但是它要求架構(gòu)師有跨越多系統(tǒng)的大局觀，去整合和組織不同系統(tǒng)的技術(shù)平臺與交互模式。其實(shí)這個(gè)職位的未來也就是CIO了。主要內(nèi)容：理解業(yè)務(wù)，梳理模型，設(shè)計(jì)模式，接口，數(shù)據(jù)交互。
網(wǎng)絡(luò)架構(gòu)師:過去，我們可能聽的最多的是網(wǎng)絡(luò)工程師。不錯(cuò)，一個(gè)優(yōu)秀的網(wǎng)絡(luò)架構(gòu)師必須有足夠的網(wǎng)絡(luò)技術(shù)基底，并且它的關(guān)注點(diǎn)也是系統(tǒng)的基礎(chǔ)架構(gòu)。比如說如果搭建并優(yōu)化集群環(huán)境，如果構(gòu)建基于云計(jì)算的系統(tǒng)應(yīng)用與部署等等。它對于像淘寶、騰訊這樣的互聯(lián)網(wǎng)公司是極其重要的。
移動架構(gòu)師:移動互聯(lián)網(wǎng)的迅猛發(fā)展橫向和縱向都細(xì)分出了很多新的職責(zé)和崗位，移動架構(gòu)師的職責(zé)和作用日益重要，既要整體和全局考慮整個(gè)前后端的軟件系統(tǒng)架構(gòu)，又要重點(diǎn)深入移動客戶端的架構(gòu)設(shè)計(jì)的方方面面，既要有跨平臺思維，又要拿捏好原生和混合開發(fā)的尺度，另外移動應(yīng)用的特點(diǎn)，導(dǎo)致移動架構(gòu)師必須要比傳統(tǒng)系統(tǒng)架構(gòu)師更加注重非功能性的質(zhì)量屬性。
前端架構(gòu)師:這也是移動互聯(lián)網(wǎng)的迅猛發(fā)展而細(xì)分出來的新的職責(zé)和崗位，這里的前端特指網(wǎng)站開發(fā)中的前端，主要考慮前端呈現(xiàn)層的設(shè)計(jì)（HTML/CSS/JS/AJAX/RIA/…），跨瀏覽器設(shè)計(jì)等等。
大數(shù)據(jù)架構(gòu)師：比如某些公司做大數(shù)據(jù)處理，需要理解業(yè)務(wù)，并通過大數(shù)據(jù)相關(guān)技術(shù)來實(shí)現(xiàn)。
4、架構(gòu)師具備素質(zhì)能力
?精通某項(xiàng)技術(shù)，能夠從本質(zhì)上類比，觸類旁通其他技術(shù)
?對等所有技術(shù)，只有合適和不合適，沒有喜歡和不喜歡。
?視野開闊，了解不同技術(shù)的優(yōu)缺點(diǎn)。知道使用某項(xiàng)開源技術(shù)實(shí)現(xiàn)某項(xiàng)業(yè)務(wù)需求，能夠辨別重復(fù)造輪子。
?精通設(shè)計(jì)模式，但又不泛用。
?把系統(tǒng)拆分成多個(gè)子系統(tǒng)或模塊。模塊之間盡量松耦合，使得原先串行的開發(fā)任務(wù)變得可以并行發(fā)展。
?能清楚系統(tǒng)的瓶頸在什么地方，不斷定位技術(shù)難度，開發(fā)進(jìn)度，性能，內(nèi)存等個(gè)方面的瓶頸。不斷調(diào)整骨干力量解決瓶頸，在風(fēng)險(xiǎn)爆發(fā)之前消除隱患。
?能做好前瞻性設(shè)計(jì)，預(yù)判到需求可能產(chǎn)生的變化。
架構(gòu)師團(tuán)隊(duì)內(nèi)做的事情
?溝通能力：各個(gè)方面都要了解，人人想法及規(guī)劃都要知道，了解產(chǎn)品思想，用了什么方法實(shí)現(xiàn)的
?組織能力：組織推動各種技術(shù)的改進(jìn)及功能的完善
?談判代表：左右兩難的時(shí)候的調(diào)解人
?設(shè)計(jì)模塊及業(yè)務(wù)：通過圖形化設(shè)計(jì)發(fā)現(xiàn)開發(fā)后才會發(fā)現(xiàn)的業(yè)務(wù)問題
?成本規(guī)劃：通過過往經(jīng)驗(yàn)評估成本及步伐
?愿望收集：不斷收集建議及愿望，一步步實(shí)現(xiàn)
?傳播布道：不斷參與行業(yè)交流，提高理論及技術(shù)知識科普分享團(tuán)隊(duì)
5、架構(gòu)師職場攻略
《大型網(wǎng)站技術(shù)架構(gòu)+核心原理與案例分析》總結(jié)：
架構(gòu)師需要處理好個(gè)人、團(tuán)隊(duì)、公司的利益。需要不斷的在工作中發(fā)現(xiàn)問題，解決問題，提升工作經(jīng)驗(yàn)，知識技能和核心競爭力。擴(kuò)大自身影響力，達(dá)成工作績效。
1、發(fā)現(xiàn)問題，尋找突破
即使在一流的技術(shù)團(tuán)隊(duì)，也有數(shù)不清的問題，團(tuán)隊(duì)人員已經(jīng)習(xí)慣這些積重難返的問題，而且解決問題投入產(chǎn)出比不大。例如：
1）數(shù)據(jù)庫線程池存在安全漏洞。
2）版本管理混亂。
作為一個(gè)新人，從局外旁觀者的視角看待，自然發(fā)現(xiàn)很多問題。如果新人急于表現(xiàn)自己，證明自己，往往是事與愿違，四處碰壁。因此新人要先融入團(tuán)隊(duì)，和團(tuán)隊(duì)共進(jìn)退，等熟悉情況，了解問題深淺，再尋找突破口，擇機(jī)而動。
2、提出問題，尋求支持
1)把“我的問題”表述成“我們的問題”：
人們都不喜歡問題，問題意味著麻煩。當(dāng)人們聽到你說，“我遇到一個(gè)問題的時(shí)候”，下意識的遠(yuǎn)離你的問題。如果需要他們的支持，就想辦法把你的問題變成他們的問題，是他遇到了問題，而你來幫忙解決。
既然你也是團(tuán)隊(duì)一員，問題表述為“我們的問題”。
1)給上司提封閉式問題，給下屬提開發(fā)式問題：
上司一般是做決策，因此給上司提問需要給出建設(shè)性的方案或者建議，然后希望得到他的支持，給上司提問：“你覺得A和B哪個(gè)方案更好？”
給下屬則相反，用開放式的問題啟發(fā)他去思考，尋找創(chuàng)新的解決方案。“元芳，這個(gè)問題你怎么看？”
3)指出問題而不是批評人:
如果遇到問題，不要責(zé)問他為什么出現(xiàn)問題，而是說問題的緊迫性和解決的優(yōu)先級。
4）用贊同的方式提出問題：
如果人們遇到：“你這里有問題”可能會本能自我保護(hù)而拒絕你的建議。
而如果這么說“我非常贊同你的方案，但是我有個(gè)小小的建議”。
3、解決問題，達(dá)成績效
在解決我的問題之前，先解決你的問題：
適當(dāng)?shù)奶颖軉栴}：比如我去開個(gè)會，回來再回答的你問題。
做好以下幾點(diǎn)，基本離你說的移動架構(gòu)師不遠(yuǎn)了
選，Java后臺還是客戶端開發(fā)？Java跟C、C++、PHP、Python等一直較勁，在當(dāng)前的現(xiàn)實(shí)中，也穩(wěn)坐編程語言榜首
面向?qū)ο蟮乃枷朐趹?yīng)用開發(fā)領(lǐng)域占主導(dǎo)，Java往往成為其代名詞
Java技術(shù)的人多，一直以來也有大公司資助，所以發(fā)展一直不錯(cuò)，進(jìn)入了良性循環(huán)
從企業(yè)的角度來說，找Java后臺的人相對比較容易
后臺被認(rèn)為是技術(shù)核心，而客戶端，被認(rèn)為技術(shù)含量不高
貪省事，讓Java后臺的架構(gòu)師順便來一下客戶端幾個(gè)人就好了，這可能是有些企業(yè)負(fù)責(zé)人自然而然的想法
客戶端技術(shù)和后臺技術(shù)的側(cè)重點(diǎn)完全不同，連編程語言都不同。Java能統(tǒng)一后臺開發(fā)；但是從目前的趨勢看，雖然客戶端也在強(qiáng)調(diào)統(tǒng)一，不過語言肯定不是Java
Java后臺的人跟用戶離得太遠(yuǎn)，與產(chǎn)品人員溝通，那真是雞同鴨講
如果產(chǎn)品真的是為了給用戶用，那么選客戶端背景的人員做移動架構(gòu)師要好一點(diǎn)。
客戶端是IOS，android，還是JS，根據(jù)企業(yè)喜好來選吧。根據(jù)本人經(jīng)驗(yàn)來說，當(dāng)然是IOS啦。智能手機(jī)這么熱，是誰帶起來的？從編程體驗(yàn)，程序美感來說，誰的最出色？只要干過移動開發(fā)的人，這幾個(gè)問題都是不言而喻的
作為移動架構(gòu)師，要重點(diǎn)注意的三個(gè)問題架構(gòu)師作為中層管理，直接領(lǐng)導(dǎo)一般是總監(jiān)了。技術(shù)加管理的綜合職位，在技術(shù)和管理上面的思路，跟總監(jiān)要保持一致。這方面是最重要的。如果這點(diǎn)做不好，趁早換地方，不讓對自己，對總監(jiān)，對企業(yè)都不好。有兩種情況需要注意：一種是跟總監(jiān)合作很好，但是總監(jiān)自己要換地方；這里，最好和總監(jiān)一起走，能遇到一個(gè)好領(lǐng)導(dǎo)不是一件容易的事。另一種是空降一個(gè)總監(jiān)過來，但是兩人想不到一塊去。這個(gè)時(shí)候就有點(diǎn)糾結(jié)，離開嘛，感覺舍不得，前面的付出要泡湯；留下嘛，感覺又很別扭。這種情況，需要加強(qiáng)溝通，調(diào)整自己，努力使合作更順利一點(diǎn)。否則，還是要走，畢竟胳膊擰不過大腿，估計(jì)大家都懂的。
跟周邊部門的合作要做好，特別是產(chǎn)品和測試，運(yùn)營也要注意一下。否則，將會導(dǎo)致很多稍大公司的部門墻。
跟具體的開發(fā)人員也要搞好關(guān)系。管理的本質(zhì)是自己不干活，但是團(tuán)隊(duì)的整體效率要更高。這點(diǎn)如果做不好，最直接的影響就是團(tuán)隊(duì)的績效不高，團(tuán)隊(duì)缺乏凝聚力，團(tuán)隊(duì)氣氛壓抑。這在很多公司都有發(fā)生。
如何與總監(jiān)CTO合作好？從思想上認(rèn)識到，兩者是利益完全一致者。總監(jiān)為架構(gòu)師拓展上升空間，而架構(gòu)師將總監(jiān)的規(guī)劃切實(shí)落地。
保證足夠的溝通，可以約定一個(gè)固定溝通機(jī)制，比如每2周一次。讓雙方在思想上保持同步和一致。
如果CTO也是客戶端技術(shù)出生，那么架構(gòu)師可以多探討一些技術(shù)經(jīng)驗(yàn)，將CTO的一些技術(shù)構(gòu)想落到實(shí)處，同時(shí)自己也能在技術(shù)上獲得提升。
如果CTO是Java后臺技術(shù)出生，那么CTO盡量授權(quán)，架構(gòu)師側(cè)重在設(shè)計(jì)思路，技術(shù)可行性，技術(shù)風(fēng)險(xiǎn)等較高的層面內(nèi)容。
架構(gòu)師應(yīng)該帶著方案和CTO溝通，講清楚AB方案的優(yōu)缺點(diǎn)。可以讓CTO來下決心，就算是架構(gòu)師下決策，也要獲得CTO的認(rèn)可。
如果意見出現(xiàn)分歧，最好的方式是先擱置，等條件成熟了，很可能意見會趨于一致。如果不能等，只要CTO的意見不是太離譜，還是按照CTO的意見執(zhí)行比較好。如果有十足把握，自己的方案更好，那么也要得到CTO的許可和諒解，否則千萬不要這么做。
如何與周邊部門合作好？產(chǎn)品經(jīng)理一般不懂技術(shù)。架構(gòu)師的作用就是幫他解決這個(gè)問題。在理解了需求之后，要進(jìn)行技術(shù)可行性分析。從技術(shù)的角度，提出改善意見。在不改變整體方案的前提下，修改設(shè)計(jì)，方便實(shí)現(xiàn)。這就需要產(chǎn)品經(jīng)理和架構(gòu)師的合作。
與后臺架構(gòu)師搞好合作，從后臺到實(shí)現(xiàn)，整條鏈路太長，一個(gè)人管不過來，需要兩人好好合作，共同把好技術(shù)關(guān)。
測試，要當(dāng)作開發(fā)的朋友看待，是自己人。可以考慮讓測試人員在“自測”階段介入，幫助開發(fā)人員提供測試案例。
運(yùn)營，關(guān)系稍微遠(yuǎn)了一點(diǎn)。關(guān)鍵點(diǎn)是及早介入，不然，到臨上線了，要加入一對的運(yùn)營需求，就可能影響產(chǎn)品投放時(shí)間了。
總之，和周邊部門，應(yīng)該以合作為主，及早溝通，將風(fēng)險(xiǎn)消滅在反生之前。
如何與團(tuán)隊(duì)成員溝通移動開發(fā)團(tuán)隊(duì)人數(shù)不多，但是角色和開發(fā)語音多。有IOS，android，還有JS和Java網(wǎng)關(guān)。
如果一個(gè)角色超過3個(gè)人，那么就應(yīng)該設(shè)置一個(gè)TeamLeader，進(jìn)行授權(quán)
對于自己擅長的技術(shù)，要分一兩個(gè)任務(wù)給自己，和兄弟們一起戰(zhàn)斗。中層人員需要在一線。
對于自己不擅長的技術(shù)，可以采用“結(jié)對編程”的方法，逐漸進(jìn)入角色。程序基本是相同的，還是能夠理解和參與討論的。
對于幾個(gè)Leader，要重點(diǎn)溝通，在大方向上保證思想一致，給他們空間，協(xié)助他們做出成績。
重點(diǎn)注意團(tuán)隊(duì)的正能量以及活躍的氣氛，人不是機(jī)器。和諧的氛圍比冰冷的制度和懲罰要好得多。
記好團(tuán)隊(duì)的功績和成果，提高團(tuán)隊(duì)成員集體榮譽(yù)感，將奮斗目標(biāo)引導(dǎo)到“自我實(shí)現(xiàn)”上來。
關(guān)于技術(shù)整體上是一專多能
以IOS技術(shù)為主，跟上蘋果的節(jié)奏，隨時(shí)學(xué)習(xí)新技術(shù)。深度技術(shù)按照需求來。
Object-C為主，畢竟在用，并且成熟度高。
Swift也要學(xué)，這是蘋果的未來。
Java要優(yōu)先學(xué)，android和后臺都要用到
JS也要學(xué)，最近H5勢頭比較猛
總之，架構(gòu)師是一個(gè)綜合素質(zhì)的體現(xiàn)，打鐵還需自身硬，能解決問題，或者能帶動周邊的人解決問題，才是關(guān)鍵，至于職位、位置，這只是一種職業(yè)稱謂，你牛逼了，還在乎別人稱你架構(gòu)師，還是其他的嗎，技術(shù)是硬實(shí)力，情商是軟實(shí)力，君子性非異也，善假于物也。自個(gè)體會。mvp模式
簡稱：MVP全稱：Model-View-Presenter；MVP是從經(jīng)典的模式MVC演變而來，它們的基本思想有相通的地方：Controller/Presenter負(fù)責(zé)邏輯的處理，Model提供數(shù)據(jù)，View負(fù)責(zé)顯示。作為一種新的模式，MVP與MVC有著一個(gè)重大的區(qū)別：在MVP中View并不直接使用Model，它們之間的通信是通過Presenter(MVC中的Controller)來進(jìn)行的，所有的交互都發(fā)生在Presenter內(nèi)部，而在MVC中View會直接從Model中讀取數(shù)據(jù)而不是通過Controller。
在MVC里，View是可以直接訪問Model的！從而，View里會包含Model信息，不可避免地還要包括一些業(yè)務(wù)邏輯。在MVC模型里，更關(guān)注的Model的改變，而同時(shí)有多個(gè)對Model的不同顯示，即View。所以，在MVC模型里，Model不依賴于View，但是View是依賴于Model的。不僅如此，因?yàn)橛幸恍I(yè)務(wù)邏輯在View里實(shí)現(xiàn)了，導(dǎo)致要更改View也是比較困難的，至少那些業(yè)務(wù)邏輯是無法重用的。
mvi架構(gòu)
你好，MVI（Model-View-Intent）是一種架構(gòu)模式，用于開發(fā)用戶界面。它是基于MVC（Model-View-Controller）和MVVM（Model-View-ViewModel）模式的演變而來。
MVI架構(gòu)的核心思想是將用戶界面的狀態(tài)表示為不可變的數(shù)據(jù)模型（Model），并通過Intent對象來表示用戶界面的交互意圖。用戶界面通過觀察Model的變化來更新自身的狀態(tài)，并將用戶的交互意圖通過Intent對象發(fā)送給業(yè)務(wù)邏輯層處理。
MVI架構(gòu)的主要組成部分包括：
1.Model：不可變的數(shù)據(jù)模型，用于表示用戶界面的狀態(tài)。
2.View：負(fù)責(zé)展示用戶界面，并通過觀察Model的變化來更新自身的狀態(tài)。
3.Intent：表示用戶界面的交互意圖，包括用戶的輸入和操作。
4.Reducer：負(fù)責(zé)根據(jù)接收到的Intent對象和當(dāng)前的Model狀態(tài)，計(jì)算出新的Model狀態(tài)。
5.Action：表示業(yè)務(wù)邏輯層的操作，用于響應(yīng)用戶的交互意圖并更新Model狀態(tài)。
MVI架構(gòu)的優(yōu)點(diǎn)包括：
1.易于測試：由于Model是不可變的，可以方便地編寫單元測試來驗(yàn)證Model的狀態(tài)變化。
2.擴(kuò)展性：通過將用戶界面的狀態(tài)和交互意圖明確地分離出來，可以方便地修改和擴(kuò)展用戶界面的功能。
3.可預(yù)測性：由于Model是不可變的，每次更新都是通過Reducer計(jì)算得出的，因此可以準(zhǔn)確地預(yù)測用戶界面的狀態(tài)變化。
需要注意的是，MVI架構(gòu)并不是適用于所有情況的通用解決方案，開發(fā)者需要根據(jù)具體的項(xiàng)目需求和團(tuán)隊(duì)情況來選擇適合的架構(gòu)模式。
OK，本文到此結(jié)束，希望對大家有所幫助。
