一、大前端
簡單來說，大前端就是所有前端的統稱，比如Android、iOS、web、Watch等，最接近用戶的那一層也就是UI層，然后將其統一起來，就是大前端。大前端最大的特點在於一次開發，同時適用於所有平台，開發者不用為一個APP需要做Android和iOS兩種模式而擔心。大前端是web統一的時代，利用web不僅能開發出網站，更可以開發手機端web應用和移動端應用程序。
由於node的出現，前端工程師不需要依賴於后端程序而直接運行，從而前后端分離起來。所以當開發一個新產品的時候服務只需要寫一次，但是面向用戶的產品可能有很多，例如網站、Android客戶端、iOS客戶端和微信小程序等。由於各個平台使用的技術棧都不一樣，代碼無法復用，非常浪費人力、物力。那么有沒有什么技術能夠解決這一痛點呢？大前端應運而生，其實大前端的主要核心就是跨平台技術，有了跨平台技術，各個平台的差異性就抹平了，開發者只需要一套技術棧就可以開發出適用於多個平台的客戶端。
目前的主流跨平台方案：Cordova/phoneGap、React Native、Weex、微信小程序、PWA和Flutter等，根據其原理性，可以分為四大類。
- H5+原生（Cordova、Ionic、微信小程序）
- JavaScript開發+原生渲染 （React Native、Weex、快應用）
- 自繪UI+原生(Flutter)
- 增強版Web App(PWA)
大前端不僅會成為移動開發與Web前端的發展趨勢，也將會是未來的顯示設備終端的開發技術趨勢。大前端將做更多的終端開發、工程化等工作，而不僅僅只是開發Web頁面。大前端工程師將能搞定所有端上的開發。與充滿爭議的全棧工程師相比，它更具可操作性。但同時對開發者而言，要會更多的技術棧，比如原生開發者要學習html、css、js等前端知識，前端開發人員也要學習Android或iOS的原生開發技術，然后了解一下常見的跨平台技術，只有這樣才能更好的融入到大前端的這個大家庭中。
二、前后端分離
前后端分離是指前端HTML頁面通過AJAX調用后端的RESTFUL API接口並使用JSON數據進行交互，例如通過nginx+tomcat的方式（也可以中間加一個nodejs）有效的進行解耦。
以前的Java Web項目大多數都是Java程序員又當爹又當媽，又搞前端，又搞后端。隨着時代的發展，漸漸的許多大中小公司開始把前后端的界限分的越來越明確，前端工程師只管前端的事情，后端工程師只管后端的事情。正所謂術業有專攻，一個人如果什么都會，那么他畢竟什么都不精。大中型公司需要專業人才，小公司需要全才，但是針對技術而言，前后端需要分離。
大家一致認同的前后端分離的例子就是SPA(Single-page application)，所有用到的展現數據都是后端通過異步接口(AJAX/JSONP)的方式提供的，前端只管展現。詳細點此處
三、敏捷模型
使用前后端分離符合敏捷開發模式，利用nodeJS層夾在前后端中間充當Controller，作為前后端之間的橋梁，增加靈活性。
從技術角度，使得項目從面向UI轉變為面向服務，適合於超大項目的同一套后端，多套前端的模式，后端只提供數據Model，viewModel由不同的端自行渲染，即后端只要提供滿足的數據需求就可以了，剩下的事情，就讓“大前端”內部自己解決。
從開發人員角度，使得前后端可同時並行開發，前后端完全解耦。產品經理提出PRD（Product Requirements Document產品需求文檔）、UI設計稿后直接前端開發（后端數據mock模擬），完成后直接遞交客戶預覽進行可行性分析，通過后交由DBA（或架構師）進行數據庫設計、后端研發人員（或架構師）進行后端設計等，中國人喜歡先設計數據庫，外國人恰恰相反，甚至使用hibernate自動完成數據庫的建表操作。前端先行往往使產品開發效率更高，且做到了敏捷開發中的測試先行（Mock數據最早做出），簡單講，就是將通常的“后端功能推動型”改為“大前端產品拉動型”，前端逆襲了，BFF(Backend for Frontends，為前端而存在的后端。
模式是測試專職維護BFF上的Mock數據，將設計的用例轉化為實際可用的Mock數據，開發測試用同一套標准，減少流程和溝通上的損耗。
“大前端”開發測試完成的內部版本是半成品，是缺乏后台實際支撐的。這個內部版本不能交給實際的用戶使用，但是內部的產品，開發，測試可以使用，用來體驗，查找bug等等。對於后端開發來說，也很便利，服務開發好之后，有現成的產品用來測試，能省很多事。向老板匯報，或者向客戶展示，也很方便，有實際可用的產品可以體驗，雖然數據是Mock的。這個跟看word文檔，ppt，原型設計，或者UI圖，感覺是完全兩樣的。修改成本小，一般來說，70%的工作在后台開發，30%的工作在“大前端”頁面。在內部試用的那一周中，發現的問題，或者需求變更，可以非常容易的在下一個版本迭代完成。這個時候，后台服務的開發還沒開始，或者剛剛開始，變更成本很小。
以前，想開發一個功能，首先考慮的是后端邏輯是怎么樣的。很多時候，要根據后端現有的邏輯，修改頁面的展示，交互的順序等等。是一種“后端功能推動的模式”。現在，產品和“大前端”一起，領先后端至少一個迭代以上。遇到需求變更強烈的點，或者爭論較大的點，可以考慮讓內部版本運行時間長一點，比如領先兩三個版本。等產品想清楚了，基本穩定了，后端再上。這樣，產品思考問題的重點，就從后端現有的功能轉移到客戶現實需求上來。“需求拉動型開發模式”，解放了產品的思維，更容易設計出符合客戶期望的產品。原來的模式是由后端推着前端走，現在的模式是產品和前端拉着后端走，思維模式是完全不一樣的。“大前端需求拉動型開發模式”：先有個可用的產品，搞清楚用戶喜歡什么，再接上后端實現。“后端功能推動型開發模式”：先做需求分析，評估現有后端功能，然后想辦法滿足客戶需求。
問題是：“客戶或者用戶知道自己想要什么嗎？需求分析能有效嗎？”。相對來講，如果有個可用的東西，真正用起來了，用戶更加容易知道自己想要什么。比如“這個顏色最好改一下”，“這里的按鈕礙眼，最好去掉”，“這里我想看更多的信息，最好能加上”。
前后端分離敏捷開發模式圖：
