① 你們知道大公司里是怎樣開發和部署前端代碼的嗎
開發時，把應用代碼分支拉到本地，這些分支可以只包含你要修改的應用，也可包含你要引用的類庫。在本地搭建webserver，修改host映射到本地。開發過程中要引用類庫地址時直接引用線上地址，會被webserver中轉到本地代碼上。 發布時直接發布到對應機器上就行，代碼里不用再修改線上路徑。項目是你要做一件事建的項目，跟代碼模塊沒關系。大公司前端代碼一般會發布帶cdn。看需要了，一般是php和java的， Nginxlighttpd apache都有用。當然是現有設計稿，至少你要先知道做什麼，再寫代碼吧。自己寫，如果某個函數忘記了或者樣式調整不好可以參考網上的資料，模塊當然自己寫。開發時和部署時，類庫的的引用和存放是看起來一致，但是背後其實不一樣。天貓由於業務對模塊的線上搭建的需求比較強烈，大部分場景下沒法走本地打包，都用的存放在CDN的模塊。
② 前端項目的開發流程
前端開發流程概述
前端開發流程可分為需求分析、開發階段、測試階段、維護階段，下面分別進行敘述。
2.1 需求分析
這個環節中，首先是和客戶進行交流，了解客戶的需求，然後分析項目的可行性，撰寫項目需求文檔。如果項目可行，則起討論具體方案，分模塊分步驟進行規劃，分析項目進度安排、所需成本，進行原型設計（包括頁面布局圖，頁面邏輯流程圖，說明文檔等。通過原型設計，可以讓項目組和客戶都可以對項目有一個直觀感受，同時可以低成本高效率的復現業務場景和各模塊流程）。
可以說需求分析階段是整個前端項目的基礎，基礎不牢，地動山搖。可以試想，如果和客戶溝通不順暢，有的方面客戶沒搞清楚是什麼效果，開發完成後就可能與客戶發生糾紛；如果可行性有問題，有的模塊很難實現或成本超出預算，就很難處理。
2.2 開發階段
這個環節是前端工程師主要參與的部分，按照需求分析階段的規劃按步驟完成任務。
根據產品需求分析文檔和原型圖進行UI設計，對產品的整體美術風格、交互設計、界面結構、操作流程等做出設計。負責項目中各種交互界面、圖標、LOGO、按鈕等相關元素的設計與製作。
根據UI設計進行規劃，提取界面中可以復用的模塊方便重復利用，分析界面是否有實現難度比較困難的地方，進行溝通和功能排期，按功能大小以及難度進行功能時間的評估，和後端溝通好排期時間，保證大家能夠更有效地開發合作，針對功能復雜的地方要先理清思路。
不要盲目開發前端搭建框架。根據設計圖進行前端界面開發，以及遇到的問題及時與產品、UI、後台人員溝通，保持大家信息一致，針對不清楚的地方也要及時溝通，以免做錯功能。
根據後端介面進行欄位填充，以及部分功能開發。針對缺少的欄位或者數據結構進行提出，及時與後端反應，盡量讓大家都能以最小的改動完成後續開發工作。前後端都要按照規范進行開發，針對不規范的地方要給與提出、指正，營造出規范的工作模式，以後維護成本和溝通成本更低以及開發效率更高。如果前端的設計進度遠遠超前後端的介面和數據結構設計，也不必等後端，可以自行開發nodejs伺服器配合postman等介面軟體進行開發。
前後端功能聯調、完成自測。檢查功能完成情況，看是否有遺漏，出現問題及時溝通解決。
2.3 測試階段
發布測試、修改bug、發布上線，自測完成後提交測試，測試根據提交的項目以及需求進行測試，提出bug給相關人員修改，開發人員周期性的配合修改bug，保證今天能夠修復昨天的bug。
發布dev環境，配合測試，修復bug以及需求優化
發布test環境，修復bug以及需求優化
發布it環境，修復bug以及需求優化
發布pre環境，修復bug以及需求優化
pre驗收之後，發布線上環境，產品進行驗收
2.4 維護階段
如果客戶驗收通過，項目就進入了維護階段，程序的維護包括程序上線後後續bug的修復和程序版本的更新。
3 個人經驗總結
3.1 文檔很重要
前端項目的文檔似乎已經作為前端工程化的標准流程之一了，文檔寫的好，可以便於同事快速了解你的代碼功能和需求，便於協作。可以想像，隨之項目復雜度增加，體量越來越龐大，開發團隊人數也越來越多。這種情況下，如果像變魔術一樣隱匿中間流程而直接得出結果，後果可想而知：項目復雜度越增加就越難以管理，開發效率低，合作混亂，結果甚至導致項目死亡。
好的文檔看起來就像一個產品說明書，但作用卻遠遠超過了說明書，不僅僅告訴你如何使用，還應該告訴你項目的設計思路，用了哪些組件，哪些部分不完善，將來有什麼規劃等等。這是一份比較好的說明文檔。
3.2 與客戶及時溝通很重要
3.3 扎實的基本功很重要
盡管當下框架、函數庫、工具包等更新迭代非常快，前端工程師有很多新的知識要學，但原生JS、HTML和CSS依然是重要的基本功，在學習前沿工具的同時不能放棄基本功的訓練。
③ 怎麼開發和部署前端代碼
先部署頁面，再部署資源：在二者部署的時間間隔內，如果有用戶訪問頁面，就會在新的頁面結構中載入舊的資源，並且把這個舊版本的資源當做新版本緩存起來，其結果就是：用戶訪問到了一個樣式錯亂的頁面，除非手動刷新，否則在資源緩存過期之前，頁面會一直執行錯誤。
先部署資源，再部署頁面：在部署時間間隔之內，有舊版本資源本地緩存的用戶訪問網站，由於請求的頁面是舊版本的，資源引用沒有改變，瀏覽器將直接使用本地緩存，這種情況下頁面展現正常；但沒有本地緩存或者緩存過期的用戶訪問網站，就會出現舊版本頁面載入新版本資源的情況，導致頁面執行錯誤，但當頁面完成部署，這部分用戶再次訪問頁面又會恢復正常了。
- 總之，前端性能優化絕逼是一個工程問題！
好的，上面一坨分析想說的就是：先部署誰都不成！都會導致部署過程中發生頁面錯亂的問題。所以，訪問量不大的項目，可以讓研發同學苦逼一把，等到半夜偷偷上線，先上靜態資源，再部署頁面，看起來問題少一些。
但是，大公司超變態，沒有這樣的「絕對低峰期」，只有「相對低峰期」。So，為了穩定的服務，還得繼續追求極致啊！
這個奇葩問題，起源於資源的 覆蓋式發布，用 待發布資源 覆蓋 已發布資源，就有這種問題。解決它也好辦，就是實現 非覆蓋式發布。
<img src="https://pic4.mg.com/50/_hd.jpg" data-rawwidth="631" data-rawheight="456" class="origin_image zh-lightbox-thumb" width="631" data-original="https://pic4.mg.com/_r.jpg">
好了，目前我們快速的學習了一下前端工程中關於靜態資源緩存要面臨的優化和部署問題，新的問題又來了：這™讓工程師怎麼寫碼啊！！！
要解釋優化與工程的結合處理思路，又會扯出一堆有關模塊化開發、資源載入、請求合並、前端框架等等的工程問題，以上只是開了個頭，解決方案才是精髓，但要說的太多太多，有空再慢慢展開吧。或者大家可以去我的blog看其中的一些拆解：fouber/blog · GitHub
以上不是我YY的，可以觀察 網路 或者 facebook 的頁面以及靜態資源源代碼，查看它們的資源引用路徑處理，以及網路請中靜態資源的緩存控制部分。再次贊嘆facebook的前端工程建設水平，跪舔了。
建議前端工程師多多關注前端工程領域，也許有人會覺得自己的產品很小，不用這么變態，但很有可能說不定某天你就需要做出這樣的改變了。而且，如果我們能把事情做得更極致，為什麼不去做呢？
另外，也不要覺得這些是運維或者後端工程師要解決的問題。如果由其他角色來解決，大家總是把自己不關心的問題丟給別人，那麼前端工程師的開發過程將受到極大的限制，這種情況甚至在某些大公司都不少見！
④ 大公司里怎樣開發和部署前端代碼
雖然美團不是大公司，但在這里寫一下我們的情況，僅供參考。開發時的和部署時類庫的引用和存放是一致還是不同?開發環境和部署環境的類庫代碼都是相同的，但物理位置不同。部署環境的類庫在CDN上，開發環境的類庫在開發伺服器上。模塊放在項目中還是放在 CDN 之類伺服器?模塊放在項目中，部署時都在CDN上。渲染網頁用 Nginx 還是其他動態語言的 Web 伺服器?前面用ngnix做負載均衡，後面用apache做web伺服器。製作網頁的流程, 是現有設計師的稿, 還是先看模塊?先有設計師的稿再寫模塊，但很多時候並不需要設計師，因為架子已經搭好了，界面規范和基礎元素都有，一般的界面前端工程師都能搞得定。會選擇用自己寫的模塊還是從社區尋找模塊?基礎框架用的YUI3，大部分二次開發的底層模塊，還有和業務緊密結合的UI模塊都是自己寫的。當然也會用社區寫的模塊，比如上傳組件、highcharts、Ace等。如果說怎麼選擇模塊的話，那就是具體情況具體分析了，總體原則有兩個：能不自己寫，就不自己寫；選擇最符合需求的，一般來說，要麼選最好的，要麼選最快出結果的。
⑤ webpack打包後的代碼，如何部署到伺服器上
本文章前端代碼是基於vue+webpack開發的
Nginx是一款輕量級的Web 伺服器/反向代理伺服器
首先，webpack配置如下
在開發過程中，我們是通過npm run dev在開發環境中運行代碼
如果要部署到生產環境中，可以運行npm run build進行上線打包
打包完成後，會發現項目中多了dist這個文件夾
執行結果和webpack的配置文件一致。
代碼被webpack打包完成後下一步就是部署到伺服器上，此文僅適合於前端代碼是部署在windows操作系統的nginx服務中。
這里假設：
Windows操作系統：windows server 2008 64位
Nginx服務：nginx-1.12.2 64位
1.下載nginx-1.12.2 64位解壓，假設nginx-1.12.2放在D:nginx-1.12.2目錄中，nginx目錄結構。如圖下
2、前端代碼放在D:nginx-1.12.2html目錄中，dist目錄就是剛剛前端打包完的代碼。如圖下
3、在D:nginx-1.12.2conf目錄中，有個nginx.conf配置文件，進行編輯這個文件
4、假設前端的埠號為8082，如果埠號被佔用，請修改為其它埠號。後台服務訪問地址http://192.168.121.**:8080,
5、打開cmd控制台，進入目錄D:nginx-1.12.2中，用start nginx命令啟動服務，然後用tasklist /fi "imagename eq nginx.exe"，查看nginx服務是否啟動。
4、如果改變配置文件時，需要用nginx -s reload 命令重啟nginx工作進程。
5、關閉服務
nginx -s stop
nginx -s quit 安全關閉
taskkill /F /IM nginx.exe > nul 關閉所有nginx服務
⑥ 如何將前端和後端結合
前端和後端結合的過程需要通過數扮介面來進行數據交互。
1.確定介面：前後端開發人員需要協商確定介面，包括介面的名稱、參數、返回值等。在確定介面時，需要考慮數據的格式和傳遞方式，如JSON、XML等。
2.編寫後端代碼：後端開發人員需要根據介面的要求編寫代碼，實現介面的功能。後端代碼需要根游橡據介面的參數進行相應的處理，並將處理結果返回給前端。
3.編寫前端代碼：前端開發人員需要根據介面的返回值進行相應的處理，將數據顯示在前端頁面上。前端代碼需要通過Ajax、fetch等技術調用後端介面，並將返回的數據進行解析和處理。
4.測試介面：前後端開發人員需要對介面進行測試，確保數據的傳遞和處理沒有薯磨灶問題。在測試過程中，需要對介面的各種情況進行測試，包括正常情況、異常情況等。
5.部署上線：當介面測試通過後，可以將前端和後端代碼部署到伺服器上線。在部署上線時，需要確保伺服器環境的配置和安全性，以及代碼的穩定性和性能。
⑦ 如何高效部署前端代碼，如css，js
1.利用瀏覽器的304緩存，但是304叫協商緩存，還是需要與伺服器通信一次
2.強制使用瀏覽器使用本地緩存（cache-control/expires），但是問題來了，不讓瀏覽器發資源請求，資源怎麼更新。
3.使用版本號，類似於a.css?v=1.0，b.css?v=1.0，做了更改的時候都變成a.css?v=2.0，b.css?v=2.0，有時候a.css改變了，b.css沒有改變，不是多此一舉嗎？
4.使用數據摘要演算法，類似於a.css?v=0abc23，b.css?v=65ao1j，如果a.css做了更改的話，a.css=v=1asd2j，b.css還是b.css?v=65ao1j。
5.很多企業，現在都靜態文件cdn部署了，類似於http://static.cdn.com/css/a.css?v=0abc23，與頁面分開部署了，
a.如果先部署頁面，再部署資源：在二者部署的時間間隔內，如果有用戶訪問頁面，就會在新的頁面結構中載入舊的資源，並且把這個舊版本的資源當做新版本緩存起來，其結果就是：用戶訪問到了一個樣式錯亂的頁面，除非手動刷新，否則在資源緩存過期之前，頁面會一直執行錯誤。
b.如果先部署資源，再部署頁面：
在部署時間間隔之內，有舊版本資源本地緩存的用戶訪問網站，由於請求的頁面是舊版本的，資源引用沒有改變，瀏覽器將直接使用本地緩存，這種情況下頁面展現正常；但沒有本地緩存或者緩存過期的用戶訪問網站，就會出現舊版本頁面載入新版本資源的情況，導致頁面執行錯誤，但當頁面完成部署，這部分用戶再次訪問頁面又會恢復正常了。
解決方法：改變命名方式，改成a_0abc23.css，上線的時候先部署靜態資源，再部署頁面。