知乎用戶：
沒必要分太細(xì)。我們需要 specialist，但是 senior 的人都應(yīng)該了解整個 E2E (end-to-end) 過程的。
在 Facebook 我們不分前端和后端，只分 product 和 infrastructure。做 product 的通常都是 full stack，不需要對特定的技術(shù)非常精通，但要求學(xué)習(xí)能力和靈活性足夠好，不能只做自己 comfort zone 以內(nèi)的事情，do whatever it takes to get your product shipped。通常聰明的應(yīng)屆生都會先進入 product，因為他們學(xué)什么都很快，也不會說浪費了在某個領(lǐng)域的積累。infrastructure 擁有更多各個領(lǐng)域的 specialist，前端只是其中之一。infrastructure 的客戶就是 product，要做的事情就是讓 product 開發(fā)實際產(chǎn)品時覺得爽，就這么簡單。
至于真正 senior 的人，必須了解整個 E2E 過程。這有點像那個「在瀏覽器地址欄按下回車后都發(fā)生了什么」的答案，也就是掌握大局同時了解細(xì)節(jié)。因為具體的問題可疑扔給 junior 的人去解決，所以 senior 的存在價值就是在眾多問題當(dāng)中尋找值得解決的問題。學(xué)過計算機體系結(jié)構(gòu)的人都應(yīng)該知道，性能優(yōu)化只應(yīng)該在瓶頸上做，因為做在非瓶頸上就是浪費資源。同理技術(shù)或產(chǎn)品的優(yōu)化都應(yīng)該是做在瓶頸上的，所以 senior 的人應(yīng)該熟悉整套系統(tǒng)并且能夠有效找到當(dāng)前的瓶頸。這時候就不存在前端或者后端的概念了，因為 specialist 在特定領(lǐng)域再精通，不了解整個 E2E 的過程就沒辦法再往上提升。
@winter

提到「聯(lián)調(diào)」，我想說我很久沒聽說過這個詞了，因為這個詞沒有對應(yīng)的英語版本，美國公司的產(chǎn)品開發(fā)過程通常不包括聯(lián)調(diào)。product 要做什么，就自己學(xué)習(xí)對應(yīng)的技術(shù)，學(xué)習(xí)公司內(nèi)部的 infrastructure，然后調(diào)用公司內(nèi)部的 API 就可以了。一個產(chǎn)品的邏輯，要分前端和后端兩個團隊的人實現(xiàn)，然后還要協(xié)調(diào)實現(xiàn)的結(jié)果，這我只在中國公司見過。當(dāng)然這不僅僅要求公司 infrastructure 好，還要求有開放的文化。
我進 Facebook 之前只寫 JS，在 Facebook 要用 PHP 我隨便學(xué)學(xué)就開始寫，反正寫得不好 code review 時會有人指出。只要保持開放的學(xué)習(xí)心態(tài)，同一個錯誤不要一犯再犯，別人都樂意幫助你進步?，F(xiàn)在我的 PHP/Hack 就僅僅是夠用的程度，但這不妨礙我工作。我的工作當(dāng)然要用到別人的 infrastructure，偶爾用起來有點小不爽，我就會想要改動一下。管它是 Python、Java 還是 C++，反正我不爽就必須親自研究源代碼弄懂了自己該。原本的作者不一定有時間處理我的小需求，我就按照我的理解去改，改好提交 code review，別人都會幫忙看然后提點建議。
所謂聯(lián)調(diào)，無非就是有些事情你自己做不了非要以來于別人幫你做，然后別人就會成為阻塞你的環(huán)節(jié)。（通常都是前端依賴后端，很少有說后端因為前端沒完成就必須停下來等的。）這種做不了就停下來等的態(tài)度是不對的，不能說那是別人的問題就等別人解決?？傊枞水a(chǎn)品發(fā)布的問題就是你的問題，無論需要你學(xué)習(xí)什么新技術(shù)，無論需要你編寫和調(diào)試什么不熟悉的代碼，do whatever it takes，just get the product launched。
@齊泰然

那個木工和電工的比喻大致也是對的。在中國公司，這就是木工和電工的分離。在美國公司，有一幫人使用 3D 打印機、激光切割機、數(shù)控機床，外加 Arduino 或 Raspberry Pi，迅速把新一代電子產(chǎn)品的原型做出來；還有另外一幫人研究新一代的 3D 打印機，考慮如何讓上述 maker 更快地把頭腦中的產(chǎn)品原型變?yōu)楝F(xiàn)實。在中國公司，木工和電工整天吵架，木工說電工不把線路板面積確定下來他就沒辦法做木盒子，電工說他在電動機大小不確定的情況下線路板沒辦法定稿。

知乎用戶：徐飛
意義很大，但是你的問題本身認(rèn)識有偏差。對于前后端分離，認(rèn)識上有個誤區(qū)，那就是很多人自稱：我們老早就分離了，全AJAX，使用Angular或者什么什么就可以了。這個說法是不合適的，打個比方，別人問的是“如何解決家禽把蛋生在水草邊的問題？”，但實際上人家養(yǎng)的是鴨子，答題的卻是養(yǎng)雞的，所以回答“不讓去水邊就行了”，這顯然不在點子上。這兩年業(yè)界說的前后端分離，是限于偏展示類的系統(tǒng)（用A代替），而不是應(yīng)用、管控類Web項目（用B代替），在B類項目里，前后端是天然分離的，對此，除了少部分后端開發(fā)人員，基本所有人的認(rèn)識都是一致的。上一段中這樣回答的人一般都是只做B類項目，在B類項目里，前后端分離是共識，不需要討論。那么，剩下的問題就是討論A類項目的前后端分離了。這個問題的核心在什么地方呢，在于模板的與數(shù)據(jù)結(jié)合的位置，以及，模板的控制權(quán)在誰手里。經(jīng)過這兩年的討論，基本上我們可以達成的共識就是：模板應(yīng)當(dāng)由前端人員去控制，主要原因有兩方面：- 性能優(yōu)化（尤其是外部資源的管理與發(fā)布，請求合并等等）- 協(xié)作的順暢性（已形成模板的界面片段的返工等問題）那么，模板到底應(yīng)該在什么地方跟數(shù)據(jù)結(jié)合？這個問題就比較折騰了，有部分人嘗試像B類項目那樣，使用js模板，然后在瀏覽器端執(zhí)行，這是存在一些問題的，比如說seo不友好，首屏性能不夠，尤其對于首頁DOM量很大的電商類網(wǎng)站，差距很明顯。所以我們還是得把主要的模板放在服務(wù)端來執(zhí)行。在這個過程中，阿里作了一些嘗試，那就是引入Node層，在這一層把模板與數(shù)據(jù)進行合成，然后瀏覽器拿到的就是生成好的HTML了，但也不是所有HTML都是這么生成好的，還是會有一些內(nèi)容等到了瀏覽器之后，再用js去加載和生成。所以這一定會是一個混合方案，同一個系統(tǒng)中存在兩種模板，一種在服務(wù)端執(zhí)行，一種在瀏覽器中執(zhí)行，互為補充。至于說這個方案中，是否中間層一定要是node，我覺得無所謂，只要是能正常做web項目的東西都可以，這個還是要看所在企業(yè)的技術(shù)積累方向，當(dāng)然node做這塊是有一些優(yōu)勢的，比如對前端人員的語言友好性，前后端模板的通用性等等，但這些都是細(xì)節(jié)，重點還是整體方案和流程。這時候回頭看你問題中的這句：> 前后端分離的意思是，前后端只通過 JSON 來交流，組件化、工程化不需要依賴后端去實現(xiàn)。我相信你這里對前后端的限定是以瀏覽器為準(zhǔn)的，但事實上，A類項目中，前后端的分界一定要延伸到服務(wù)器端的模板層，也就是在這一層里，把各種來源的數(shù)據(jù)整合到模板中，這個數(shù)據(jù)未必是JSON格式的，會存在有JSON，XML，特定的二進制等等。組件化這個話題就更復(fù)雜了，在剛才組織形式中，很難說出究竟什么才是組件。是某個商品的模板嗎？是數(shù)據(jù)嗎？是數(shù)據(jù)和模板的結(jié)合體嗎？沒法回答。在此，我說一句自己的看法：像電商這種項目的前端部分，基本不存在組件的概念，甚至不存在組件化的價值，因為這里面可復(fù)用的東西太少了，也不易提取，大多數(shù)東西都是不帶邏輯的界面模板。最近因為ReactJS的流行，帶來了一個Isomorphic的概念，這是一種很有意義的探索，但是否能解決這類問題，尚不得而知，根據(jù)我的理解，它對B類項目是較好的補充方案，但對A類項目暫時還缺乏可用性，因為A類項目中，運行期的DOM變更并不多，多是整片的改變，用這個方案去解決的話，有些牛刀殺雞的感覺。