標籤：

大公司里怎樣開發和部署前端代碼？

11-26

主要有以下問題：

  • 開發時的和部署時類庫的引用和存放是一致還是不同？
  • 模塊放在項目中還是放在 CDN 之類伺服器？
  • 渲染網頁用 Nginx 還是其他動態語言的 Web 伺服器？
  • 製作網頁的流程，是先有設計師的稿，還是先看模塊？
  • 會選擇用自己寫的模塊還是從社區尋找模塊？

沒人邀請，看到這個問題不錯，路過怒答。（多圖預警）

前百度工程師，曾負責百度 前端集成解決方案 的核心設計與開發工作。我現在稱這個領域為【前端工程】。沒錯，這是我最愛嘮叨的問題域。

這是一個非常有趣的 非主流前端領域，這個領域要探索的是如何用工程手段解決前端開發和部署優化的綜合問題，入行到現在一直在學習和實踐中。

在我的印象中，facebook是這個領域的鼻祖，有興趣、有梯子的同學可以去看看facebook的頁面源代碼，體會一下什麼叫工程化。

接下來，我想從原理展開講述，多圖，較長，希望能有耐心看完。

---------------------------- 我是一條分割線 ----------------------------

讓我們返璞歸真，從原始的前端開發講起。上圖是一個「可愛」的index.html頁面和它的樣式文件a.css，用文本編輯器寫代碼，無需編譯，本地預覽，確認OK，丟到伺服器，等待用戶訪問。前端就是這麼簡單，好好玩啊，門檻好低啊，分分鐘學會有木有！

然後我們訪問頁面，看到效果，再查看一下網路請求，200！不錯，太?完美了！那麼，研發完成。。。。了么？

等等，這還沒完呢！對於大公司來說，那些變態的訪問量和性能指標，將會讓前端一點也不「好玩」。

看看那個a.css的請求吧，如果每次用戶訪問頁面都要載入，是不是很影響性能，很浪費帶寬啊，我們希望最好這樣：

利用304，讓瀏覽器使用本地緩存。但，這樣也就夠了嗎？不成！304叫協商緩存，這玩意還是要和伺服器通信一次，我們的優化級別是變態級，所以必須徹底滅掉這個請求，變成這樣：

強制瀏覽器使用本地緩存（cache-control/expires），不要和伺服器通信。好了，請求方面的優化已經達到變態級別，那問題來了：你都不讓瀏覽器發資源請求了，這緩存咋更新？

很好，相信有人想到了辦法：通過更新頁面中引用的資源路徑，讓瀏覽器主動放棄緩存，載入新資源。好像這樣：

下次上線，把鏈接地址改成新的版本，就更新資源了不是。OK，問題解決了么？！當然沒有！大公司的變態又來了，思考這種情況：

頁面引用了3個css，而某次上線只改了其中的a.css，如果所有鏈接都更新版本，就會導致b.css，c.css的緩存也失效，那豈不是又有浪費了？！

重新開啟變態模式，我們不難發現，要解決這種問題，必須讓url的修改與文件內容關聯，也就是說，只有文件內容變化，才會導致相應url的變更，從而實現文件級別的精確緩存控制。

什麼東西與文件內容相關呢？我們會很自然的聯想到利用 數據摘要要演算法 對文件求摘要信息，摘要信息與文件內容一一對應，就有了一種可以精確到單個文件粒度的緩存控制依據了。好了，我們把url改成帶摘要信息的：

這回再有文件修改，就只更新那個文件對應的url了，想到這裡貌似很完美了。你覺得這就夠了么？大公司告訴你：圖樣圖森破！

唉~~~~，讓我喘口氣

現代互聯網企業，為了進一步提升網站性能，會把靜態資源和動態網頁分集群部署，靜態資源會被部署到CDN節點上，網頁中引用的資源也會變成對應的部署路徑：

好了，當我要更新靜態資源的時候，同時也會更新html中的引用吧，就好像這樣：

這次發布，同時改了頁面結構和樣式，也更新了靜態資源對應的url地址，現在要發布代碼上線，親愛的前端研發同學，你來告訴我，咱們是先上線頁面，還是先上線靜態資源？

  1. 先部署頁面，再部署資源：在二者部署的時間間隔內，如果有用戶訪問頁面，就會在新的頁面結構中載入舊的資源，並且把這箇舊版本的資源當做新版本緩存起來，其結果就是：用戶訪問到了一個樣式錯亂的頁面，除非手動刷新，否則在資源緩存過期之前，頁面會一直執行錯誤。
  2. 先部署資源，再部署頁面：在部署時間間隔之內，有舊版本資源本地緩存的用戶訪問網站，由於請求的頁面是舊版本的，資源引用沒有改變，瀏覽器將直接使用本地緩存，這種情況下頁面展現正常；但沒有本地緩存或者緩存過期的用戶訪問網站，就會出現舊版本頁面載入新版本資源的情況，導致頁面執行錯誤，但當頁面完成部署，這部分用戶再次訪問頁面又會恢復正常了。

好的，上面一坨分析想說的就是：先部署誰都不成！都會導致部署過程中發生頁面錯亂的問題。所以，訪問量不大的項目，可以讓研發同學苦逼一把，等到半夜偷偷上線，先上靜態資源，再部署頁面，看起來問題少一些。

但是，大公司超變態，沒有這樣的「絕對低峰期」，只有「相對低峰期」。So，為了穩定的服務，還得繼續追求極致啊！

這個奇葩問題，起源於資源的 覆蓋式發布，用 待發布資源 覆蓋 已發布資源，就有這種問題。解決它也好辦，就是實現 非覆蓋式發布。

看上圖，用文件的摘要信息來對資源文件進行重命名，把摘要信息放到資源文件發布路徑中，這樣，內容有修改的資源就變成了一個新的文件發布到線上，不會覆蓋已有的資源文件。上線過程中，先全量部署靜態資源，再灰度部署頁面，整個問題就比較完美的解決了。

所以，大公司的靜態資源優化方案，基本上要實現這麼幾個東西：

  1. 配置超長時間的本地緩存 —— 節省帶寬，提高性能
  2. 採用內容摘要作為緩存更新依據 —— 精確的緩存控制
  3. 靜態資源CDN部署 —— 優化網路請求
  4. 更資源發布路徑實現非覆蓋式發布 —— 平滑升級

全套做下來，就是相對比較完整的靜態資源緩存控制方案了，而且，還要注意的是，靜態資源的緩存控制要求在前端所有靜態資源載入的位置都要做這樣的處理。是的，所有！什麼js、css自不必說，還要包括js、css文件中引用的資源路徑，由於涉及到摘要信息，引用資源的摘要信息也會引起引用文件本身的內容改變，從而形成級聯的摘要變化，大概示意圖就是：

好了，目前我們快速的學習了一下前端工程中關於靜態資源緩存要面臨的優化和部署問題，新的問題又來了：這?讓工程師怎麼寫碼啊！！！

要解釋優化與工程的結合處理思路，又會扯出一堆有關模塊化開發、資源載入、請求合併、前端框架等等的工程問題，以上只是開了個頭，解決方案才是精髓，但要說的太多太多，有空再慢慢展開吧。或者大家可以去我的blog看其中的一些拆解：fouber/blog · GitHub

總之，前端性能優化絕逼是一個工程問題！

以上不是我YY的，可以觀察 百度 或者 facebook 的頁面以及靜態資源源代碼，查看它們的資源引用路徑處理，以及網路請中靜態資源的緩存控制部分。再次讚歎facebook的前端工程建設水平，跪舔了。

建議前端工程師多多關注前端工程領域，也許有人會覺得自己的產品很小，不用這麼變態，但很有可能說不定某天你就需要做出這樣的改變了。而且，如果我們能把事情做得更極致，為什麼不去做呢？

另外，也不要覺得這些是運維或者後端工程師要解決的問題。如果由其他角色來解決，大家總是把自己不關心的問題丟給別人，那麼前端工程師的開發過程將受到極大的限制，這種情況甚至在某些大公司都不少見！

媽媽，我再也不玩前端了。。。。5555

========================[ 10.29更新 ]========================
這裡更新一下：

在評論中， @陳鋼@fleuria @林翔 提到了rails，剛剛去看了一下，確實是完成了以上所說的優化細節，對整個靜態資源的管理上的思考於本答案描述的一致。很遺憾我直到今天（2014-10-29）才了解到rails中的assets pipeline。這裡向以上3位同學道歉，原諒我的無知。

不過整篇回答沒有講解到具體的解決方案實現思路，只是介紹了前端在工程化方向的思考，答案本身是可用的，了解rails的人也可以把此答案當做是對rails中assets pipeline設計原理的分析。

rails通過把靜態資源變成erb模板文件，然後加入&<%= asset_path "image.png" %&>，上線前預編譯完成處理，不得不承認，fis的實現思路跟這個幾乎完全一樣，但我們當初確實不知道有rails的這套方案存在。

相關資料：英文版：The Asset Pipeline，中文版：Asset Pipeline
========================[ 10.31更新 ]========================
用 F.I.S 包裝了一個小工具，完整實現整個回答所說的最佳部署方案，並提供了源碼對照，可以感受一下項目源碼和部署代碼的對照。
源碼項目：fouber/static-resource-digest-project · GitHub
部署項目：fouber/static-resource-digest-project-release · GitHub
部署項目可以理解為線上發布後的結果，可以在部署項目里查看所有資源引用的md5化處理。

這個示例也可以用於和assets pipeline做比較。fis沒有assets的目錄規範約束，而且可以以獨立工具的方式組合各種前端開發語言（coffee、less、sass/scss、stylus、markdown、jade、ejs、handlebars等等你能想到的），並與其他後端開發語言結合。

assets pipeline的設計思想值得獨立成工具用於前端工程，fis就當做這樣的一個選擇吧。

目前 負責天貓模塊方案，大概回答下答主的問題。

  • 開發時的和部署時類庫的引用和存放是一致還是不同？

開發時和部署時，類庫的的引用和存放是看起來一致，但是背後其實不一樣。
天貓由於業務對模塊的線上搭建的需求比較強烈，大部分場景下沒法走本地打包，都用的存放在CDN的模塊。
本地開發的時候，文件host會指到本地，引用的模塊會從服務端拉取到本地（提高下次讀取的速度，這部分工作由本地的開發server完成），但是引用的方式是和線上一樣的。
本地開發時：

const overly = require("mui/overlay/index");

打包到線上

define("xxx", ["mui/overlay/index"], function(require){
var overly = require("mui/overlay/index");
})

請求模塊的url都是

http://g.alicdn.com/mui/overlay/4.0.0/index.js

  • 模塊放在項目中還是放在 CDN 之類伺服器？

內部依賴模塊放到項目中，公共模塊放CDN。
其實這麼描述有些抽象，但是也給了開發者足夠的自由。

  • 渲染網頁用 Nginx 還是其他動態語言的 Web 伺服器？

現在貌似這個問題沒什麼好討論的。
本地開發環境最好和服務端架構保持一致，現在服務端是Node，本地肯定也是Node。

  • 製作網頁的流程，是先有設計師的稿，還是先看模塊？

最理想的情況下，設計師應當花比較多的時間和前端一起維護一套模塊UI規範，然後設計師設計頁面的時候，也必須根據這個模塊UI規範來。
所有有個性化的調整，都應當考慮是不是應當補充回到UI規範中，保證整體視覺的一致性體驗。
當然，總有不合適和一些特殊場景下的視覺稿，就單獨處理好了。
所以應該是在設計師的稿子上體現模塊，而不是到前端才來看哪些模塊和視覺稿能匹配上。

  • 會選擇用自己寫的模塊還是從社區尋找模塊？

對於模塊，社區方案一定是非常棒的，所以在沒有現成的情況下，非常建議引入社區模塊，並在引入之後維護起來。
後面一點維護起來非常重要，引入一個模塊很簡單，維護起來就不是了，或許你會發現這個社區模塊有一些bug，或者是部分不滿足需求，去修改並改善這個模塊比重寫一個模塊要求更高，難度更大（你要理解其他開發者為什麼要這麼寫代碼）。完成之後提MR到社區也是對社區的貢獻。
自己寫的情況也有，但更多還是要考慮自己寫的意義在哪裡，一般在社區模塊落後於你對模塊的思考和規劃時，自己寫是一個好的選擇。

最後有招聘，有意者留意一下，謝謝~~

雖然我們不是大公司，但是我也來佔個位，東西太多慢慢寫。

1.開發環境的被動式資源服務。

我們的開發環境是一個叫做ads的服務，在github上找得到，沒說開源，但是都是public的項目。
這個環境跑在每個人的機器和測試環境的機器和線上的機器上。
支撐了大搜車所有環境的靜態服務。
其實它做的工作比較簡單，無非是一個靜態文件伺服器+一些實時處理。
原理也比較簡單，被動式處理，當你訪問一個文件的時候，就會去尋找這個文件的需要經過的處理中間件，讓文件以管道的形式通過這些中間件，最後返回一個處理過的文件內容。
例如jade和less，我們項目里沒有編譯和打包的概念，你就寫就行了，然後任何環境里訪問index.css其實都返回的是index.less的編譯結果，打包的過程和配置，都不需要關心。包括jade，less，js壓縮，requrejs打包合併都是用這樣的方式開發，你寫的是這樣，你看到的是另一樣，簡單粗暴，每個人只需要關心自己需要關心的事情，而不是項目的配置和打包之類的事情。

這個環境也無需配置，直接github clone下來，node app.js跑一下就再也不用管了。

2.如何開發和測試？

測試環境。通過切換host，我們有一個測試的域名，叫做http://f2e.souche.com。默認這個域名是指向一台前端單獨的測試伺服器的，通過nginx，轉發到一個ads的服務上。然後這個服務的背後是我們的前端資源文件，這個項目里還跑了一個定時腳本，一分鐘pull一次從github更新代碼。
所以http://f2e.souche.com直接訪問，訪問的就是測試環境，這個環境的代碼永遠是最新的，它會定時從github拉取最新的代碼。
這個環境主要用來支撐測試和開發訪問網站的測試環境時候訪問到的前端資源的服務支撐。

本地開發。通過切換host，把http://f2e.souche.com切換到127.0.0.1，然後就把服務指向了本地的ads服務，本地的ads訪問的是本地的資源項目，所以任何修改直接會生效。

3.動態路徑和時間戳自動更新

在java程序中，我們實現了兩個跟前端資源有關的機制。
動態路徑。我們的java程序會根據環境的不同判斷來引用不同環境的資源文件，例如測試和線上，自動引用不同路徑的資源。

時間戳自動更新。我們前端維護了一個resource.properties，這個文件是一個時間戳的kv。每次發布一個文件，就讓他對應的時間戳+1。然後java里會定時去遠程讀取這個文件，如果讀取成功，就把這個kv解析到內存覆蓋之前的時間戳map，然後每次渲染模板的時候，會把對應的時間戳通過方法注入到模板中，模板中所有的資源引用都會根據這個時間戳配置動態改變資源的時間戳。

4.線上CDN和發布

線上我們也有一台前端自己的伺服器，專門用來跑ads支撐線上服務。
每個請求進來（http://assets.souche.com是指向cdn的），會先通過阿里的cdn服務，然後如果cdn上有緩存副本，就會直接返回，如果沒有，則會去請求一台（http://f2e-assets.souche.com不經過cdn)這台是前端的線上服務，這台伺服器上的ads跟開發和測試環境的ads一模一樣，會動態處理，jade,less,js壓縮合併，requirejs打包，圖片自動優化。

發布，就簡單了，就是簡單的文件拷貝，我們有個專門的發布服務，也是nodejs寫的，會記錄每次發布的時間內容，然後copy文件過去，並且更新上面提到的resource.properties。這樣就能自動更新時間戳了。

5.combo等個性化服務。

因為採用上述的架構，所以我們可以靈活定製我們的靜態服務，因為我們中間有一層cdn，後面架設了一個動態服務，這個動態服務是無所不能的。

例如combo，這樣的url：http://assets.souche.com/assets/js/$$lib/jquery-1.7.1.min.js,lib/require.js,lib/jquery.flexslider-min.js

實現起來很簡單，後台收到請求的時候解析下路徑，把文件動態壓縮一下，然後合併返回給前端即可，沒啥好說的，但是就是夠方便。

6.被動式服務的性能。

因為ads是被動式服務，它的好處是傻瓜化，壞處是有時候可能會有性能問題，還好我們可以適當規避。
例如常用的服務：jade,less,js壓縮合併，requirejs打包，圖片自動優化

其中jade,less的實時編譯是非常快的，基本感覺不出來，所以這兩個可以忽略。
js合併壓縮，requirejs打包，圖片優化是比較慢的。
所以在本地開發和測試環境的時候，這幾個服務是關閉掉的。也就是我們的js只有在線上才是壓縮的，本地都是不壓縮的，當然訪問路徑都是一樣一樣的。
requirejs也不打包，本地和測試都採用非同步載入，到了線上才會使用打包出來的文件。

所有的所有，都沒有中間文件，所以在我們的前端項目里，看不到css文件，看不到壓縮後的js文件，看不到jade編譯出來的html，看不到requirejs打包的文件，也看不到優化後的圖片文件。因為所有的一切都是被動式。

而在線上，所有的性能問題都不是問題了，因為有cdn，所以服務不會一直被請求，請求一次之後就被cdn緩存，再慢的服務，也是沒有問題的。

7.後言

大概先說這些，一直以來從來沒跟別人講過公司的前端工程環境，今天廢話了一通。

最近正在搞一個比較特立獨行的前後端分離，思路跟其他公司稍微不同，前後端分離最重要的不是技術實現，而是因為涉及到了整個公司的開發架構，需要為前端，開發，測試，都定製一套傻瓜化的開發環境和解決方案，重新制定開發流程，又涉及到產品運營等等，這些的推動才是最複雜的，中間要解決很多問題，不能說為了技術而技術，要為每個職責解決問題才能夠推動整個項目。


另外，公司招聘前端開發，杭州大搜車，線上二手車O2O服務平台，技術什麼的就不說了（java,ruby,nodejs,golang我們都玩），氛圍也懶得誇了（燒烤喝酒party妹子應有盡有），有興趣的直接聯繫我吧，郵箱：sunxinyu@souche.com

每一家大公司都不一樣，你只能尋找適合自己的流程。

一般來說，大公司面臨的問題就是複雜度。這就如同說，簡單的問題，你用彙編寫也肯定寫得出來，但更複雜的問題就需要用高級語言來抽象，否則其複雜度無法管理。此外，編譯不僅僅是能執行就可以，還要考慮目標平台的執行效率。

對於大公司來說，用 CDN 是必然的，只是如何儘可能多地把靜態資源放到 CDN 上去。對於圖片這種數量有限的資源，一般新增多少都會放到 CDN 而不在乎成本。至於 JavaScript 這類打包方案有無窮組合的資源，則需要特別的優化了。最笨的辦法，當然是人手劃定幾個基本的打包方案，然後在 CDN 上部署。如果組合數有限，把所有打包方案都緩存到 CDN 也是可以的（沒有人請求的打包方案就不生成了）。更先進的辦法是，統計實際請求的打包方案，然後自動生成優化的打包方案，並且緩存在 CDN 上。

考慮到各家大公司採用的語言不一樣，用什麼伺服器也是不確定的。甚至在一家公司內不同語言的系統用的伺服器就不一樣。同理，不同團隊的合作方式不一樣，導致了設計到實現的流程也不一樣。就算在同一家公司內，也有可能同時存在最保守的團隊和最敏捷的團隊，一邊必須設計定稿了才開始寫第一行代碼，另一邊想到什麼寫什麼覺得不好看再找設計師調整。

大公司一般都不會非常多的依賴於開源項目，而是自己做自己的項目然後開源。一方面這是 Not Invented Here 的問題；另一方面，確實通用的開源項目無法滿足某一家公司非常特定的某些需求，所以就算 idea 是很好的，大公司也會把 idea 搬過來再結合自己的需求做一個自己的版本。

雖然美團不是大公司，但在這裡寫一下我們的情況，僅供參考。

開發時的和部署時類庫的引用和存放是一致還是不同?

開發環境和部署環境的類庫代碼都是相同的，但物理位置不同。部署環境的類庫在CDN上，開發環境的類庫在開發伺服器上。

模塊放在項目中還是放在 CDN 之類伺服器?
模塊放在項目中，部署時都在CDN上。

渲染網頁用 Nginx 還是其他動態語言的 Web 伺服器?
前面用ngnix做負載均衡，後面用apache做web伺服器。

製作網頁的流程, 是現有設計師的稿, 還是先看模塊?
先有設計師的稿再寫模塊，但很多時候並不需要設計師，因為架子已經搭好了，界面規範和基礎元素都有，一般的界面前端工程師都能搞得定。

會選擇用自己寫的模塊還是從社區尋找模塊?
基礎框架用的YUI3，大部分二次開發的底層模塊，還有和業務緊密結合的UI模塊都是自己寫的。當然也會用社區寫的模塊，比如上傳組件、highcharts、Ace等。如果說怎麼選擇模塊的話，那就是具體情況具體分析了，總體原則有兩個：

  1. 能不自己寫，就不自己寫；
  2. 選擇最符合需求的，一般來說，要麼選最好的，要麼選最快出結果的
填坑開始，根據關鍵詞為線索一條不條補全吧，更新時間記錄在第一行（LAST UPDATE: 兒童節 4:21 AM）。

和項目相關的重要關鍵詞有以下，雖然看起來和題目關聯不大，但是最後的方案選擇，往往與這些因素都相關：

  1. 項目類型
    1. 主要職責範圍內的活是什麼類型的
      1. 工作量主要在純前端部分的活（移動/PC）
      2. 工作量除了處理前端外，還需要處理服務端的活（各種形式的前後端交互數據）
    2. 是否需要遷就項目終端受眾，簡而言之，對內對外，開發和受眾誰強勢誰弱勢
    3. 是一版之後再無新版，還是需要持續維護，慢慢做大的類型，是否可以將項目作為實驗項目或者培養新人練手任務
  2. 人力資源
    1. 項目可投入的人力資源有誰，分別是什麼角色，團隊夥伴的技能經驗儲備
    2. 如果後續需要持續維護，是否需要考慮公司內||團隊內或者接手人員的技能儲備和學習成本
    3. 需要共建與否以及是否可以使用團隊已有技術儲備
  3. 時間節點
    1. 時間周期長短、平均時間內的工作量
    2. 多人組隊，考慮溝通、聯調成本
    3. 時間點有依賴或者交叉的情況下（前端先發/後發）：需求評審、視覺評審、項目啟動、視覺交付、自測聯調、提測冒煙....
  4. 項目風險
    1. 人
      1. 產品經理喜歡變來變去的，考慮後期產品形態變化，考慮方案和實現的變化
      2. 一個人solo可能會生病，考慮壓力問題和時間點問題，考慮方案是否容易快速實施
      3. 多人組隊，可能遇到溝通不愉快或者講不清楚的問題，考慮什麼方案減少溝通成本和聯調成本
      4. 老闆。據說最後項目上線前被老闆砍掉的情況不少見，如果經驗豐富，那麼考慮建設方案和投入程度，以及上面提到的是否使用實驗性質的方案以減少損失。

接下來來簡單的說一下，上述不同組合下的簡單選擇，一家之言，歡迎斧正。

情景1:

實習生期間，在一個不以前端見長的團隊/公司中，負責產品功能相對簡單和單純的後台的功能開發。同類型職業以及一起組隊做項目的人數少，可能你是唯一的工程師。

情景2:

實習生期間，在一個以前端見長的團隊/公司中，負責特別細的一個或者幾個功能/小產品。你是團隊前端芸芸眾生中的一枚。個別項目存在共建。

情景3:

工作不到一年，在一個業界知名的團隊中，負責一塊業務線以及一些小產品的開發。和上面一樣，你有許多有共同話題的前端戰友。很多項目存在共建。

情景4:

工作不到一年，在一個一般的創業團隊中，負責所有的產品的前端相關的活。多數情況下，你是一個人在戰鬥，大量和別人共建的情況。

情景其他：

理論上，工作一年以上的童鞋，應該可以直接點贊並無視本帖了。

睡醒了繼續寫，遁~

---歷史的分割線---

挖個大坑，接下來慢慢填（估計數月）

首先，做項目中，我們可能會遇到的問題可能會有：

問題

  • 做新的項目的時候，整套工程方案是什麼，除了數據和業務層的實現外，前端（服務端+客戶端）的工程方案選擇什麼
    • 移動端業務的時候，選擇什麼
      • 單頁應用
      • 多頁應用
      • 特殊的活動頁
    • 傳統PC業務的時候，選擇什麼
      • 單頁應用
      • 多頁應用
      • 特殊的活動頁
    • 降級方案如何促成
      • 依賴開關進行的功能降級（包括兼容）
      • 純粹根據介面降級
  • 做項目時候，對應的協作規範和工具鏈如何儘可能趨同（約束）
    • 書寫風格？提交格式化？
    • 代碼質量？review？提交lint？test？
      • 具體到測試中，該用什麼框架，BDD如何,TDD又該如何，跨瀏覽器UI如何做自動測試
    • 三方依賴的資源管理？字體/圖片/媒體/甚至模板 ？HTTPS support?
    • 配套CDN的支持
    • 三方依賴的數據介面？mock？dev env?
  • 已經做完的項目中的內容的復用（如何做一個靠譜的模塊倉庫）
    • 優秀的後端模塊/功能
    • 優秀的前端模塊/功能
    • 數據介面包裹復用？
  • 打包發布，出錯回滾，模擬環境模擬和追錯
    • python/php/nodejs如何發布管理
    • 純前端資源如何發布管理
  • 維護/集成新組件
    • 上線後如何做監控
    • 遇到問題如何報警

解決方案


一千個人心中有一千萬個蒼老師，場景不同，訴求不同，解決方案也不同。

個人認為解決問題的關鍵除了積累之外，關鍵在於：模塊化倉庫、固化簡單方案場景（同構化）並配套腳手架方案。


挖坑完畢，待填

  • 開發時的和部署時類庫的引用和存放是一致還是不同？

開發時，把應用代碼分支拉到本地，這些分支可以只包含你要修改的應用，也可包含你要引用的類庫。在本地搭建webserver，修改host映射到本地。開發過程中要引用類庫地址時直接引用線上地址，會被webserver中轉到本地代碼上。 發布時直接發布到對應機器上就行，代碼里不用再修改線上路徑。

  • 模塊放在項目中還是放在 CDN 之類伺服器？

項目是你要做一件事建的項目，跟代碼模塊沒關係。大公司前端代碼一般會發布帶cdn。

  • 渲染網頁用 Nginx 還是其他動態語言的 Web 伺服器？

看需要了，一般是php和java的， Nginx lighttpd apache都有用

  • 製作網頁的流程，是先有設計師的稿，還是先看模塊？

當然是現有設計稿，至少你要先知道做什麼，再寫代碼吧。

  • 會選擇用自己寫的模塊還是從社區尋找模塊？

自己寫，如果某個函數忘記了或者樣式調整不好可以參考網上的資料，模塊當然自己寫。

求前端講師，在家會議軟體授課，小班，一小時300到800，晚上和周末授課。 求別刪除

原來做的大多是集成在發布產品中的WEB前端，不是發布到互聯網上的。是用戶安裝到自己的伺服器上配合其他軟體使用的。類似於oracle的web管理界面之類。

部分問題如下：
開發時的和部署時類庫的引用和存放是一致還是不同?
:: 這個安裝性的自然不一致，開發js，css是未混淆和未合併的。部署（或者稱為安裝，或者生成版本時）使用的是合併後的js和css


製作網頁的流程, 是現有設計師的稿, 還是先看模塊?
:: 先有交互設計師設計幾乎所界面，操作模式，
再有視覺設計師設計出來常用場景和常用控制項。要求覆蓋交互設計師的所有界面。
然後開發人員根據邏輯需求分到各個模塊中開發。

會選擇用自己寫的模塊還是從社區尋找模塊?
::多數是自己寫的模塊。使用的前端框架是自的框架（很重的框架，自完備型的）

一般線上全 docker 環境，通過上傳 git 合併到 master 分支後，自動部署系統會自動監控並 pull 代碼，在 jenkins 中可以看到 deploy 中 build 的全過程，會全新在設定好的集群中 build 新的 docker

企業應用：

1. 開發時的和部署時類庫的引用和存放是一致還是不同？

A: 開發和部署使用完全一樣的類庫。底層類庫開發人員直接更新主server上的庫版本，包括源碼和運行時，上層AP開發人員默認直接使用主server上的運行時版本。有問題時加上develop_xxx=1，切換為載入類庫源碼。

因其它開發團隊也開始使用我們的類庫，因此類庫開發人員也會適時更新到他區主server（跨國）。

2. 模塊放在項目中還是放在 CDN 之類伺服器？

A: 直接放在web主server上

3. 渲染網頁用 Nginx 還是其他動態語言的 Web 伺服器？

A: 瀏覽器渲染

4. 製作網頁的流程，是先有設計師的稿，還是先看模塊？

A: 企業應用無需特別設計網頁。需求分析人員與用戶確認好界面後，交給開發人員實現。

5. 會選擇用自己寫的模塊還是從社區尋找模塊？

A: 社區已有的類庫直接使用，如jQuery,圖表，JS AST分析器。其它所有組件自寫。

可以看看百度的FIS

公司也算不小，但是我不是前端，只能大概說一下前端的情況。

開發時的和部署時類庫的引用和存放是一致還是不同?
開發時，前端會在自己機器上用nginx搭建一個簡單的前端環境來模擬CDN。
部署時，前端會用腳本壓縮合併JS，並上傳到CDN，路徑中存在版本號。

模塊放在項目中還是放在 CDN 之類伺服器?
前端有單獨的SVN存放相關內容，但是部署上線時都會經過壓縮合併、加上版本號同步CDN。

渲染網頁用 Nginx 還是其他動態語言的 Web 伺服器?
前端nginx，後端resin或tomcat。
所有靜態內容包括圖片、flash、js、css等全部由CDN完成（CDN那邊應該是nginx）。

製作網頁的流程, 是現有設計師的稿, 還是先看模塊?
首先由設計師出設計稿，之後交由前端童鞋來切圖、做頁面。
通常，設計師會根據整個網站的風格來設計，這樣前端就可以復用已有的UI庫了，但這種情況不多。。。

會選擇用自己寫的模塊還是從社區尋找模塊?
我們有一套自己的前端庫，很大很全，各項功能都有。。很少從社區尋找。。


另外，贊成@Cat Chen的答案~

我們公司是這樣做的
1，前後端完全分離
2，前段html javascript放在nginx里
3，通過配置nginx的反向代理等，講前端的ajax請求轉發到後端伺服器（前端全部是ajax請求）
4，後端採用分散式部署在16台wildfly上，前身就是jboss

@張雲龍 為真么不使用前置？幾台機器新的工程，幾台機器老的工程。發布時候做前置機的IP 翻轉就好了，出問題了還能翻轉回老的環境。測試還能直接在新的PROJECT 上面做測試。HOST 裡面MAP IP地址就可以測試了。

此問題沒有標準答案。我個人傾向於把前端開發者定義為全棧程序員。這種個體全能是被工作分工困難倒逼出來的，是不利於工程的。

對於不同的技術棧的團隊，「前端」的工作內容出入較大，大公司的流水線上的工位也不是完全一致的，所以幾乎每家前端乾的事情都不一樣。如果僅僅討論部署和開發流程，上面幾位已經闡述了大方向和思路。這些的思路和方案完全就是傳統軟體工程過去積累出的經驗和方案的前端版本，只不過由於過去的「前端技術」的客觀條件和需求還不足以暴露出這些工程問題，所以基本沒人討論這些問題。

對比前端工程和傳統軟體工程的各個環節的解決方案數量，會發現前端的可選方案出奇的多。由此可見當下前端生態的混亂的程度。我認為造成這種局面的原因在於，現在前端技術中的中心對象HTML文檔的模塊化方案還沒有事實標準， 所以目前生產環境中的所有的前端工程方案都只能借用其他的技術來實現HTML的模塊化，這一點其實是很彆扭的。這樣做也大大增加前端工程的複雜度。只有待這一問題有了大家認可的解決方案(有可能是Web Components)，前端技術才能有較為統一的最佳實踐。

開發時的和部署時類庫的引用和存放是一致還是不同?
開發時候用的源碼開發，部署的時候用的壓縮後的，性能優化！
模塊放在項目中還是放在 CDN 之類伺服器?
你說的模塊是JS類庫嗎？對於前端的js和css文件放在獨立的伺服器就行，主要設置緩存，減少客戶端的重複請求壓力；
渲染網頁用 Nginx 還是其他動態語言的 Web 伺服器?
前端頁面的渲染都是瀏覽器來處理的，至於動態語言的運行，看你用的什麼開發語言來配置環境，Nginx和apache是用來運行php語言的，iis運行asp和c#,tomcate運行java語言
製作網頁的流程, 是現有設計師的稿, 還是先看模塊?
當然先看模塊，有交互設計師做出原型，然後是設計人員根據原型做設計搞，最後是前端做頁面，最後是開發人員嵌入程序；
會選擇用自己寫的模塊還是從社區尋找模塊?
根據需求來，複雜的模塊可以採用第三方的，簡單的可以自己直接寫；

看了這個帖子好幾遍了,我就問一個問題,我後台一個cms系統，我有好多頁面，其中有一個html片段是通過伺服器端包含的，好多頁面都引用了這個html片段，那麼那麼問題來了，按照你的思路，我做非覆蓋式發布，靜態文件通過工具比如fis打了hash之後先扔了線上去，然後呢，我下一步肯定要修改頁面了吧，但是問題來了，我是先修改伺服器端包含的html片段呢還是先修改頁面上的引用呢，這個問題就是我的html片段所依賴的靜態文件引用並不在一個地方.此時我要先修改引用，那麼ok，頁面中的引用是新的，但是伺服器端包含的那部分html片段卻是舊的，反之亦然，我先修改伺服器包含的html片段，那麼線上所有包含了這個伺服器端html片段的頁面dom都變了，然而呢，引用未變，即使靜態文件已經在線上。不知道這個先改引用呢，還是先改html片段的問題如何做灰度升級。。。 @張雲龍

JavaScript 方面的工具不太好說。有一些明顯的特徵和趨勢：

Node.js 和 npm 將變得至關重要，因為你採用的工具記得上都是 Node.js 和 npm 實現管理的。

Gulp 和/或 Webpack 也值得嘗試一下。

了解ES6，即使您仍然在向後兼容的 ES5 項目上工作。

jQuery是明顯是最受歡迎的。然而隨著 IE 的消亡，jQuery 的跨瀏覽器支持變得沒那麼重要，並且許多功能已經和瀏覽器原生 API 和 CSS 重複。https://0x9.me/MsIqW

先說一句，學習了。

但畢竟自己的公司不是大公司，待過的公司發現基本都是不重視前端這一塊，基本停留在原始加一些框架上面。前端打個包，給後端。沒有交流，沒有團隊，沒有意識。

正式服用docker構建部署，dev用jekins ci持續集成

推薦閱讀：

※Web 前後端分離的意義大嗎？

TAG:前端開發 | JavaScript | Nginx | SeaJS | 前端工程化 |