摘要：概述前段時間剛剛完成公司觸屏版項目，我覺得很有必要寫一篇文章總結下自己的心得和踩過的坑。小結個人覺得整個開發流程就是一體的，沒有絕對的前后端分離。細數下開發過程中遇到的坑。最近在看模板，貌似很吊的樣子總結學習就是不斷踩坑的過程啊

前段時間剛剛完成公司觸屏版項目，我覺得很有必要寫一篇文章總結下自己的心得和踩過的坑。每次回頭看看自己寫的代碼，都有不一樣的體會，不過大致感覺都是驚人的相似：這TM寫的是啥？這TM寫的又是啥？

Java+Node。嘗試了前后端分離，Java端負責業務邏輯處理，提供接口。Node端負責頁面渲染、SEO等balabala一堆非業務邏輯，兩者通過HTTP接口交互。前后端分離確實帶來了好處：

分工明確，不會出現占著茅坑不拉粑粑的情況，一人一個坑蹲著

職能清晰，設計寫SASS，前端寫JavaScript，后端寫Java

提高了代碼的復用性，Java端的接口可供多個應用調用

前后端分離只有好處? No! 多了Node，實際上多了層請求，這個過程是需要花費時間的，不過這點性能的損耗同提高維護性來比是微不足道的，咋不糾結這個！真正來說，前后端的過度分離讓每個人只關注自己的任務，等到聯調的時候會發現出現很多問題，舉個幾個簡單的例子：

一般都是設計跟據視覺稿先編碼，做好HTML頁面，然后丟給我們前端開發。我套頁面的時候，發現有個幻燈片效果，然后去找了個插件xxx.js，大部分的幻燈片插件對HTML結構都是有要求的（你懂的），所以我只好找到設計，讓他重新寫下這部分結構，設計欣然接收，改了！做著做著又發現某個div的需要fixed布局，又得找設計改SASS，某個div需要添加 overflow:hidden,還是得找設計改，如此反復，設計心里肯定會默念：我去年買了個表！說到這里我不得不說一點了，作為一個合格的設計，在編寫HTML時，要根據交互效果編寫CSS代碼，站在套頁面人的角度去編碼。也需要將CSS模塊化，便于維護啊！當然了，作為一個合格的JSer，也要善于同設計交流，提前溝通，避免出現上述的情況。不溝通的結果就是這樣的：

    



$("#btn").click(function(){
    $(".someDiv").css({overfolw : "hidden"}).show();
});

來來來，放學別走！

交互說，點擊這里，我需要duang的效果，點擊那里我需要duang duang的效果，點那那里，我需要duang duang duang的效果。我一看，希望用盡量少的代碼實現，同交互交流希望統一UI，保留一種效果就可以了，交互堅持！交互堅持，交涉無果，不得不多寫額外的代碼，然并卵！下次需求，又換交互效果！

不同的列表頁，有著相同的HTML結構，本次相同代碼不寫兩遍的原則，抽出了結構：

     {{comName}}
    //...

但是后端返回的數據結構一處叫comName，一處叫companyName。問后端，他說數據庫就是這樣設計的。

個人覺得整個開發流程就是一體的，沒有絕對的前后端分離。產品、交互、設計、JSer、后端、庫表設計都會對我們的代碼產生影響。及時溝通是一方面。處了自己的本職外，也需要了解他人的工作，當你對整個流程都特別熟悉，那就是所謂的架構師了。還在前端摸爬滾打的我，還差得遠啊。

Zepto是一個輕量級的針對現代高級瀏覽器的JavaScript庫， 它與jquery有著類似的api。選擇Zepto是因為它輕量高效，并且封裝好了移動端的touch事件。細數下開發過程中遇到的坑。

直接從官網上下載了Zepto，馬上編碼

$("#btn").on("tap",function(){
    //todo
});

發現壓根不起作用，再到官網上看下，我就呵呵了

看黃色部分，默認只添加了Effects、iOS3和Detect這三個模塊，最最重要的Touch模塊居然沒有！所以大家要下載Zepto還得自己定制模塊
Zepto Builder
附上模塊說明：

總所周知，默認click事件，會有300ms的延時問題，Zepto的tap事件很好的解決了這個問題。但是也挖了一個大坑。

Zepto的點透應該也是大家比較熟悉的了。當兩個層疊加的時候，上層綁定的tap事件觸發后會穿透到底層，恰好底層有個a標簽，頁面就跳轉了。為了解決這個問題，我不得不把tap事件換成click事件，由于click事件有延時，還得引入了第三方的類庫FastClick。

一個很簡單的Tip提示，例如‘操作成功’、‘登錄失敗’等等簡單的提示，Tip在show之前，我會計算讓Tip居中顯示：

var left = ($(window).width() - $pop.width()) / 2 + $(window).scrollLeft();

然而$pop.width()始終為0，對于不可見元素，獲取的寬高度始終為0，但是jQuery就能正常獲取到，我又不得不采取如下的處理方式：

var cssShow = {visibility: "hidden", display: "block"};
var cssHide = {visibility: "visible", display: "none"};

$pop.css(cssShow);
var left = ($(window).width() - $pop.width()) / 2 + $(window).scrollLeft();
$pop.css(cssHide);

 $pop.css({
     left: left > 0 ? left : 0
 });

Zepto相對于JQuery來說確實比較輕量，但是成熟度還差得遠，當出現點透和計算寬高失效的時候，我對Zepto有點灰心，希望Zepto后續能夠及時升級解決這些問題，不然就使用jQuery了，特別是jQuery升級到版本2，也是相當不錯的選擇。

當頁面彈出一個選擇框。滑動屏幕，背后的頁面跟著滾動，特別是在safari下，那效果太惡心，所以我選擇禁用body的滾動。最暴力的解決方式是：

$(document).on("touchmove",function(e){
    e.preventDefault();
});

這樣會同時禁用掉彈出層的滾動效果，明顯不可取，所以我才用下面的方式：

.alpha {
    height: 100%;
    overflow: hidden;
    position: relative;
}

.alpha body {
    height: 100%;
    overflow: hidden;
}

當遮蓋彈出的時候或者隱藏的時候讓html切換class alpha
$("html").toggleClass("alpha");

對于PC端，直接這樣寫，就會有一個向上平滑滾動的效果，然而對于移動端來說，并沒有什么卵用：

$("body,html").animate({scrollTop: 0});

還是使用了第三方的插件模式出這個效果的scrollToTop。

前后端分離后，Node端要干的事情太多了，URL重寫這個模塊是我一個前輩寫的，配置放在JSON文件里，就像這樣：

{
    "product.detail": {
        "in": {
            "from": "^/chanpin/(.+).html$",
            "to": "/product/$1",
            "last": true
        },
        "out": {
            "from": "^/product/(.+)$",
            "to": "/chanpin/$1.html",
            "last": true
        }
    },    
    "special": {
        "in": {
            "from": "^/special/(.+).html$",
            "to": "/special/$1",
            "last": true
        },
        "out": {
            "from": "^/special/(.+)$",
            "to": "/special/$1.html",
            "last": true
        }
    }
}

就是這貨：

我同樣采用JSON文件管理所有頁面的推廣代碼，就像這樣：

{  
  "catalog": {
    "title": "產品目錄–$1",
    "keywords": "產品目錄,$1",
    "description": "$1，產品目錄。"
  }, 
  "search.product": {
    "title": "產品搜索–$1",
    "keywords": "產品搜索,$1",
    "description": "$1，產品搜索。"
  }  
}

自己編寫了個模塊，可以指定某個文件下的js文件作為路由，路由代碼寫起來就像這樣的：

module.exports = {
    mapping: "/vo",
    get: {       
        /**
         * 登錄
         */
        "/login": function (req, res) {
            res.render("vo/login");
        },
        /**
         * 注冊
         */
        "/register": function (req, res) {
            res.render("vo/register");
        }            
    },
    post: {
        /**
         * 登錄
         */
        "/login": function (req, res) {
            //todo
        },
        /**
         * 注冊
         */
        "/register": function (req, res) {
           //todo
        }        
    }
};

詳細使用請看這里Express-Mapping

模板引擎使用的Handlebars。Handlebars的if判斷不支持type==="2"這種邏輯判斷的，然而我們的數據庫里有很多字段是使用數字1,2,3,4來標識不同狀態的，碰到這種情況就得在Node端預先處理，這個是很坑爹的！碰到列表展示的嵌套循環更是坑爹了。有時候還得寫這種代碼：

{{#if a}}
    {{#if b}}
        {{#if c}}
            //todo
        {{/if}}
    {{/if}}
{{/if}}

真實的業務場景更是復雜，額外的處理代碼總是會帶來維護的負擔。最近在看nunjucks模板，貌似很吊的樣子！

學習就是不斷踩坑的過程啊！