簡(jiǎn)介：

詳情頁(yè)也叫做單品頁(yè)立叛，域名以「item.jd.com/skuid.html」為格式的頁(yè)面造壮。是負(fù)責(zé)展示京東商品 SKU 的落地頁(yè)吼过。主要任務(wù)是展示和商品相關(guān)的信息泼诱，如：價(jià)格坛掠、促銷、庫(kù)存治筒、推薦屉栓，從而引導(dǎo)用戶進(jìn)入購(gòu)買流程。同時(shí)單品頁(yè)有很多版本耸袜。一般分為兩類系瓢。一類我們通常看到的「通用類目詳情頁(yè)」—— 所有類目都可以使用句灌，一類是不經(jīng)常看到的「垂直屬性詳情頁(yè)」—— 一些有特殊屬性的商品集合

item version

首先。由于詳情頁(yè)大量（sku上億）胰锌、高并發(fā)（日 pv 約 5000 萬(wàn)）等特性骗绕，在很長(zhǎng)的一段時(shí)間里，單品頁(yè)面都是后端程序生成靜態(tài)頁(yè)面使用 CDN 來(lái)解決大量资昧、高并發(fā)的問(wèn)題酬土。

其次。單品頁(yè)涉及的「三方」系統(tǒng)特別多格带，比如：促銷撤缴、庫(kù)存、合約叽唱、秒殺屈呕、預(yù)售、推薦棺亭、IM虎眨、店鋪、評(píng)價(jià)社區(qū)镶摘。而單品頁(yè)的主要任務(wù)就是展示這些系統(tǒng)的信息嗽桩，并且適當(dāng)?shù)奶幚硭麄冎g的沖突關(guān)系，而這些系統(tǒng)的接口一般都使用 異步 Ajax 來(lái)完成凄敢，因?yàn)?其一 CDN 無(wú)法做到頁(yè)面的動(dòng)態(tài)化碌冶，其二 一些系統(tǒng)的信息對(duì)實(shí)時(shí)性要求特別高（價(jià)格、秒殺）涝缝，即使使用后端動(dòng)態(tài)渲染也很難做到無(wú)緩存 0 延遲
基于上面兩個(gè)原因扑庞，注定了單品頁(yè)是一種重多系統(tǒng)業(yè)務(wù)邏輯展示型頁(yè)面。重前端頁(yè)面俊卤。我大概匯總了一下頁(yè)面上異步接口嫩挤，總共約有 30 個(gè)，頁(yè)首屏的接口特別重要消恍，接口之間幾乎都有耦合關(guān)系

item-async-service

前端的發(fā)展歷程

混沌時(shí)期

混沌時(shí)期的單品頁(yè)并沒(méi)有前端開(kāi)發(fā)的概念岂昭。核心的功能腳本只有三個(gè)：促銷價(jià)格（promotion.js）、庫(kù)存地區(qū)（iplocation.js）狠怨、其它邏輯（pshow.js）约啊。這三個(gè)腳本分別是三個(gè)不同團(tuán)隊(duì)的同事負(fù)責(zé)維護(hù)，當(dāng)時(shí)我剛進(jìn)入京東的時(shí)候在 UED 部門佣赖，負(fù)責(zé)頁(yè)面腳本整體的維護(hù)工作和 pshow的開(kāi)發(fā)恰矩。那時(shí)候我自己維護(hù)的 pshow.js 腳本壓縮后只有 80 kb，所有的代碼都是過(guò)程式的憎蛤，沒(méi)有任何使用模式和代碼技巧外傅，JS 最多也只被用來(lái)做個(gè)判斷渲染 DOM纪吮。那時(shí)候的前端工作內(nèi)容只在 UI 層面，寫樣式和一些交互腳本

這個(gè)階段給我最深刻的感覺(jué)是單品頁(yè)后端模板很少維護(hù)（后端架構(gòu)是最老的 aspx 版本）萎胰。大多數(shù)的改動(dòng)都要用 JavaScript 去動(dòng)態(tài)渲染碾盟。因?yàn)楹蠖隧?yè)面是一個(gè)生成器生成的。如果頁(yè)面后端模板有改動(dòng)那么就需要全量的生成一次技竟，過(guò)程可能需要幾個(gè)小時(shí)

初見(jiàn)端倪

當(dāng)我接手這個(gè)項(xiàng)目時(shí)剛好有一次大改版冰肴，就在這時(shí)候老大說(shuō)頁(yè)面上的腳本都要放在我們手里維護(hù)。然后就是一大波的重構(gòu)榔组、重寫熙尉。基本上 pshow 被重寫了大概 80% 其它的因?yàn)闃I(yè)務(wù)邏輯的問(wèn)題并沒(méi)有完全重寫搓扯，只是做了些代碼層面的優(yōu)化

有一個(gè)模板引擎叫 [trimPath]检痰，知道這個(gè)的估計(jì)都算老前端的了。最早的客戶端 JavaScript MVC 模式代表作品擅编，只到現(xiàn)在還是使用攀细。這個(gè)階段像評(píng)價(jià)這種完全異步加載的模塊特別適合使用模板引擎來(lái)減少維護(hù)的工作量。這個(gè)時(shí)候雖然頁(yè)面上的代碼并不都是我們寫的爱态，但基本上前端對(duì)頁(yè)面的 JavaScript 有了控制權(quán)谭贪，接下來(lái)的事情就是尋找機(jī)會(huì)逐個(gè)優(yōu)化

這段時(shí)間是最痛苦的時(shí)候，維護(hù)的工作統(tǒng)一到前端锦担。然后后端幾乎沒(méi)有變化俭识，只是在一段時(shí)間將后臺(tái)的架構(gòu)從 aspx 過(guò)渡到了 java。本質(zhì)上并沒(méi)有什么改變洞渔。前端卻做了比以前更多的事情套媚，也是在這個(gè)時(shí)候我接手了大量的維護(hù)工作（包含全站公共庫(kù)的維護(hù)）使得我意識(shí)到了一些自動(dòng)化、工程化方面的重要性磁椒，后文會(huì)主要講解堤瘤，順便說(shuō)下，那時(shí)候前端自動(dòng)化工具 Grunt 剛面世浆熔，但是我自己卻用的是 [apache ant]本辐，不過(guò)不久就切換到了 Grunt 來(lái)構(gòu)建項(xiàng)目

撥云見(jiàn)日

單品頁(yè)不僅重系統(tǒng)邏輯，也重維護(hù)
在這段時(shí)間里一方面有正常的維護(hù)類需求要做医增，一方面自己也不斷的學(xué)習(xí)新知識(shí)為以后的改版做鋪墊慎皱。不過(guò)就在這時(shí)單品頁(yè)有歷史意義的一次技改出現(xiàn)了 —— 單品頁(yè)動(dòng)態(tài)化技改。

總的來(lái)說(shuō)這次的改版后很多數(shù)據(jù)直接從后端讀取叶骨，不再?gòu)那岸水惒将@取而且我們也做過(guò)一些異步加載的優(yōu)化茫多，多接口 combo 從統(tǒng)一服務(wù)吐出給前端使用。這時(shí)前端就不用再為異步接口的加載時(shí)苦腦了忽刽，只需要專注系統(tǒng)接口的邏輯

隨著這次技改天揖，前端的代碼也迎來(lái)了模塊化的時(shí)代夺欲。我們把所有的前端代碼都進(jìn)行了模塊化然后基于 SeaJS 重寫，配合 Nginx concat 功能實(shí)現(xiàn)了本地模塊化開(kāi)發(fā)宝剖，線上服務(wù)端合并

單品頁(yè)前端模塊的結(jié)構(gòu)與劃分

概覽

first-screen-normal-module

上圖可以看出洁闰，基本上最核心的模塊都在首屏。每個(gè)模塊都有單獨(dú)的一/多個(gè)腳本万细。代碼行數(shù)（LOC）由 230+ ~ 1200+ 不等。通常來(lái)說(shuō)代碼行數(shù)越多代碼復(fù)雜性就越高纸泄，邏輯越復(fù)雜赖钞。很難想象「購(gòu)買方式」這種只有一行屬性選擇功能的代碼行數(shù)卻 高達(dá) 1200 多行。其主要原因就在于購(gòu)買方式所在的系統(tǒng)和其它首屏核心系統(tǒng)（庫(kù)存聘裁、促銷雪营、地址選擇、白條）都有邏輯上的耦合
看著不錯(cuò)衡便，然而在一個(gè)前端工程師眼里至少應(yīng)該是這樣的（我只取了一些典型的模塊献起，并不是全部）：

first-screen-in-fe-eye

這就可以解釋為什么有的時(shí)候只是加一個(gè)很小的東西我們都為考慮再三然后通過(guò) AB 測(cè)試提取相關(guān)數(shù)據(jù)，最后后再進(jìn)行決策镣陕。單品頁(yè)的首屏可以說(shuō)是寸土寸金

按什么維度劃分模塊

起初我按模塊的屬性劃分谴餐，比如：核心、公共腳本呆抑、模塊腳本岂嗓。但用了一段時(shí)候以后發(fā)現(xiàn)這樣劃分在單品這種大型系統(tǒng)中并不科學(xué)，因?yàn)檫@樣劃分出來(lái)的代碼只有劃分的人知道是什么規(guī)則鹊碍，其它人接手代碼很難快速掌握代碼架構(gòu)厌殉，而且尤其在模塊比較多的時(shí)候不方便維護(hù)
后來(lái)我嘗試完全以功能模塊在頁(yè)面上出現(xiàn)的位置維度劃分。這樣以來(lái)維護(hù)起來(lái)方便多了侈咕，需要修改某個(gè)模塊代碼只需要對(duì)照著圖里面標(biāo)識(shí)的模塊信息就能輕易找到代碼

整體核心模塊

我們按頁(yè)面上的模塊結(jié)構(gòu)首屏劃分出來(lái)這幾個(gè)核心模塊：

• curmb - 面包屑
• concat - 聯(lián)系咨詢相關(guān)店鋪信息
• prom - 價(jià)格促銷信息
• address - 地區(qū)庫(kù)存選擇公罕，配送服務(wù)
• color - 顏色尺碼
• buytype - 合約機(jī)購(gòu)買方式
• suits - 套裝購(gòu)買
• jdservice - 增值服務(wù)
• baitiao - 白條支付
• buybtn - 購(gòu)買按鈕
• info - 地區(qū)提示信息

項(xiàng)目的整體樹(shù)形結(jié)構(gòu)是這樣的：

project-structure

模塊內(nèi)部結(jié)構(gòu)

比如下面這個(gè)大圖預(yù)覽的功能，我全部放在一個(gè)文件夾里面維護(hù)耀销，但是邏輯上的 JavaScript 模塊是分離的楼眷，只是說(shuō)文件夾（preview）就代表頁(yè)面上的某一部分功能集合

module-structure

注意文件夾的命名有一定的規(guī)則：

模塊腳本與樣式名必須一樣

需要制作 sprite 的圖片統(tǒng)一放在 module/i 目錄下面，生成的 sprite 圖片也在其中

生成的 mixin 在模塊根目錄下树姨，便于其它樣式文件調(diào)用

我們?cè)賮?lái)看下自動(dòng)生成生成的 __sprite.scss 是什么內(nèi)容：
/* __sprite.scss 自動(dòng)生成 /@mixin sprite-arrow-next { width: 22px; height: 32px; background-image: url(i/__sprite.png); background-position: -0px -30px;}/ preview.scss 手動(dòng)添加 */@import "./__sprite";.sprite-arrow-next { @include sprite-arrow-next;}

注意引用的 mixin 名稱和我們需要手動(dòng)添加的樣式類名一致摩桶。當(dāng)然也可以直接生成一個(gè)類名對(duì)應(yīng)的樣式，但是靈活性不好帽揪。比如 hover 的時(shí)候是另外一張圖片就沒(méi)法自動(dòng)生成了

前端技能樹(shù)

HTML

DOM 節(jié)點(diǎn)數(shù)

與重業(yè)務(wù)邏輯的頁(yè)面不同硝清，重展示的頁(yè)面一般具有很高的 DOM 節(jié)點(diǎn)數(shù)。比如京東首頁(yè)转晰，正常情況加載完頁(yè)面一共有 3500 多個(gè) DOM 節(jié)點(diǎn)芦拿，基本上全部用于展示商品信息士飒、廣告圖和內(nèi)容布局，頁(yè)面上的三方異步服務(wù)也比較少蔗崎。尤其像頻道頁(yè)基本上沒(méi)有什么業(yè)務(wù)上的邏輯酵幕，全部是靜態(tài)頁(yè)面。這種頁(yè)面的特點(diǎn)是更新?lián)Q代頻率高缓苛，一年兩三次改版很正常芳撒，CMS 做模塊化后兩天換個(gè)皮膚都是沒(méi)問(wèn)題的。但是這種思路并不適合單品頁(yè)未桥。單品頁(yè)更重業(yè)務(wù)邏輯笔刹，同時(shí)展示層 UI 邏輯也有很多關(guān)系

我自己的經(jīng)驗(yàn)是：頁(yè)面上的 DOM 節(jié)點(diǎn)數(shù)絕對(duì)不能超過(guò) 5000 個(gè)，否則頁(yè)面滾動(dòng)的時(shí)候就會(huì)出現(xiàn)卡頓的情況冬耿，尤其是移動(dòng)端
同步渲染還是異步加載

理論情況下最好做法是后端同步動(dòng)態(tài)渲染頁(yè)面舌菜，但是由于 Web 應(yīng)用中很多功能都是用戶行為驅(qū)動(dòng)的。同步加載不可避免的消耗了后端服務(wù)資源亦镶。比如：非首屏模塊（公共頭尾日月、評(píng)價(jià)）、點(diǎn)擊事件觸發(fā)的 DOM 內(nèi)容（異步 tab）

所以我的經(jīng)驗(yàn)是：能放到后端做判斷渲染的 DOM 就盡量放在后端（尤其是首屏）缤骨。這樣做的好處有四點(diǎn)好處

1. 后端渲染頁(yè)面相對(duì)穩(wěn)定爱咬，不像前端 JavaScript 動(dòng)態(tài)渲染 DOM，可能因?yàn)槟_本報(bào)錯(cuò)或者不可用造成模塊都無(wú)法展示

2. 可訪問(wèn)性荷憋、SEO 及用戶體驗(yàn)也比較好台颠。不會(huì)產(chǎn)生腳本的渲染抖動(dòng)問(wèn)題

3. 一定程度上減少了前端渲染頁(yè)面的復(fù)雜性，減少前端代碼復(fù)雜度

4. 邏輯統(tǒng)一到一個(gè)地方維護(hù)起來(lái)也方便勒庄，而且后端應(yīng)該為業(yè)務(wù)邏輯負(fù)責(zé)串前，前端應(yīng)該為展示UI 交互負(fù)責(zé)

對(duì)于異步渲染的模塊來(lái)說(shuō)，后端通常需要判斷 「頁(yè)面有什么元素」实蔽，以及元素之間的依賴對(duì)應(yīng)關(guān)系荡碾；而前端需要專注于 「元素應(yīng)該怎么展示」，UI 層面的交互以及模塊與模塊之前的邏輯關(guān)系
其實(shí)更多的時(shí)候 異步是一種沒(méi)有辦法的辦法局装，也就是說(shuō)異步是其它方案都解決不了的情況下才考慮的

外鏈靜態(tài)資源

盡量使用外鏈 CSS 和 JavaScript 資源坛吁，一方面便于緩存，減少服務(wù)同步輸出的資源浪費(fèi)铐尚。IE 6 里面會(huì)有一些可怪的 bug拨脉，比如有內(nèi)聯(lián)樣式 style 標(biāo)簽的頁(yè)面 A 如果在另外一個(gè)頁(yè)面 B 中的 link 標(biāo)簽中引用，那么這段 style 會(huì)在 B 頁(yè)面也起作用

使用雙協(xié)議的 URL

使用 //來(lái)代替http:和 https:瀏覽器會(huì)自動(dòng)適應(yīng)兩種協(xié)議的資源訪問(wèn)宣增，兼容性較好玫膀。注意 IE 8 下使用腳本更新 src 為雙協(xié)議時(shí)會(huì)出現(xiàn) bug，建議用 location.protocol來(lái)判斷然后做兼容處理

刪除元素默認(rèn)屬性

比如 script 標(biāo)簽?zāi)J(rèn)的 type 就是 text/javascript爹脾，如果 script 里面的內(nèi)容是 JavaScript 時(shí)可以不用寫 type帖旨。另外如果要在頁(yè)面里面插入一段不需要瀏覽器解析的 HTML 片段時(shí)可以將 type 寫成 text/x-template（任意不存在的 type） 用于放置模板文件箕昭，通常用來(lái)在腳本中獲取其 innerHTML 而無(wú)任何負(fù)作用
給腳本控制元素加上類鉤子
在腳本中取頁(yè)面元素使用 J-
前綴類名，與普通樣式類分離解阅。這樣做會(huì)生成很多冗余的類名落竹，但卻很好的降低了樣式和腳本的耦合，并且在重構(gòu)和腳本職位分開(kāi)團(tuán)隊(duì)里會(huì)是一條最佳實(shí)踐

CSS

樣式分類

所有頁(yè)面只共享一個(gè) sass Mixin货抄，里面包含了基礎(chǔ)的 sass 語(yǔ)法糖述召、常用類（清浮動(dòng)、頁(yè)面整體顏色字體等）
模塊級(jí)的樣式分為兩類：

• 與腳本無(wú)關(guān)的公共樣式蟹地，單獨(dú)在模塊文件夾中組織桨武。比如：按鈕、標(biāo)簽頁(yè)锈津。全部放在 common 模塊中維護(hù)
• 與腳本相關(guān)的模塊級(jí)樣式，與對(duì)應(yīng)模塊腳本放在一起凉蜂，可以引用 common 中的公共樣式琼梆，但不可以被其它模塊引用

雪碧圖

關(guān)于雪碧圖 我經(jīng)驗(yàn)是：永遠(yuǎn)不要想把所有的圖標(biāo)拼合在一起。按模塊而不是按頁(yè)面去拼 sprite 更合理窿吩，更方便維護(hù)茎杂，然后配合構(gòu)建工具自動(dòng)接合生成樣式文件才是最好的解決方案。當(dāng)然如果你的頁(yè)面比較簡(jiǎn)單纫雁，那這條規(guī)則并不適用煌往。說(shuō)到這個(gè)問(wèn)題我就得把珍藏多年的圖片拿出來(lái) show 一把，用事實(shí)來(lái)說(shuō)明為什么把所有圖片都拼在一張圖上就一定是對(duì)的

早期由于年輕篤信將所有的 icon 拼在一張圖上才是完美的（圖 1）

first-sprite

后來(lái)維護(hù)起來(lái)實(shí)在不方便轧邪，就把按鈕全部單獨(dú)接合起來(lái)刽脖。注意，當(dāng)時(shí)的按鈕都是圖片忌愚，設(shè)計(jì)方面要求的很嚴(yán)格曲管。加入購(gòu)物車按鈕做的也非常漂亮（圖 2）

button-sprite

（web前端學(xué)習(xí)交流群：328058344 禁止閑聊，非喜勿進(jìn)Ｋ逗）

然后這些都不是最典型的院水，下面這個(gè) promise icon 才是 （圖 3）

promise-sprite

從圖里面可以看到，這個(gè)功能在第一個(gè)版本的時(shí)候只有 7 個(gè) icon简十，后來(lái)不斷增加檬某，最多的時(shí)候達(dá)到 77 個(gè)。以至于當(dāng)時(shí)每周都會(huì)添加兩個(gè)的頻率

同時(shí)這個(gè) icon 當(dāng)時(shí)接合的時(shí)候技術(shù)上也有問(wèn)題：不應(yīng)該把文字也切到圖片里面螟蝙，主要原因是早期 icon 比較少加上外邊框樣式對(duì)齊的問(wèn)題綜合選擇了直接使用圖片

后來(lái)我就覺(jué)得這樣是不對(duì)的恢恼。然后通過(guò)和產(chǎn)品的溝通，說(shuō)明我的考慮以及新的解決方案后得到了認(rèn)同胶逢。結(jié)果就是對(duì)圖片不進(jìn)行拼合厅瞎，后臺(tái)上傳經(jīng)過(guò)審核的不帶文字 icon饰潜，文字由接口輸出，然后在產(chǎn)品上做了約定：icon 最多不能超過(guò) 4 個(gè)和簸，代碼里也做了相應(yīng)限制彭雾。這樣就能保證頁(yè)面上的請(qǐng)求數(shù)不會(huì)太多同時(shí)方便系統(tǒng)維護(hù)，問(wèn)題得到了解決

適當(dāng)使用 DataURI

這個(gè)在一些小圖片場(chǎng)景方面特別適合锁保，比如 1*1 的占位圖薯酝、loading 圖等，不過(guò) IE 6 并不支持這種寫法爽柒，需要的時(shí)候可以加上一些兼容寫法：
.ELazy-loading { background: url(data:image/gif;base64,R0lGODlhKwAeAJEAAP///93d3Xq9VAAAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQFFAAAACwDAA0AJQADAAACEpSPAhDtHxacqcr5Lm416f1hBQAh+QQJFAAAACwDAA0AJQADAAACFIyPAcLtDKKcMtn1Mt3RJpw53FYAACH5BAkUAAAALAMADQAlAAMAAAIUjI8BkL0CoxQtrYrenPjcrgDbVAAAOw==) center center no-repeat; *background-image: url(//misc.360buyimg.com/lib/skin/e/i/loading-jd.gif);}

關(guān)于兼容性

兼容性可以說(shuō)是前端工程師在平常開(kāi)發(fā)中花費(fèi)很大量無(wú)意義工作的地方吴菠。關(guān)于兼容性我想說(shuō)的是 如果你不愿意去說(shuō)服周圍的人放棄或者讓他們意識(shí)到兼容性是個(gè)不可能完全解決的問(wèn)題，那么你就得為那些低級(jí)瀏覽器給你帶來(lái)的痛苦埋單

其實(shí)更好的辦法是你和設(shè)計(jì)浩村、產(chǎn)品溝通然后給出一種分級(jí)支持的方案做葵。把每種瀏覽器定義一個(gè)級(jí)別。然后在開(kāi)發(fā)功能的時(shí)候以「漸進(jìn)增強(qiáng)」的方式心墅。通常來(lái)講我們的解決方案是在低級(jí)瀏覽器里面保證流程正常進(jìn)行酿矢、模塊可以使用，但忽略一些無(wú)關(guān)緊要的錯(cuò)位怎燥、不透明等問(wèn)題瘫筐，在高級(jí)瀏覽器里面需要對(duì)設(shè)計(jì)稿進(jìn)行精確還原，適當(dāng)?shù)募由弦恍┚咸砘ㄔ诩?xì)節(jié)铐姚。比如微小的動(dòng)畫策肝、邏輯細(xì)節(jié)上的處理等

舉個(gè)例子吧，下面這個(gè)進(jìn)度條表示預(yù)約的人數(shù)隐绵，它是接口異步加載完才展示的之众。如果加載完就立即設(shè)置進(jìn)度條寬度會(huì)顯得生硬無(wú)趣，但是如果加上一點(diǎn)動(dòng)畫效果的話就好多了氢橙。然而問(wèn)題又來(lái)了酝枢，如果加上動(dòng)畫那么邏輯上這個(gè)進(jìn)度條應(yīng)該是一點(diǎn)點(diǎn)的增加，對(duì)應(yīng)的人數(shù)也應(yīng)該是逐個(gè)增加悍手。于是我就做了個(gè)優(yōu)化帘睦，讓人數(shù)在這段時(shí)間內(nèi)均勻的增加。這個(gè)細(xì)節(jié)并不是很容易被人發(fā)現(xiàn)坦康，但是這種設(shè)計(jì)會(huì)讓用戶感覺(jué)很用心而且有意思

pingou

JavaScript

javascript-exec-sequence

單品頁(yè)的腳本加載/執(zhí)行順序：

1. 等待頁(yè)面準(zhǔn)備就緒（DOM Ready）
2. 準(zhǔn)備就緒后加載入口腳本（main.js）竣付，腳本負(fù)責(zé)其它功能模塊的調(diào)度，動(dòng)態(tài)接合模塊通過(guò) seajs 的 require.async
   方法異步調(diào)用
3. 公共模塊（common.js）負(fù)責(zé)加初始化全局變量并掛載到 pageConfig 命名空間
4. 動(dòng)態(tài)模塊數(shù)組滞欠，這個(gè)是后端通過(guò)程序判斷處理生成的一個(gè)模塊名列表古胆。一般只包含首屏需要加載的模塊
5. 后加載模塊（lazyinit.js）初始化，這個(gè)腳本只做一些頁(yè)面滾動(dòng)才加載的模塊事件綁定。當(dāng)模塊出現(xiàn)在視口內(nèi)再使用 require.async 異步加載模塊的資源及初始化

入口腳本

大致代碼如下

/**
* 模塊入口（1. 公共腳本 2. 首屏模塊資源 3. 非首屏「后加載模塊」）
*/
var entries = [];

// 頁(yè)面公共腳本樣式
entries.push('common');
// 頁(yè)面使用到的首屏模塊(后端開(kāi)發(fā)根據(jù)頁(yè)面不同配置需要調(diào)用的模塊)
entries = entries.concat(config.modules);
// 非首屏「后加載模塊」
entries.push('lazyinit');

for (var i = 0; i < entries.length; i++) {
    entries[i] = 'MOD_ROOT/' + entries[i] + '/' + entries[i];
}

if (/debug=show_modules/.test(location.href)) console.log(entries);

require.async(entries, function() {
    var modules = Array.prototype.slice.call(arguments);
    var len = modules.length;

    for (var i = 0; i < len; i++) {
        var module = modules[i];

        if (module && typeof module.init === 'function') {
            module.init(config);
        } else {
            console.warn('Module[%s] must be exports a init function.', entries[i]);
        }
    }
});

注意模塊路徑中的 MOD_ROOT
是提前在頁(yè)面定義好的一個(gè) seajs path逸绎。目的是為了把前端版本號(hào)更新的控制權(quán)釋放給后端惹恃，從而解決了前后端依賴上線不同步造成的緩存延遲問(wèn)題，配置腳本中只有幾個(gè)定義好的路徑：

seajs.config({
    paths: {
        'MISC' : '//misc.360buyimg.com',
        'MOD_ROOT' : '//static.360buyimg.com/item/default/1.0.12/components',
        'PLG_ROOT' : '//static.360buyimg.com/item/default/1.0.12/components/common/plugins',
        'JDF_UI'   : '//misc.360buyimg.com/jdf/1.0.0/ui',
        'JDF_UNIT' : '//misc.360buyimg.com/jdf/1.0.0/unit'
    }
});

還有一點(diǎn)棺牧，在測(cè)試環(huán)境的頁(yè)面中版本號(hào)（上面代碼中的 1.0.12 是一個(gè)全量的版本號(hào)）是后端從 URL 上動(dòng)態(tài)讀取的（使用參數(shù)訪問(wèn)就可以命中對(duì)應(yīng)版本 item.jd.com/sku.html?version=1.0.12
）巫糙。這樣以來(lái)測(cè)試環(huán)境上就可以并行測(cè)試不同版本的需求，而且互不影響颊乘。當(dāng)然如果不同版本的后端代碼也有修改的話這樣是不行的参淹，因?yàn)楹蠖舜a也需要有個(gè)對(duì)應(yīng)的版本號(hào)

不過(guò)我們已經(jīng)解決了這個(gè)問(wèn)題。后端會(huì)在測(cè)試環(huán)境里 動(dòng)態(tài)加載后端模板 并且可以做到版本號(hào)與前端一致乏悄。這樣以來(lái)配合 git 方便的分支策略就可以同時(shí)并行開(kāi)發(fā)測(cè)試多個(gè)需求浙值，不用單獨(dú)配多個(gè)測(cè)試環(huán)境。什么檩小？你還在使用 SVN开呐！哦。那當(dāng)我沒(méi)說(shuō)過(guò)

事件處理模型

客戶端的 JavaScript 代碼基本上都是事件驅(qū)動(dòng)的规求，代碼的加載解析依賴于瀏覽器提供的 DOM 事件负蚊。比如 onload, mouseover, scroll 等
事件驅(qū)動(dòng)的的模型特別適用于異步編程，而 JavaScript 天生就是異步颓哮，所有的異步操作行為都最終會(huì)在一個(gè)回調(diào)函數(shù)（callback）中觸發(fā)

比如單品頁(yè)中價(jià)格接口，加載完成后需要更新 DOM 元素來(lái)展示實(shí)時(shí)價(jià)格鸵荠；地區(qū)選擇接口加載完成后會(huì)更新配送信息冕茅、庫(kù)存/商品狀態(tài)等，偽代碼如下：

/* onPriceReady 和 onAreaChange 可以認(rèn)為都是一個(gè) Ajax 異步函數(shù)調(diào)用
 * code 1 和 code 2 執(zhí)行到的時(shí)間是不確定先后順序的
 */
/* prom.js */
onPriceReady(function(price) {
    // code 1
    $('#price').html(price);
});

/* address.js */
onAreaChange(function(area) {
    // code 2
    $('#stock').html(area.stockInfo);
});

上面的兩段代碼分別在兩個(gè)腳本中維護(hù)蛹找，因?yàn)樗麄兊倪壿嬒鄬?duì)獨(dú)立姨伤。早期并沒(méi)有關(guān)聯(lián)關(guān)系。后來(lái)需求有變庸疾，他們之間需要共享一些對(duì)方的數(shù)據(jù)（切換地區(qū)后需要重新獲取價(jià)格數(shù)據(jù)并展示）乍楚。但是物理上又不能放在一起通過(guò)使用全局變量的方式共享，而且它們都是異步加載接口后才取到數(shù)據(jù)的届慈，并不好確定誰(shuí)先誰(shuí)后（非要做到那就只能用全局變量雙向判斷）徒溪。所以這樣并不能很好的解決問(wèn)題，而且代碼的耦合度會(huì)成倍增加

這時(shí)候我們引入了一種設(shè)計(jì)模式來(lái)解決這種問(wèn)題金顿，我們把這種模式抽象成了自定義事件代碼來(lái)解決這一問(wèn)題臊泌。這段代碼是由 YUI 核心開(kāi)發(fā)者 Nicholas C. Zakas 實(shí)現(xiàn)的。代碼很簡(jiǎn)單揍拆，事件對(duì)象主要有兩個(gè)方法 addListener(type, listener)
和 fire(event)

于是我們重構(gòu)了上面的偽代碼：

/* prom.js */
// 在代碼中注冊(cè)一個(gè)地區(qū)變化事件渠概，獲取變化后的地區(qū) id
// 然后重新請(qǐng)求價(jià)格接口并展示
Event.addListener('onAreaChange', function(data) {
    getAreaPrice(data.areaIds)
});

onPriceReady(function(price) {
    $('#price').html(price);

    Event.fire({
        type: 'onPriceReady',
        data: 'Any data you want'
    })
});

/* address.js */
onAreaChange(function(area) {
    $('#stock').html(area.stockInfo);

    // 在地區(qū)變化后除了做自己該做的事情以外
    // 觸發(fā)一個(gè)名為 onAreaChange 的事件，用來(lái)
    // 通知其它訂閱者事件完成嫂拴，并傳遞地區(qū)相關(guān)參數(shù)
    // 這個(gè)時(shí)候在 onAreaChange Ajax 回調(diào)函數(shù)
    // 中就只需要關(guān)心自己的邏輯播揪，其它模塊的耦合關(guān)系
    // 交給它們自己通過(guò)訂閱事件來(lái)處理
    Event.fire({
        type: 'onAreaChange',
        data: area.ids
    })
});

需要注意的一點(diǎn)是贮喧，必須確保事件先注冊(cè)后觸發(fā)執(zhí)行，也就是說(shuō)先 addListener猪狈， 再 fire

一些典型的性能優(yōu)化點(diǎn)

基本上客戶端的 JavaScript 性能問(wèn)題都來(lái)自于 DOM 查找和遍歷箱沦，在用于的時(shí)候一定要小心，可能不經(jīng)意的一個(gè)操作就會(huì)損失很多性能罪裹，尤其在低端瀏覽器中饱普。順便多說(shuō)一點(diǎn)，現(xiàn)代的 JavaScript 解釋器本身是很快的状共，語(yǔ)言層面的性能問(wèn)題很少遇到套耕。DOM 查找慢是因?yàn)?瀏覽器給 JavaScript 訪問(wèn)頁(yè)面提供的一套 DOM API 本身慢

1. 緩存 DOM 查找，同時(shí) DOM 查找不要超過(guò) 2000 個(gè)峡继，低級(jí)瀏覽器會(huì)卡頓

2. 不要使用鏈?zhǔn)秸{(diào)用 find冯袍，如：find('li').find('a')
   而是 find('li a')

3. 在切換元素顯示狀態(tài)的時(shí)候，如果元素很多碾牌。優(yōu)先使用 show()/hide()
   方法康愤，而不是 css('display', 'block/none')
   前者有緩存，后者會(huì)強(qiáng)制觸發(fā) reflow

4. 給節(jié)點(diǎn)添加 data-xx
   屬性在存放一些數(shù)據(jù)舶吗，通過(guò)使用 jQuery 的 data('xx')
   方法取更高效征冷，減少 DOM 屬性訪問(wèn)

5. 高密度事件（scroll, mousemove）觸發(fā)場(chǎng)景請(qǐng)使用節(jié)流方法
   6.使用事件代理，而不是直接綁定誓琼。如果不確定代碼被調(diào)用次數(shù)检激，可以先解除綁定再綁定具有命名空間的事件處理函數(shù)

6. 盡量少用 DOM 動(dòng)畫，使用 CSS 3 動(dòng)畫代替

前端工程化

原由

前端工程化其實(shí)并不是最近兩年才有的概念腹侣。大約在 2013 年的時(shí)候 Grunt 問(wèn)世的時(shí)候就已經(jīng)有所涉及叔收。這類打包工具主要的目的是自動(dòng)化一些開(kāi)發(fā)流程，我最早使用 Grunt 來(lái)構(gòu)建代碼的時(shí)候只解決了三個(gè)問(wèn)題：

1. 合并壓縮優(yōu)化樣式腳本
2. 上線完自動(dòng)備份
3. 單個(gè)文件打包到多目錄（歷史原因一個(gè)文件線上的路徑有兩種傲隶，需要傳兩個(gè)目錄）

其實(shí)這些工具出現(xiàn)的原因是：當(dāng)時(shí)前端領(lǐng)域的各種基礎(chǔ)設(shè)施很缺乏饺律，而前端的工作內(nèi)容又相對(duì)零散。工作時(shí)需要開(kāi)很多的軟件跺株。再加上 JavaScript 語(yǔ)言本身也很弱复濒，就連包管理這種基礎(chǔ)的東西也沒(méi)有內(nèi)置，以至于模塊化要通過(guò)一些第三方類庫(kù)來(lái)實(shí)現(xiàn)乒省，比如：RequireJS, SeaJS

現(xiàn)狀

如今前端工程的生態(tài)環(huán)境由于 NodeJS 的出現(xiàn)已經(jīng)變得很好了芝薇。你可以根據(jù)自己的需求選一個(gè)合適的直接用到項(xiàng)目里面。像 Grunt, Gulp, browserify, webpack 等作儿。不過(guò)要明白這些工具的出現(xiàn)從另一方面證明了前端開(kāi)發(fā)天生存在很多的問(wèn)題：

• HTML 從誕生到 HTML 5 之前幾乎沒(méi)有任何變化洛二，DOM 性能天生缺失。所以才有了 Virtual DOM 這種東西

• CSS 只是一門描述型的語(yǔ)言，沒(méi)有變量晾嘶、邏輯控制妓雾、語(yǔ)句。所以才出現(xiàn)了 Sass, Less 這種預(yù)編譯工具

• JavaScript 號(hào)稱「高階的（high-level）垒迂、動(dòng)態(tài)的（dynamic）械姻、弱類型的（untyped）解釋型（interpreted）編程語(yǔ)言，適合面向?qū)ο螅╫op）和函數(shù)式的（functional）編程風(fēng)格」的編程語(yǔ)言机断，但是語(yǔ)言本身有很多問(wèn)題（ES 6 之前）楷拳。不適合大型項(xiàng)目的開(kāi)發(fā)、沒(méi)有一些高級(jí)特性的支持吏奸、同時(shí)被其它語(yǔ)言詬病的 callback 風(fēng)格欢揖、單線程執(zhí)行等。所以才出現(xiàn)了像 TypeScript, Babel 這種編譯成 JavaScript 代碼的語(yǔ)言

這些問(wèn)題幾乎都是歷史性的原因和兼容性因素造成的奋蔚。作為一名好的前端工程師要看清楚現(xiàn)狀她混，然后按自己項(xiàng)目的需求去定制一些前端工程化的方案，而不是隨波逐流泊碑。

選擇

其實(shí)現(xiàn)在自己開(kāi)發(fā)一套前端工程化/自動(dòng)化流程的成本已經(jīng)很低了坤按，你只需要學(xué)習(xí)一些 NodeJS 的知識(shí)，配合 NPM 包管理機(jī)制馒过，隨手就搞出一個(gè)構(gòu)建工具出來(lái)臭脓。因?yàn)椴⒉恍枰闳?shí)現(xiàn)什么東西，所有的東西都有現(xiàn)成的包腹忽。腳本壓縮有 UglifyJS谢鹊，CSS 優(yōu)化有 CSS-min，圖片壓縮優(yōu)化有 PNG-quant 等等留凭。你只需要想清楚自己要達(dá)到什么目的，解決什么問(wèn)題就可以抄家伙自己寫一套工作流出來(lái)

我自己的經(jīng)歷也從 Grunt, GulpJS 到現(xiàn)在自造輪子偎巢。自己根據(jù)需求開(kāi)發(fā)出來(lái)一套集成的打包工具蔼夜，當(dāng)然你也可以不用任何打包工具，自己寫一些 NPM Script 來(lái)完全定制化項(xiàng)目開(kāi)發(fā)/測(cè)試/打包流程压昼。我猜這也是為什么現(xiàn)在類似 Grunt 不再那么火求冷，Gulp 遲遲沒(méi)有發(fā)布 4.0 版本的原因。寫一個(gè)構(gòu)建工具的成本太低了窍霞，而且這種集成的工具很難滿足差異的開(kāi)發(fā)需求匠题。

程序、設(shè)計(jì)但金、產(chǎn)品

我始終認(rèn)為程序韭山、設(shè)計(jì)是為了產(chǎn)品服務(wù)的。好的產(chǎn)品是要重視設(shè)計(jì)的，好的（前端）工程師是要有一些審美素養(yǎng)

其實(shí)很多時(shí)候技術(shù)解決方案都是要根據(jù)產(chǎn)品的定位來(lái)設(shè)計(jì)的钱磅，了解產(chǎn)品需求以后才能定制出真正合適的高效的解決方案梦裂。好比前面講到的那個(gè) sprite 案例，如果一開(kāi)始就和產(chǎn)品討論好方案后來(lái)也不可能有那種失控的情況發(fā)生盖淡。在產(chǎn)品形成/上線前期能發(fā)現(xiàn)問(wèn)題比上線后發(fā)現(xiàn)問(wèn)題更容易解決

這部分內(nèi)容和代碼無(wú)關(guān)年柠，就不多說(shuō)了。

總結(jié)

關(guān)于單品頁(yè)的前端開(kāi)發(fā)本篇文章只是冰山一角褪迟，還有很多沒(méi)有提及冗恨，每個(gè)小東西都可以單獨(dú)寫一篇文章來(lái)分享。隨后希望可以有更多的總結(jié)和分享