天天看點
傳回

[轉]京東單品頁前端開發那些不得不說的事兒京東單品頁前端開發那些不得不說的事兒

京東單品頁前端開發那些不得不說的事兒

07,31,2016 10:48 AM

簡介

詳情頁也叫做單品頁，域名以「item.jd.com/skuid.html」為格式的頁面。是負責展示京東商品 SKU 的落地頁面。主要任務是展示和商品相關的資訊，如：價格、促銷、庫存、推薦，進而引導使用者進入購買流程。同時單品頁有很多版本。一般分為兩類。一類我們通常看到的「通用類目詳情頁」—— 所有類目都可以使用，一類是不經常看到的「垂直屬性詳情頁」—— 一些有特殊屬性的商品集合

首先。由于詳情頁大量（sku上億）、高并發（日 pv 約 5000 萬）等特性，在很長的一段時間裡，單品頁面都是後端程式生成靜态頁面使用 CDN 來解決大量、高并發的問題

其次。單品頁涉及的「三方」系統特别多，比如：促銷、庫存、合約、秒殺、預售、推薦、IM、店鋪、評價社群。而單品頁的主要任務就是展示這些系統的資訊，并且适當的處理他們之間的沖突關系，而這些系統的接口一般都使用 異步 Ajax 來完成，因為 其一 CDN 無法做到頁面的動态化，其二 一些系統的資訊對實時性要求特别高（價格、秒殺），即使使用後端動态渲染也很難做到無緩存 0 延遲

基于上面兩個原因，注定了單品頁是一種重多系統業務邏輯展示型頁面。重前端頁面。我大概彙總了一下頁面上異步接口，總共約有 30 個，頁首屏的接口特别重要，接口之間幾乎都有耦合關系

前端的發展曆程

混沌時期

混沌時期的單品頁并沒有前端開發的概念。核心的功能腳本隻有三個：促銷價格（promotion.js）、庫存地區（iplocation.js）、其它邏輯（pshow.js）。這三個腳本分别是三個不同團隊的同僚負責維護，當時我剛進入京東的時候在 UED 部門，負責頁面腳本整體的維護工作和 pshow的開發。那時候我自己維護的 pshow.js 腳本壓縮後隻有 80 kb，所有的代碼都是過程式的，沒有任何使用模式和代碼技巧，JS 最多也隻被用來做個判斷渲染 DOM。那時候的前端工作内容隻在 UI 層面，寫樣式和一些互動腳本

這個階段給我最深刻的感覺是單品頁後端模闆很少維護（後端架構是最老的 aspx 版本）。大多數的改動都要用 JavaScript 去動态渲染。因為後端頁面是一個生成器生成的。如果頁面後端模闆有改動那麼就需要全量的生成一次，過程可能需要幾個小時

初見端倪

當我接手這個項目時剛好有一次大改版，就在這時候老大說頁面上的腳本都要放在我們手裡維護。然後就是一大波的重構、重寫。基本上 pshow 被重寫了大概 80% 其它的因為業務邏輯的問題并沒有完全重寫，隻是做了些代碼層面的優化

有一個模闆引擎叫 trimPath，知道這個的估計都算老前端的了。最早的用戶端 JavaScript MVC 模式代表作品，隻到現在還是使用。這個階段像評價這種完全異步加載的子產品特别适合使用模闆引擎來減少維護的工作量。這個時候雖然頁面上的代碼并不都是我們寫的，但基本上前端對頁面的 JavaScript 有了控制權，接下來的事情就是尋找機會逐個優化

這段時間是最痛苦的時候，維護的工作統一到前端。然後後端幾乎沒有變化，隻是在一段時間将背景的架構從 aspx 過渡到了 java。本質上并沒有什麼改變。前端卻做了比以前更多的事情，也是在這個時候我接手了大量的維護工作（包含全站公共庫的維護）使得我意識到了一些自動化、工程化方面的重要性，後文會主要講解，順便說下，那時候前端自動化工具 Grunt 剛面世，但是我自己卻用的是 apache ant，不過不久就切換到了 Grunt 來建構項目

撥雲見日

單品頁不僅重系統邏輯，也重維護

在這段時間裡一方面有正常的維護類需求要做，一方面自己也不斷的學習新知識為以後的改版做鋪墊。不過就在這時單品頁有曆史意義的一次技改出現了 —— 單品頁動态化技改。關于後端部分的改造細節可以去 開濤的文章 了解

總的來說這次的改版後很多資料直接從後端讀取，不再從前端異步擷取而且我們也做過一些異步加載的優化，多接口 combo 從統一服務吐出給前端使用。這時前端就不用再為異步接口的加載時苦腦了，隻需要專注系統接口的邏輯

随着這次技改，前端的代碼也迎來了子產品化的時代。我們把所有的前端代碼都進行了子產品化然後基于 SeaJS 重寫，配合 Nginx concat 功能實作了本地子產品化開發，線上服務端合并

單品頁前端子產品的結構與劃分

概覽

上圖可以看出，基本上最核心的子產品都在首屏。每個子產品都有單獨的一/多個腳本。代碼行數（LOC）由 230+ ~ 1200+ 不等。通常來說代碼行數越多代碼複雜性就越高，邏輯越複雜。很難想象「購買方式」這種隻有一行屬性選擇功能的代碼行數卻 高達 1200 多行。其主要原因就在于購買方式所在的系統和其它首屏核心系統（庫存、促銷、位址選擇、白條）都有邏輯上的耦合

看着不錯，然而在一個前端工程師眼裡至少應該是這樣的（我隻取了一些典型的子產品，并不是全部）：

這就可以解釋為什麼有的時候隻是加一個很小的東西我們都為考慮再三然後通過 AB 測試提取相關資料，最後後再進行決策。單品頁的首屏可以說是寸土寸金

按什麼次元劃分子產品

起初我按子產品的屬性劃分，比如：核心、公共腳本、子產品腳本。但用了一段時候以後發現這樣劃分在單品這種大型系統中并不科學，因為這樣劃分出來的代碼隻有劃分的人知道是什麼規則，其它人接手代碼很難快速掌握代碼架構，而且尤其在子產品比較多的時候不友善維護

後來我嘗試完全以功能子產品在頁面上出現的位置次元劃分。這樣以來維護起來友善多了，需要修改某個子產品代碼隻需要對照着圖裡面辨別的子產品資訊就能輕易找到代碼

整體核心子產品

我們按頁面上的子產品結構首屏劃分出來這幾個核心子產品：

  • curmb - 面包屑
  • concat - 聯系咨詢相關店鋪資訊
  • prom - 價格促銷資訊
  • address - 地區庫存選擇，配送服務
  • color - 顔色尺碼
  • buytype - 合約機購買方式
  • suits - 套裝購買
  • jdservice - 增值服務
  • baitiao - 白條支付
  • buybtn - 購買按鈕
  • info - 地區提示資訊

項目的整體樹形結構是這樣的：

子產品内部結構

比如下面這個大圖預覽的功能，我全部放在一個檔案夾裡面維護，但是邏輯上的 JavaScript 子產品是分離的，隻是說檔案夾（preview）就代表頁面上的某一部分功能集合

注意檔案夾的命名有一定的規則：

  • 子產品腳本與樣式名必須一樣
  • 需要制作 sprite 的圖檔統一放在 module/i 目錄下面，生成的 sprite 圖檔也在其中
  • 生成的 mixin 在子產品根目錄下，便于其它樣式檔案調用

我們再來看下自動生成生成的 __sprite.scss 是什麼内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
      
/* __sprite.scss 自動生成 */
@mixin sprite-arrow-next {
    width: 22px;
    height: 32px;
    background-image: url(i/__sprite.png);
    background-position: -0px -30px;
}

/* preview.scss 手動添加 */
@import "./__sprite";
.sprite-arrow-next {
    @include sprite-arrow-next;
}

注意引用的 mixin 名稱和我們需要手動添加的樣式類名一緻。當然也可以直接生成一個類名對應的樣式，但是靈活性不好。比如 hover 的時候是另外一張圖檔就沒法自動生成了

前端技能樹

HTML

DOM 節點數

與重業務邏輯的頁面不同，重展示的頁面一般具有很高的 DOM 節點數。比如京東首頁，正常情況加載完頁面一共有 3500 多個 DOM 節點，基本上全部用于展示商品資訊、廣告圖和内容布局，頁面上的三方異步服務也比較少。尤其像頻道頁基本上沒有什麼業務上的邏輯，全部是靜态頁面。這種頁面的特點是更新換代頻率高，一年兩三次改版很正常，CMS 做子產品化後兩天換個皮膚都是沒問題的。但是這種思路并不适合單品頁。單品頁更重業務邏輯，同時展示層 UI 邏輯也有很多關系

我自己的經驗是：頁面上的 DOM 節點數絕對不能超過 5000 個，否則頁面滾動的時候就會出現卡頓的情況，尤其是移動端

同步渲染還是異步加載

理論情況下最好做法是後端同步動态渲染頁面，但是由于 Web 應用中很多功能都是使用者行為驅動的。同步加載不可避免的消耗了後端服務資源。比如：非首屏子產品（公共頭尾、評價）、點選事件觸發的 DOM 内容（異步 tab）

是以我的經驗是：能放到後端做判斷渲染的 DOM 就盡量放在後端（尤其是首屏）。這樣做的好處有四點好處

  1. 後端渲染頁面相對穩定，不像前端 JavaScript 動态渲染 DOM，可能因為腳本報錯或者不可用造成子產品都無法展示
  2. 可通路性、SEO 及使用者體驗也比較好。不會産生腳本的渲染抖動問題
  3. 一定程度上減少了前端渲染頁面的複雜性，減少前端代碼複雜度
  4. 邏輯統一到一個地方維護起來也友善，而且後端應該為業務邏輯負責，前端應該為展示UI 互動負責

對于異步渲染的子產品來說，後端通常需要判斷 「頁面有什麼元素」，以及元素之間的依賴對應關系；而前端需要專注于 「元素應該怎麼展示」，UI 層面的互動以及子產品與子產品之前的邏輯關系

其實更多的時候 異步是一種沒有辦法的辦法，也就是說異步是其它方案都解決不了的情況下才考慮的

外鍊靜态資源

盡量使用外鍊 CSS 和 JavaScript 資源，一方面便于緩存，減少服務同步輸出的資源浪費。IE 6 裡面會有一些可怪的 bug，比如有内聯樣式 style 标簽的頁面 A 如果在另外一個頁面 B 中的 link 标簽中引用，那麼這段 style 會在 B 頁面也起作用

使用雙協定的 URL

使用 

//

 來代替

http:

 和 

https:

 浏覽器會自動适應兩種協定的資源通路，相容性較好。注意 IE 8 下使用腳本更新 src 為雙協定時會出現 bug，建議使用 

location.protocol

 來判斷然後做相容處理

删除元素預設屬性

比如 script 标簽預設的 type 就是 

text/javascript

，如果 script 裡面的内容是 JavaScript 時可以不用寫 type。另外如果要在頁面裡面插入一段不需要浏覽器解析的 HTML 片段時可以将 type 寫成

text/x-template

（任意不存在的 type） 用于放置模闆檔案，通常用來在腳本中擷取其 innerHTML 而無任何負作用

給腳本控制元素加上類鈎子

在腳本中取頁面元素使用 

J-

 字首類名，與普通樣式類分離。這樣做會生成很多備援的類名，但卻很好的降低了樣式和腳本的耦合，并且在重構和腳本職位分開團隊裡會是一條最佳實踐

CSS

樣式分類

所有頁面隻共享一個 sass Mixin，裡面包含了基礎的 sass 文法糖、常用類（清浮動、頁面整體顔色字型等）

子產品級的樣式分為兩類：

  1. 與腳本無關的公共樣式，單獨在子產品檔案夾中組織。比如：按鈕、标簽頁。全部放在 common 子產品中維護
  2. 與腳本相關的子產品級樣式，與對應子產品腳本放在一起，可以引用 common 中的公共樣式，但不可以被其它子產品引用

雪碧圖

關于雪碧圖 我經驗是：永遠不要想把所有的圖示拼合在一起。按子產品而不是按頁面去拼 sprite 更合理，更友善維護，然後配合建構工具自動接合生成樣式檔案才是最好的解決方案。當然如果你的頁面比較簡單，那這條規則并不适用。說到這個問題我就得把珍藏多年的圖檔拿出來 show 一把，用事實來說明為什麼把所有圖檔都拼在一張圖上就一定是對的

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

後來維護起來實在不友善，就把按鈕全部單獨接合起來。注意，當時的按鈕都是圖檔，設計方面要求的很嚴格。加入購物車按鈕做的也非常漂亮（圖 2）

然後這些都不是最典型的，下面這個 promise icon 才是 （圖 3）

從圖裡面可以看到，這個功能在第一個版本的時候隻有 7 個 icon，後來不斷增加，最多的時候達到 77 個。以至于當時每周都會添加兩個的頻率

同時這個 icon 當時接合的時候技術上也有問題：不應該把文字也切到圖檔裡面，主要原因是早期 icon 比較少加上外邊框樣式對齊的問題綜合選擇了直接使用圖檔

後來我就覺得這樣是不對的。然後通過和産品的溝通，說明我的考慮以及新的解決方案後得到了認同。結果就是對圖檔不進行拼合，背景上傳經過稽核的不帶文字 icon，文字由接口輸出，然後在産品上做了約定：icon 最多不能超過 4 個，代碼裡也做了相應限制。這樣就能保證頁面上的請求數不會太多同時友善系統維護，問題得到了解決

适當使用 DataURI

這個在一些小圖檔場景方面特别适合，比如 1*1 的占位圖、loading 圖等，不過 IE 6 并不支援這種寫法，需要的時候可以加上一些相容寫法：

1
2
3
4
      
.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);
}

關于相容性

相容性可以說是前端工程師在平常開發中花費很大量無意義工作的地方。關于相容性我想說的是如果你不願意去說服周圍的人放棄或者讓他們意識到相容性是個不可能完全解決的問題，那麼你就得為那些低級浏覽器給你帶來的痛苦埋單

其實更好的辦法是你和設計、産品溝通然後給出一種分級支援的方案。把每種浏覽器定義一個級别。然後在開發功能的時候以「漸進增強」的方式。通常來講我們的解決方案是在低級浏覽器裡面保證流程正常進行、子產品可以使用，但忽略一些無關緊要的錯位、不透明等問題，在進階浏覽器裡面需要對設計稿進行精确還原，适當的加上一些井上添花在細節。比如微小的動畫、邏輯細節上的處理等

舉個例子吧，下面這個進度條表示預約的人數，它是接口異步加載完才展示的。如果加載完就立即設定進度條寬度會顯得生硬無趣，但是如果加上一點動畫效果的話就好多了。然而問題又來了，如果加上動畫那麼邏輯上這個進度條應該是一點點的增加，對應的人數也應該是逐個增加。于是我就做了個優化，讓人數在這段時間内均勻的增加。這個細節并不是很容易被人發現，但是這種設計會讓使用者感覺很用心而且有意思

JavaScript

單品頁的腳本加載/執行順序：

  1. 等待頁面準備就緒（DOM Ready）
  2. 準備就緒後加載入口腳本（main.js），腳本負責其它功能子產品的排程，動态接合子產品通過 seajs 的 

    require.async

      方法異步調用
  3. 公共子產品（common.js）負責加初始化全局變量并挂載到 pageConfig 命名空間
  4. 動态子產品數組，這個是後端通過程式判斷處理生成的一個子產品名清單。一般隻包含首屏需要加載的子產品
  5. 後加載子產品（lazyinit.js）初始化，這個腳本隻做一些頁面滾動才加載的子產品事件綁定。當子產品出現在視口内再使用 require.async 異步加載子產品的資源及初始化

入口腳本

大緻代碼如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
      
/**
* 子產品入口（1. 公共腳本 2. 首屏子產品資源 3. 非首屏「後加載子產品」）
*/
var entries = [];

// 頁面公共腳本樣式
entries.push('common');
// 頁面使用到的首屏子產品(後端開發根據頁面不同配置需要調用的子產品)
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

 是提前在頁面定義好的一個 seajs path。目的是為了把前端版本号更新的控制權釋放給後端，進而解決了前後端依賴上線不同步造成的緩存延遲問題，配置腳本中隻有幾個定義好的路徑：

1
2
3
4
5
6
7
8
9
      
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'
    }
});

還有一點，在測試環境的頁面中版本号（上面代碼中的 1.0.12 是一個全量的版本号）是後端從 URL 上動态讀取的（使用參數通路就可以命中對應版本 

item.jd.com/sku.html?version=1.0.12

）。這樣以來測試環境上就可以并行測試不同版本的需求，而且互不影響。當然如果不同版本的後端代碼也有修改的話這樣是不行的，因為後端代碼也需要有個對應的版本号

不過我們已經解決了這個問題。後端會在測試環境裡 動态加載後端模闆 并且可以做到版本号與前端一緻。這樣以來配合 git 友善的分支政策就可以同時并行開發測試多個需求，不用單獨配多個測試環境。什麼？你還在使用 SVN！哦。那當我沒說過

事件處理模型

用戶端的 JavaScript 代碼基本上都是事件驅動的，代碼的加載解析依賴于浏覽器提供的 DOM 事件。比如 onload, mouseover, scroll 等

事件驅動的的模型特别适用于異步程式設計，而 JavaScript 天生就是異步，所有的異步操作行為都最終會在一個回調函數（callback）中觸發

比如單品頁中價格接口，加載完成後需要更新 DOM 元素來展示實時價格；地區選擇接口加載完成後會更新配送資訊、庫存/商品狀态等，僞代碼如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
      
/* onPriceReady 和 onAreaChange 可以認為都是一個 Ajax 異步函數調用
 * code 1 和 code 2 執行到的時間是不确定先後順序的
 */
/* prom.js */
onPriceReady(function(price) {
    // code 1
    $('#price').html(price);
});

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

上面的兩段代碼分别在兩個腳本中維護，因為他們的邏輯相對獨立。早期并沒有關聯關系。後來需求有變，他們之間需要共享一些對方的資料（切換地區後需要重新擷取價格資料并展示）。但是實體上又不能放在一起通過使用全局變量的方式共享，而且它們都是異步加載接口後才取到資料的，并不好确定誰先誰後（非要做到那就隻能用全局變量雙向判斷）。是以這樣并不能很好的解決問題，而且代碼的耦合度會成倍增加

這時候我們引入了一種設計模式來解決這種問題 —— 釋出者/訂閱者，我們把這種模式抽象成了自定義事件代碼來解決這一問題。這段代碼是由 YUI 核心開發者 Nicholas C. Zakas 實作的。代碼很簡單，事件對象主要有兩個方法 

addListener(type, listener)

 和 

fire(event)

于是我們重構了上面的僞代碼：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
      
/* prom.js */
// 在代碼中注冊一個地區變化事件，擷取變化後的地區 id
// 然後重新請求價格接口并展示
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);

    // 在地區變化後除了做自己該做的事情以外
    // 觸發一個名為 onAreaChange 的事件，用來
    // 通知其它訂閱者事件完成，并傳遞地區相關參數
    // 這個時候在 onAreaChange Ajax 回調函數
    // 中就隻需要關心自己的邏輯，其它子產品的耦合關系
    // 交給它們自己通過訂閱事件來處理
    Event.fire({
        type: 'onAreaChange',
        data: area.ids
    })
});

需要注意的一點是，必須確定事件先注冊後觸發執行，也就是說先 addListener， 再 fire

一些典型的性能優化點

基本上用戶端的 JavaScript 性能問題都來自于 DOM 查找和周遊，在用于的時候一定要小心，可能不經意的一個操作就會損失很多性能，尤其在低端浏覽器中。順便多說一點，現代的 JavaScript 解釋器本身是很快的，語言層面的性能問題很少遇到。DOM 查找慢是因為 浏覽器給 JavaScript 通路頁面提供的一套 DOM API 本身慢

  1. 緩存 DOM 查找，同時 DOM 查找不要超過 2000 個，低級浏覽器會卡頓
  2. 不要使用鍊式調用 find，如：

    find('li').find('a')

      而是 

    find('li a')
  3. 在切換元素顯示狀态的時候，如果元素很多。優先使用 

    show()/hide()

      方法，而不是 

    css('display', 'block/none')

      前者有緩存，後者會強制觸發 reflow
  4. 給節點添加 

    data-xx

      屬性在存放一些資料，通過使用 jQuery 的 

    data('xx')

      方法取更高效，減少 DOM 屬性通路
  5. 高密度事件（scroll, mousemove）觸發場景請使用節流方法
  6. 使用事件代理，而不是直接綁定。如果不确定代碼被調用次數，可以先解除綁定再綁定具有命名空間的事件處理函數
  7. 盡量少用 DOM 動畫，使用 CSS 3 動畫代替

前端工程化

原由

前端工程化其實并不是最近兩年才有的概念。大約在 2013 年的時候 Grunt 問世的時候就已經有所涉及。這類打包工具主要的目的是自動化一些開發流程，我最早使用 Grunt 來建構代碼的時候隻解決了三個問題：

  1. 合并壓縮優化樣式腳本
  2. 上線完自動備份
  3. 單個檔案打包到多目錄（曆史原因一個檔案線上的路徑有兩種，需要傳兩個目錄）

當時我還在組内做過一個分享，有興趣的可以去圍觀一下 Best Workflow With Grunt

其實這些工具出現的原因是：當時前端領域的各種基礎設施很缺乏，而前端的工作内容又相對零散。工作時需要開很多的軟體。再加上 JavaScript 語言本身也很弱，就連包管理這種基礎的東西也沒有内置，以至于子產品化要通過一些第三方類庫來實作，比如：RequireJS, SesJS

工具的重要性可以在我之前的一個分享中找到 前端開發工具系列

現狀

如今前端工程的生态環境由于 NodeJS 的出現已經變得很好了。你可以根據自己的需求選一個合适的直接用到項目裡面。像 Grunt, Gulp, browserify, webpack 等。不過要明白這些工具的出現從另一方面證明了前端開發天生存在很多的問題：

  • HTML 從誕生到 HTML 5 之前幾乎沒有任何變化，DOM 性能天生缺失。是以才有了 Virtual DOM 這種東西
  • CSS 隻是一門描述型的語言，沒有變量、邏輯控制、語句。是以才出現了 Sass, Less 這種預編譯工具
  • JavaScript 号稱「高階的（high-level）、動态的（dynamic）、弱類型的（untyped）解釋型（interpreted）程式設計語言，适合面向對象（oop）和函數式的（functional）程式設計風格」的程式設計語言，但是語言本身有很多問題（ES 6 之前）。不适合大型項目的開發、沒有一些進階特性的支援、同時被其它語言诟病的 callback 風格、單線程執行等。是以才出現了像 TypeScript, Babel 這種編譯成 JavaScript 代碼的語言

這些問題幾乎都是曆史性的原因和相容性因素造成的。作為一名好的前端工程師要看清楚現狀，然後按自己項目的需求去定制一些前端工程化的方案，而不是随波逐流。

選擇

其實作在自己開發一套前端工程化/自動化流程的成本已經很低了，你隻需要學習一些 NodeJS 的知識，配合 NPM 包管理機制，随手就搞出一個建構工具出來。因為并不需要你去實作什麼東西，所有的東西都有現成的包。腳本壓縮有 UglifyJS，CSS 優化有 CSS-min，圖檔壓縮優化有 PNG-quant 等等。你隻需要想清楚自己要達到什麼目的，解決什麼問題就可以抄家夥自己寫一套工作流出來

我自己的經曆也從 Grunt, GulpJS 到現在自造輪子。自己根據需求開發出來一套內建的打包工具，有興趣的可以去圍觀一下 Wooo

當然你也可以不用任何打包工具，自己寫一些 NPM Script 來完全定制化項目開發/測試/打包流程。我猜這也是為什麼現在類似 Grunt 不再那麼火，Gulp 遲遲沒有釋出 4.0 版本的原因。寫一個建構工具的成本太低了，而且這種內建的工具很難滿足差異的開發需求。君不知已有人意識到了這一點麼why-i-left-gulp-and-grunt-for-npm-scripts

程式、設計、産品

我始終認為程式、設計是為了産品服務的。好的産品是要重視設計的，好的（前端）工程師是要有一些審美素養

其實很多時候技術解決方案都是要根據産品的定位來設計的，了解産品需求以後才能定制出真正合适的高效的解決方案。好比前面講到的那個 sprite 案例，如果一開始就和産品讨論好方案後來也不可能有那種失控的情況發生。在産品形成/上線前期能發現問題比上線後發現問題更容易解決

這部分内容和代碼無關，就不多說了。然而早年我還有一次分享關于前端、改變

總結

關于單品頁的前端開發本篇文章隻是冰山一角，還有很多沒有提及，每個小東西都可以單獨寫一篇文章來分享。随後希望可以有更多的總結和分享

上一篇: [轉]我腦海中的優秀技術團隊我腦海中的優秀技術團隊
下一篇: 安卓架構搭建(一)基本配置