這個(gè)題目是zlx出給我們的題目，但是如果僅僅當(dāng)作題目來(lái)做我覺(jué)得沒(méi)有多大的意義。這個(gè)問(wèn)題很大，目前階段個(gè)人理解也很粗淺，只是簡(jiǎn)單做一個(gè)歸納，當(dāng)作最近所學(xué)的總結(jié)。

上次winter來(lái)鞋廠分享之后我也想了不少，雖然目前自己遠(yuǎn)遠(yuǎn)達(dá)不到這樣的高度，但是思考應(yīng)該是沒(méi)有問(wèn)題的。團(tuán)隊(duì)協(xié)作的問(wèn)題要從至少兩個(gè)角度去考慮：

1. 代碼問(wèn)題
2. 工程問(wèn)題

工程問(wèn)題看似和代碼問(wèn)題平行，其實(shí)兩者相輔相成。

既然已經(jīng)討論團(tuán)隊(duì)合作的范疇，那么我們假定這個(gè)項(xiàng)目已經(jīng)比較龐大并且適合用工程的問(wèn)題去解決它。

代碼問(wèn)題

代碼規(guī)范

首先，團(tuán)隊(duì)合作的代碼需要規(guī)范，這是首要的。代碼規(guī)范是保證團(tuán)隊(duì)合作里別人能方便得看懂你的代碼的前提。

我認(rèn)為代碼規(guī)范沒(méi)有好壞之說(shuō)，只有合理性和習(xí)慣性上的區(qū)別。

有一些規(guī)范也許時(shí)人們的習(xí)慣，沒(méi)有什么道理，可能也是我不知道。但大部分規(guī)范是有意義的。例如以前我不知道

body {
    //選擇符后有空格
}
body{ 
    //選擇符后無(wú)空格
}

之間的區(qū)別，后來(lái)小志告訴我說(shuō)是因?yàn)?first-letter和:first-line中間的橫線在ie6下會(huì)因?yàn)闆](méi)有空格出問(wèn)題，我還沒(méi)有自己去求證這個(gè)問(wèn)題，但是我從中意識(shí)到大部分規(guī)范是有道理的。

例如Bootstrap的編碼規(guī)范：http://codeguide.bootcss.com/

好的編碼規(guī)范增加了可讀性和可維護(hù)性，不管自己和別人讀起來(lái)都會(huì)比較爽。

所以在我看來(lái)團(tuán)隊(duì)協(xié)作的話非常需要統(tǒng)一的編碼規(guī)范。

當(dāng)然有的人覺(jué)得我本來(lái)的寫(xiě)法就很好，我不想改變，但是這是團(tuán)隊(duì)的事情不是一個(gè)人的事情。

HTML結(jié)構(gòu)

HTML結(jié)構(gòu)方面離不開(kāi)幾個(gè)話題，標(biāo)簽的語(yǔ)義化，標(biāo)簽的選擇，類(lèi)名怎么取，單類(lèi)還是多類(lèi)，結(jié)構(gòu)如何嵌套合理。

我把團(tuán)隊(duì)合作密切相關(guān)的幾個(gè)重點(diǎn)討論一下。

• 標(biāo)簽的選擇
• 模塊化
• 可擴(kuò)展性
• 未來(lái)

標(biāo)簽的選擇

標(biāo)簽選擇上的問(wèn)題我覺(jué)得見(jiàn)仁見(jiàn)智，例如之前從zlx那里學(xué)到的導(dǎo)航的寫(xiě)法。

之前導(dǎo)航的結(jié)構(gòu)一直是nav>ul>li>a這樣的。但是其實(shí)直接div>a或者nav>a也可以。沒(méi)有必要非要用ul>li。

兩種方式表現(xiàn)上是一樣的，但是為什么主流網(wǎng)站都用了ul>li？我認(rèn)為一個(gè)規(guī)范，一個(gè)是語(yǔ)義化。而且在團(tuán)隊(duì)合作層面，可能隊(duì)友一看到這個(gè)結(jié)構(gòu)就能知道它是導(dǎo)航，但是div>a會(huì)讓人愣一下，雖然可能會(huì)給class="nav"之類(lèi)的，但好像一個(gè)導(dǎo)航對(duì)應(yīng)一個(gè)列表這樣的方式已經(jīng)給人留下了很深的印象，一種習(xí)慣。

<nav>
  <ul>
    <li><a href="#">
    <li><a href="#">
    <li><a href="#">
  </ul>
</nav>

和

<nav>
  <a href="#">
  <a href="#">
  <a href="#">
</nav>

都是可以的。

這個(gè)方面我覺(jué)得不必要吹毛求疵，還是結(jié)合需要來(lái)選擇。

我覺(jué)得衡量標(biāo)簽選擇的幾個(gè)標(biāo)準(zhǔn)：

• 語(yǔ)義化
• 結(jié)構(gòu)清晰

模塊化

類(lèi)名怎么取，單類(lèi)還是多類(lèi)，標(biāo)簽的語(yǔ)義化，結(jié)構(gòu)如何嵌套其實(shí)是結(jié)合在一起的，最終目前的最好的解決方案可能是模塊化。隨著Web Component概念的普及，我覺(jué)得Web模塊是一個(gè)必然的事情。因?yàn)槟壳扒岸说恼Z(yǔ)言相對(duì)年輕，可能走的路是其他一些傳統(tǒng)語(yǔ)言的老路。例如之前的OOCSS，面向?qū)ο蟮腃SS。模塊化也是其他一些例如python之類(lèi)的所運(yùn)用的。模塊化的好處在于能夠?qū)⒋蠖蔚拇a復(fù)用，避免重復(fù)造輪子。之前跟大漠簡(jiǎn)單聊了一下，發(fā)現(xiàn)這個(gè)如果結(jié)合前端工程的問(wèn)題可以變的很厲害。這個(gè)之后再說(shuō)。模塊化就涉及了類(lèi)名的取名，目前常用的3種CSS設(shè)計(jì)模式BEM,OOCSS,SMACSS。

BEM主要是命名技巧，簡(jiǎn)單來(lái)說(shuō)就是模塊名--元素名__狀態(tài)。

OOCSS沒(méi)有怎么看。

主要看了SMACSS,它主要是以元素的業(yè)務(wù)邏輯來(lái)劃分類(lèi)名。具體不做詳細(xì)介紹。

但是我認(rèn)為他們的中心思想都類(lèi)似:

1. 減少對(duì)HTML結(jié)構(gòu)依賴(lài)，配合模塊化盡量少用子元素，后代，標(biāo)簽選擇器。有利于代碼的復(fù)用。
2. 增加class來(lái)提高復(fù)用性，降低標(biāo)簽耦合度。

第二點(diǎn)就涉及到了單類(lèi)和多類(lèi)的問(wèn)題。例如
HTML:

第一種：

    <a class="button-default">
    <a class="button-primary">

第二種

    <a class="button button-default">
    <a class="button button-primary">

CSS:

第一種：

    .button-default {
        width: 50px;
        background-color: blue;
    }
    .button-primary {
        width: 50px;
        background-color: red;
    }

第二種：

    .button {
        width: 50px;
    }
    .button-default {
        background-color: blue;
    }
    .button-primary {
        background-color: red;
    }

第二種看似多了一條CSS規(guī)則但是擴(kuò)展的時(shí)候要更加靈活。

我認(rèn)為單類(lèi)和多類(lèi)圍繞的核心問(wèn)題是基于狀態(tài)的變化。一般都是一個(gè)默認(rèn)態(tài)，通過(guò)多類(lèi)來(lái)賦予不同的狀態(tài)。
還有HTML結(jié)構(gòu)嵌套的問(wèn)題，我認(rèn)為盡量避免很深的嵌套，對(duì)于CSS選擇器也是，等維護(hù)的時(shí)候會(huì)比較困難。
其實(shí)我認(rèn)為有時(shí)候過(guò)分追求這里少一層嵌套或者少一個(gè)標(biāo)簽意義并不是很大，需要做的是減少?zèng)]有意義的標(biāo)簽和過(guò)深的嵌套。

可擴(kuò)展性

可擴(kuò)展性其實(shí)取決于模塊化的程度。還有其他一些因素，比如之前練習(xí)里給一些狀態(tài)把:before和after都用了，那么你以后想加其他的狀態(tài)可能沒(méi)那么方便。

未來(lái)

前端的整體結(jié)構(gòu)我認(rèn)為會(huì)往MVC的模式去靠，目前的Angular.js,React.js等，都是基于MVC、MVVM之類(lèi)。前端可以做一些后端的事情，后端只要負(fù)責(zé)業(yè)務(wù)和數(shù)據(jù)處理。
基于Node前端可以發(fā)生好多的變化，前端可以變的無(wú)比簡(jiǎn)介，比如Jade模版之類(lèi)。

工程問(wèn)題

其實(shí)我認(rèn)為團(tuán)隊(duì)化更多的在工程問(wèn)題上，主要討論一下我目前想到的幾點(diǎn)：

Code Review

前端普遍沒(méi)有code review我認(rèn)為這是有危險(xiǎn)的，代碼質(zhì)量無(wú)法保證，整個(gè)平臺(tái)沒(méi)有統(tǒng)一的代碼，不利于今后的擴(kuò)展和維護(hù)，很可能原來(lái)寫(xiě)代碼的這個(gè)人走了，那么其他的人要花很大時(shí)間和精力去看他的代碼才能維護(hù)。

模塊測(cè)試

團(tuán)隊(duì)合作的過(guò)程當(dāng)中可能每個(gè)人負(fù)責(zé)一個(gè)模塊，那么對(duì)于獨(dú)立模塊的測(cè)試就很重要。每個(gè)模塊的質(zhì)量決定了總體的質(zhì)量。目前好像對(duì)于前端代碼的測(cè)試都是交給開(kāi)發(fā)去做，有問(wèn)題再反饋。我覺(jué)得這是前端自己的問(wèn)題，除了邏輯上的問(wèn)題可能自己看不出來(lái)，一些表現(xiàn)上和兼容性的問(wèn)題還是應(yīng)該自己去解決的。不能完全依賴(lài)測(cè)試。目前的前端自己的測(cè)試僅僅限于極限情況的考慮和跨瀏覽器兼容性下的表現(xiàn)。我覺(jué)得遠(yuǎn)遠(yuǎn)不夠。

前端自動(dòng)化

現(xiàn)在很多項(xiàng)目開(kāi)始時(shí)都是在重復(fù)造輪子，其實(shí)這樣很浪費(fèi)時(shí)間。不管是Gulp還是Grunt宗旨都是用代碼來(lái)進(jìn)行自動(dòng)化的工作流。比如文件的建立，模塊的引用，代碼的壓縮，Sprite合圖。這樣的工作流結(jié)合響應(yīng)式，模塊化和Sass之類(lèi)的CSS預(yù)編譯語(yǔ)言，可以很大的提高開(kāi)發(fā)效率。