先後端分離意義

先後端分離意義

1、總結

一、低耦合，提升工做效率，每人明確分工

二、全棧工程師少

三、json：先後端交流經過json

四、先後端工程師沒必要要分的，必須瞭解E2E的整個過程

 

 

2、先後端分離優勢

對於先後端分離的意義咱們也能夠看作是前端渲染的意義，我主要總結了下面四點：

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框架，咱們能夠很是快速的定位及發現問題的所在，客戶端的問題再也不須要後臺人員參與及調試，代碼重構及可維護性加強。

 

3、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 的過程就沒辦法再往上提高。

 

@winter

提到「聯調」，我想說我好久沒據說過這個詞了，由於這個詞沒有對應的英語版本，美國公司的產品開發過程一般不包括聯調。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 更快地把頭腦中的產品原型變爲現實。在中國公司，木工和電工成天吵架，木工說電工不把線路板面積肯定下來他就沒辦法作木盒子，電工說他在電動機大小不肯定的狀況下線路板沒辦法定稿。