这个题目是zlx出给我们的题目，但是如果仅仅当作题目来做我觉得没有多大的意义。这个问题很大，目前阶段个人理解也很粗浅，只是简单做一个归纳，当作最近所学的总结。
上次winter来鞋厂分享之后我也想了不少，虽然目前自己远远达不到这样的高度，但是思考应该是没有问题的。团队协作的问题要从至少两个角度去考虑：
- 代码问题
- 工程问题
工程问题看似和代码问题平行，其实两者相辅相成。
既然已经讨论团队合作的范畴，那么我们假定这个项目已经比较庞大并且适合用工程的问题去解决它。
代码问题
代码规范
首先，团队合作的代码需要规范，这是首要的。代码规范是保证团队合作里别人能方便得看懂你的代码的前提。
我认为代码规范没有好坏之说，只有合理性和习惯性上的区别。
有一些规范也许时人们的习惯，没有什么道理，可能也是我不知道。但大部分规范是有意义的。例如以前我不知道
body {
//选择符后有空格
}
body{
//选择符后无空格
}
之间的区别，后来小志告诉我说是因为:first-letter和:first-line中间的横线在ie6下会因为没有空格出问题，我还没有自己去求证这个问题，但是我从中意识到大部分规范是有道理的。
例如Bootstrap的编码规范：http://codeguide.bootcss.com/
好的编码规范增加了可读性和可维护性，不管自己和别人读起来都会比较爽。
所以在我看来团队协作的话非常需要统一的编码规范。
当然有的人觉得我本来的写法就很好，我不想改变，但是这是团队的事情不是一个人的事情。
HTML结构
HTML结构方面离不开几个话题，标签的语义化，标签的选择，类名怎么取，单类还是多类，结构如何嵌套合理。
我把团队合作密切相关的几个重点讨论一下。
- 标签的选择
- 模块化
- 可扩展性
- 未来
标签的选择
标签选择上的问题我觉得见仁见智，例如之前从zlx那里学到的导航的写法。
之前导航的结构一直是nav>ul>li>a这样的。但是其实直接div>a或者nav>a也可以。没有必要非要用ul>li。
两种方式表现上是一样的，但是为什么主流网站都用了ul>li？我认为一个规范，一个是语义化。而且在团队合作层面，可能队友一看到这个结构就能知道它是导航，但是div>a会让人愣一下，虽然可能会给class="nav"之类的，但好像一个导航对应一个列表这样的方式已经给人留下了很深的印象，一种习惯。
<nav>
<ul>
<li><a href="#">
<li><a href="#">
<li><a href="#">
</ul>
</nav>
和
<nav>
<a href="#">
<a href="#">
<a href="#">
</nav>
都是可以的。
这个方面我觉得不必要吹毛求疵，还是结合需要来选择。
我觉得衡量标签选择的几个标准：
- 语义化
- 结构清晰
模块化
类名怎么取，单类还是多类，标签的语义化，结构如何嵌套其实是结合在一起的，最终目前的最好的解决方案可能是模块化。随着Web Component概念的普及，我觉得Web模块是一个必然的事情。因为目前前端的语言相对年轻，可能走的路是其他一些传统语言的老路。例如之前的OOCSS，面向对象的CSS。模块化也是其他一些例如python之类的所运用的。模块化的好处在于能够将大段的代码复用，避免重复造轮子。之前跟大漠简单聊了一下，发现这个如果结合前端工程的问题可以变的很厉害。这个之后再说。模块化就涉及了类名的取名，目前常用的3种CSS设计模式BEM,OOCSS,SMACSS。
BEM主要是命名技巧，简单来说就是模块名--元素名__状态。
OOCSS没有怎么看。
主要看了SMACSS,它主要是以元素的业务逻辑来划分类名。具体不做详细介绍。
但是我认为他们的中心思想都类似:
- 减少对HTML结构依赖，配合模块化尽量少用子元素，后代，标签选择器。有利于代码的复用。
- 增加class来提高复用性，降低标签耦合度。
第二点就涉及到了单类和多类的问题。例如
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规则但是扩展的时候要更加灵活。
我认为单类和多类围绕的核心问题是基于状态的变化。一般都是一个默认态，通过多类来赋予不同的状态。
还有HTML结构嵌套的问题，我认为尽量避免很深的嵌套，对于CSS选择器也是，等维护的时候会比较困难。
其实我认为有时候过分追求这里少一层嵌套或者少一个标签意义并不是很大，需要做的是减少没有意义的标签和过深的嵌套。
可扩展性
可扩展性其实取决于模块化的程度。还有其他一些因素，比如之前练习里给一些状态把:before和after都用了，那么你以后想加其他的状态可能没那么方便。
未来
前端的整体结构我认为会往MVC的模式去靠，目前的Angular.js,React.js等，都是基于MVC、MVVM之类。前端可以做一些后端的事情，后端只要负责业务和数据处理。
基于Node前端可以发生好多的变化，前端可以变的无比简介，比如Jade模版之类。
工程问题
其实我认为团队化更多的在工程问题上，主要讨论一下我目前想到的几点：
Code Review
前端普遍没有code review我认为这是有危险的，代码质量无法保证，整个平台没有统一的代码，不利于今后的扩展和维护，很可能原来写代码的这个人走了，那么其他的人要花很大时间和精力去看他的代码才能维护。
模块测试
团队合作的过程当中可能每个人负责一个模块，那么对于独立模块的测试就很重要。每个模块的质量决定了总体的质量。目前好像对于前端代码的测试都是交给开发去做，有问题再反馈。我觉得这是前端自己的问题，除了逻辑上的问题可能自己看不出来，一些表现上和兼容性的问题还是应该自己去解决的。不能完全依赖测试。目前的前端自己的测试仅仅限于极限情况的考虑和跨浏览器兼容性下的表现。我觉得远远不够。
前端自动化
现在很多项目开始时都是在重复造轮子，其实这样很浪费时间。不管是Gulp还是Grunt宗旨都是用代码来进行自动化的工作流。比如文件的建立，模块的引用，代码的压缩，Sprite合图。这样的工作流结合响应式，模块化和Sass之类的CSS预编译语言，可以很大的提高开发效率。
网友评论