前后端分離意義
一、總結
1、低耦合，提高工作效率，每人明確分工
2、全棧工程師少
3、json：前后端交流通過json
4、前后端工程師不必要分的，必須了解E2E的整個過程
二、前后端分離優點
對於前后端分離的意義我們也可以看做是前端渲染的意義，我主要總結了下面四點：
1.徹底解放前端
前端不再需要向后台提供模板或是后台在前端html中嵌入后台代碼，如：
<!--服務器端渲染 -->
<select>
<option value=''>--請選擇所屬業務--</option>
{% for p in p_list %}
<option value="{{ p }}">{{ p }}</option>
{% endfor %}
</select>
這是前后端耦合的，可讀性差。
<!--前端渲染 -->
<template>
<select id="rander">
<option value=''>--請選擇所屬業務--</option>
<option v-for="list in lists" :value="list" v-text="list"></option>
</select>
</template>
<script>
export default {
data: {
return {
lists: ['選項一', '選項二', '選項三', '選項四']
}
}，
ready: function () {
this.$http({
url: '/demo/',
method: 'POST',
})
.then(function (response) {
this.lists = response.data.lists // 獲取服務器端數據並渲染
})
}
}
</script>
上面是前端渲染的一段代碼，前端通過AJAX調用后台接口，數據邏輯放在前端，由前端維護。
2.提高工作效率，分工更加明確
前后端分離的工作流程可以使前端只關注前端的事，后台只關心后台的活，兩者開發可以同時進行，在后台還沒有時間提供接口的時候，前端可以先將數據寫死或者調用本地的json文件即可，頁面的增加和路由的修改也不必再去麻煩后台，開發更加靈活。
3.局部性能提升
通過前端路由的配置，我們可以實現頁面的按需加載，無需一開始加載首頁便加載網站的所有的資源，服務器也不再需要解析前端頁面，在頁面交互及用戶體驗上有所提升。
4.降低維護成本
通過目前主流的前端MVC框架，我們可以非常快速的定位及發現問題的所在，客戶端的問題不再需要后台人員參與及調試，代碼重構及可維護性增強。
三、Web 前后端分離的意義大嗎？
問題：
前后端分離的意思是，前后端只通過 JSON 來交流，組件化、工程化不需要依賴后端去實現。 可以通過 Angular 或者 FIS-Pure 等，以實現組件化；通過 FIS 之類的工具去做工程化。 有哪些好處或弊端？現在的發展趨勢是否往這個方面發展？
解答：
沒必要分太細。我們需要 specialist，但是 senior 的人都應該了解整個 E2E (end-to-end) 過程的。
在 Facebook 我們不分前端和后端，只分 product 和 infrastructure。做 product 的通常都是 full stack，不需要對特定的技術非常精通，但要求學習能力和靈活性足夠好，不能只做自己 comfort zone 以內的事情，do whatever it takes to get your product shipped。通常聰明的應屆生都會先進入 product，因為他們學什么都很快，也不會說浪費了在某個領域的積累。infrastructure 擁有更多各個領域的 specialist，前端只是其中之一。infrastructure 的客戶就是 product，要做的事情就是讓 product 開發實際產品時覺得爽，就這么簡單。
至於真正 senior 的人，必須了解整個 E2E 過程。這有點像那個「在瀏覽器地址欄按下回車后都發生了什么」的答案，也就是掌握大局同時了解細節。因為具體的問題可疑扔給 junior 的人去解決，所以 senior 的存在價值就是在眾多問題當中尋找值得解決的問題。學過計算機體系結構的人都應該知道，性能優化只應該在瓶頸上做，因為做在非瓶頸上就是浪費資源。同理技術或產品的優化都應該是做在瓶頸上的，所以 senior 的人應該熟悉整套系統並且能夠有效找到當前的瓶頸。這時候就不存在前端或者后端的概念了，因為 specialist 在特定領域再精通，不了解整個 E2E 的過程就沒辦法再往上提升。
提到「聯調」，我想說我很久沒聽說過這個詞了，因為這個詞沒有對應的英語版本，美國公司的產品開發過程通常不包括聯調。product 要做什么，就自己學習對應的技術，學習公司內部的 infrastructure，然后調用公司內部的 API 就可以了。一個產品的邏輯，要分前端和后端兩個團隊的人實現，然后還要協調實現的結果，這我只在中國公司見過。當然這不僅僅要求公司 infrastructure 好，還要求有開放的文化。
我進 Facebook 之前只寫 JS，在 Facebook 要用 PHP 我隨便學學就開始寫，反正寫得不好 code review 時會有人指出。只要保持開放的學習心態，同一個錯誤不要一犯再犯，別人都樂意幫助你進步。現在我的 PHP/Hack 就僅僅是夠用的程度，但這不妨礙我工作。我的工作當然要用到別人的 infrastructure，偶爾用起來有點小不爽，我就會想要改動一下。管它是 Python、Java 還是 C++，反正我不爽就必須親自研究源代碼弄懂了自己該。原本的作者不一定有時間處理我的小需求，我就按照我的理解去改，改好提交 code review，別人都會幫忙看然后提點建議。
所謂聯調，無非就是有些事情你自己做不了非要以來於別人幫你做，然后別人就會成為阻塞你的環節。（通常都是前端依賴后端，很少有說后端因為前端沒完成就必須停下來等的。）這種做不了就停下來等的態度是不對的，不能說那是別人的問題就等別人解決。總之阻塞了產品發布的問題就是你的問題，無論需要你學習什么新技術，無論需要你編寫和調試什么不熟悉的代碼，do whatever it takes，just get the product launched。
那個木工和電工的比喻大致也是對的。在中國公司，這就是木工和電工的分離。在美國公司，有一幫人使用 3D 打印機、激光切割機、數控機床，外加 Arduino 或 Raspberry Pi，迅速把新一代電子產品的原型做出來；還有另外一幫人研究新一代的 3D 打印機，考慮如何讓上述 maker 更快地把頭腦中的產品原型變為現實。在中國公司，木工和電工整天吵架，木工說電工不把線路板面積確定下來他就沒辦法做木盒子，電工說他在電動機大小不確定的情況下線路板沒辦法定稿。