這個題目是zlx出給我們的題目钦幔，但是如果僅僅當(dāng)作題目來做我覺得沒有多大的意義窃诉。這個問題很大豆胸，目前階段個人理解也很粗淺奥洼，只是簡單做一個歸納，當(dāng)作最近所學(xué)的總結(jié)配乱。
上次winter來鞋廠分享之后我也想了不少溉卓，雖然目前自己遠遠達不到這樣的高度皮迟，但是思考應(yīng)該是沒有問題的。團隊協(xié)作的問題要從至少兩個角度去考慮：
- 代碼問題
- 工程問題
工程問題看似和代碼問題平行桑寨，其實兩者相輔相成伏尼。
既然已經(jīng)討論團隊合作的范疇，那么我們假定這個項目已經(jīng)比較龐大并且適合用工程的問題去解決它尉尾。
代碼問題
代碼規(guī)范
首先爆阶，團隊合作的代碼需要規(guī)范，這是首要的沙咏。代碼規(guī)范是保證團隊合作里別人能方便得看懂你的代碼的前提辨图。
我認為代碼規(guī)范沒有好壞之說，只有合理性和習(xí)慣性上的區(qū)別肢藐。
有一些規(guī)范也許時人們的習(xí)慣俊戳，沒有什么道理，可能也是我不知道棱烂。但大部分規(guī)范是有意義的占遥。例如以前我不知道
body {
//選擇符后有空格
}
body{
//選擇符后無空格
}
之間的區(qū)別，后來小志告訴我說是因為:first-letter和:first-line中間的橫線在ie6下會因為沒有空格出問題痘煤，我還沒有自己去求證這個問題凑阶，但是我從中意識到大部分規(guī)范是有道理的。
例如Bootstrap的編碼規(guī)范：http://codeguide.bootcss.com/
好的編碼規(guī)范增加了可讀性和可維護性衷快，不管自己和別人讀起來都會比較爽宙橱。
所以在我看來團隊協(xié)作的話非常需要統(tǒng)一的編碼規(guī)范。
當(dāng)然有的人覺得我本來的寫法就很好蘸拔，我不想改變师郑，但是這是團隊的事情不是一個人的事情。
HTML結(jié)構(gòu)
HTML結(jié)構(gòu)方面離不開幾個話題都伪，標(biāo)簽的語義化呕乎，標(biāo)簽的選擇，類名怎么取陨晶，單類還是多類猬仁，結(jié)構(gòu)如何嵌套合理。
我把團隊合作密切相關(guān)的幾個重點討論一下先誉。
- 標(biāo)簽的選擇
- 模塊化
- 可擴展性
- 未來
標(biāo)簽的選擇
標(biāo)簽選擇上的問題我覺得見仁見智湿刽，例如之前從zlx那里學(xué)到的導(dǎo)航的寫法。
之前導(dǎo)航的結(jié)構(gòu)一直是nav>ul>li>a這樣的褐耳。但是其實直接div>a或者nav>a也可以诈闺。沒有必要非要用ul>li。
兩種方式表現(xiàn)上是一樣的铃芦，但是為什么主流網(wǎng)站都用了ul>li雅镊？我認為一個規(guī)范襟雷，一個是語義化。而且在團隊合作層面仁烹，可能隊友一看到這個結(jié)構(gòu)就能知道它是導(dǎo)航耸弄，但是div>a會讓人愣一下，雖然可能會給class="nav"之類的卓缰，但好像一個導(dǎo)航對應(yīng)一個列表這樣的方式已經(jīng)給人留下了很深的印象计呈，一種習(xí)慣。
<nav>
<ul>
<li><a href="#">
<li><a href="#">
<li><a href="#">
</ul>
</nav>
和
<nav>
<a href="#">
<a href="#">
<a href="#">
</nav>
都是可以的征唬。
這個方面我覺得不必要吹毛求疵捌显，還是結(jié)合需要來選擇。
我覺得衡量標(biāo)簽選擇的幾個標(biāo)準(zhǔn)：
- 語義化
- 結(jié)構(gòu)清晰
模塊化
類名怎么取总寒，單類還是多類扶歪，標(biāo)簽的語義化，結(jié)構(gòu)如何嵌套其實是結(jié)合在一起的摄闸，最終目前的最好的解決方案可能是模塊化击罪。隨著Web Component概念的普及，我覺得Web模塊是一個必然的事情贪薪。因為目前前端的語言相對年輕，可能走的路是其他一些傳統(tǒng)語言的老路眠副。例如之前的OOCSS画切，面向?qū)ο蟮腃SS。模塊化也是其他一些例如python之類的所運用的囱怕。模塊化的好處在于能夠?qū)⒋蠖蔚拇a復(fù)用霍弹，避免重復(fù)造輪子。之前跟大漠簡單聊了一下娃弓，發(fā)現(xiàn)這個如果結(jié)合前端工程的問題可以變的很厲害典格。這個之后再說。模塊化就涉及了類名的取名台丛，目前常用的3種CSS設(shè)計模式BEM,OOCSS,SMACSS耍缴。
BEM主要是命名技巧，簡單來說就是模塊名--元素名__狀態(tài)挽霉。
OOCSS沒有怎么看防嗡。
主要看了SMACSS,它主要是以元素的業(yè)務(wù)邏輯來劃分類名。具體不做詳細介紹侠坎。
但是我認為他們的中心思想都類似:
- 減少對HTML結(jié)構(gòu)依賴蚁趁，配合模塊化盡量少用子元素，后代实胸，標(biāo)簽選擇器他嫡。有利于代碼的復(fù)用番官。
- 增加class來提高復(fù)用性，降低標(biāo)簽耦合度钢属。
第二點就涉及到了單類和多類的問題徘熔。例如
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ī)則但是擴展的時候要更加靈活。
我認為單類和多類圍繞的核心問題是基于狀態(tài)的變化署咽。一般都是一個默認態(tài)近顷，通過多類來賦予不同的狀態(tài)。
還有HTML結(jié)構(gòu)嵌套的問題宁否，我認為盡量避免很深的嵌套窒升，對于CSS選擇器也是，等維護的時候會比較困難慕匠。
其實我認為有時候過分追求這里少一層嵌套或者少一個標(biāo)簽意義并不是很大饱须，需要做的是減少沒有意義的標(biāo)簽和過深的嵌套。
可擴展性
可擴展性其實取決于模塊化的程度台谊。還有其他一些因素蓉媳，比如之前練習(xí)里給一些狀態(tài)把:before和after都用了，那么你以后想加其他的狀態(tài)可能沒那么方便锅铅。
未來
前端的整體結(jié)構(gòu)我認為會往MVC的模式去靠酪呻，目前的Angular.js,React.js等，都是基于MVC盐须、MVVM之類玩荠。前端可以做一些后端的事情，后端只要負責(zé)業(yè)務(wù)和數(shù)據(jù)處理贼邓。
基于Node前端可以發(fā)生好多的變化阶冈，前端可以變的無比簡介，比如Jade模版之類塑径。
工程問題
其實我認為團隊化更多的在工程問題上女坑，主要討論一下我目前想到的幾點：
Code Review
前端普遍沒有code review我認為這是有危險的，代碼質(zhì)量無法保證统舀，整個平臺沒有統(tǒng)一的代碼匆骗，不利于今后的擴展和維護，很可能原來寫代碼的這個人走了誉简，那么其他的人要花很大時間和精力去看他的代碼才能維護绰筛。
模塊測試
團隊合作的過程當(dāng)中可能每個人負責(zé)一個模塊，那么對于獨立模塊的測試就很重要描融。每個模塊的質(zhì)量決定了總體的質(zhì)量铝噩。目前好像對于前端代碼的測試都是交給開發(fā)去做，有問題再反饋。我覺得這是前端自己的問題骏庸，除了邏輯上的問題可能自己看不出來毛甲，一些表現(xiàn)上和兼容性的問題還是應(yīng)該自己去解決的。不能完全依賴測試具被。目前的前端自己的測試僅僅限于極限情況的考慮和跨瀏覽器兼容性下的表現(xiàn)玻募。我覺得遠遠不夠。
前端自動化
現(xiàn)在很多項目開始時都是在重復(fù)造輪子一姿，其實這樣很浪費時間七咧。不管是Gulp還是Grunt宗旨都是用代碼來進行自動化的工作流。比如文件的建立叮叹，模塊的引用艾栋，代碼的壓縮，Sprite合圖蛉顽。這樣的工作流結(jié)合響應(yīng)式蝗砾，模塊化和Sass之類的CSS預(yù)編譯語言，可以很大的提高開發(fā)效率携冤。
