欲精一行，必先通十行

将前端开发和服务器开发来做一个比较，前端开发没有服务器开发“深”，服务端开发没有前端开发“广”。所以经常有前端开发工程师会抱怨学的东西太多，东学一点，西学一点，什么都会但是都不精。直接的结果就是沦为打杂程序员，对能力没有自信，在团队中说话没有分量。于是可能会得出这样的结论：“通十行不如精一行”。

其实这是一个误区。精通一行？在前端开发领域，不通十行就无法精一行。

先来说说“精一行”这个概念吧。具体细化到什么程度叫做“一行”？是具体到前端/服务器端，还是具体到设计/div+css/javascript？细化的粒度越小，需要掌握的东西就越少。很多工程师为了能够快速“精一行”，自己就尽量将“一行”的粒度细化。可是有两个问题：

  • 精的粒度越小，我们的业务范围就越小。显而易见，如果你精通的范围越小，你的实用价值就越小
  • 互联网是互相渗透的，界限非常不明显。

现在，分工非常明细的岗位是不存在的，所以我们需要选择“粗粒度”的精，也就是说，不必精十行，至少要通十行。专精很难，设置不可能，一专多能才是现实的。这一点，在前端领域里显得更加必要。

增加代码可读性-添加注释

在开发过程中，可能需要多人协作。大体来说，可以分为两种：

  1. 事前商量好，有组织有计划的分工合作，我们称为“直接团队合作”
  2. 事先没有考虑，因为种种原因而导致你需要去维护他人开发过的代码，我们称为“间接团队合作”

不要断定你现在编写的代码，将来一定不会有人来维护。哪怕是你自己写的代码，3个月之后再来看它，一样会觉得十分陌生。

无论是“直接团队合作”还是“间接团队合作”，一个保证代码可读性良好的绝佳武器就是注释。关于注释甚至有一种说法“一个好的代码，注释要占到1/3”。虽然有些夸张了，但是它表明了注释的重要性。

提高重用行-公共组件和私有组件的维护

团队合作很容易产生的问题之一就是冗余。如果没有事先做好规划，很容易出现这样的情况：工程师1在A页面上为了实现某种效果写了一段代码，工程师2在B页面上遇到同样的问题又重写了一遍。如果系统升级，这个效果需要改变，那么工程师1和工程师2都需要更改这部分代码，这明显是一种资源浪费。

避免出现这种冗余的最好办法就是根据代码的重用性，把它们分成公共组件和私有组件两类。设计组件的时候考虑让借口保持弹性，并且高度模块化，这是很考验能力和经验的工作。

公共组件设计之初就是考虑要被多人重复使用的，如果公共组件被修改会造成很大的影响！所以不允许轻易的修改公共组件。一般来说，公共组件需要专人来维护。公共组件需要做好注释，必要时甚至需要提供规范的API文档和演示Demo。

私有组件因为不需要考虑他人重用的问题，所以对于修改操作会自由的多。但不要忘记，虽然你的私有组件不会被他人重用，但仍然可能会被他人维护，所以必要的注释还是需要的。

冗余和精简的矛盾-选择集中还是选择分散

有了公共组件和私有组件的区分，可以有效的避免代码冗余。但是又带来了新的问题：如何组织公共组件。

一般来说，前端结构中CSS和Javascript都是会提取公共组件的，如何组织公共组件是需要我们权衡的。如果没有将公共组件载入系统，那么组件是无法被使用的。

  • 一个最方便的做法就是将公共组件全部打包好，然后一次性全部载入，这样可以保证所有的组件都是可用的。这种做法的好处就是加载方便，但是加载的代码量过大，而很多代码是没有被用到的。
  • 另一种做法就是将代码精确划分到一小块一小块，然后按需加载相应的模块。这种做法的好处是加载灵活，保证代码的加载量小，但坏处是使用起来比较麻烦。

我们需要认识到完美的解决方案是不存在的，我们只能在冗余和精简中尽量找到最佳的平衡点。我更偏向于按需加载的方式，因为这样的方式扩展性更好。

磨刀不误砍柴工-前期的构思很重要

很多工程师容易犯的一个错误就是，拿到一个任务之后就马上开始写代码，其实这不是一个好习惯。

对于简单的页面而言，这么做还不会有太大的麻烦。但是，对于一个中大型的网站而言，如果在还没有考虑成熟的前端框架前就开始动手写代码是会带来非常多的问题的，比如代码的冗余、多人合作容易冲突、代码组织没有规律等。

犯这种错的原因主要是因为两个方面：

  1. 本身经验不足
  2. 可能是客户或者boss给的压力很大，拼命赶工期。

如果是后者，我们一定要顶住压力，客户和boss可能希望尽快的看到效果。如果没有一个成熟的框架就开始写代码，很可能会出现先快后慢的局面，越到后期开发的速度越慢，反复修改bug、打补丁，系统的开发和维护成本越来越大。如果一开始不急于马上进行开发，而是先根据用户需求进行分析，先考虑好框架，会让整个开发过程更有规划、更流畅，是一个先慢后快的过程。

一个项目，前期的构思主要包括：规范制定、公共组件的设计和复杂功能的技术方案等。一般来说，前期构思占整个项目的 30%~60% 的时间都算是正常的。

制定规范

规范对于团队合作是最重要的。它能有效指导团队成员按照一个统一的标准进行开发，提高效率并保证软件的质量。规范没有同一的标准和准则，主观性很强，我们可以借鉴一些比较成熟和应用广泛的规范来制定适合自己项目的规范。

团队合作的最大难度不是技术，是人

团队合作的最大难度不是技术，是人。

只要有一定经验，构思良好，有完善的规范，尽管最终的代码有好有坏，但是团队合作在技术上并不太可能出现大的问题。但是，每个工程师的说话方式、生活习惯、性格特点都是存在差异的，所以面对问题的时候，大家的态度也不一样，有的人比较容易接受他人的观点，有的人可能固执己见。如果处理的不好，可能产生火药味，让大家带着情绪工作，影响开发进度。

工程师往往喜欢和非黑即白的代码相处，不善于处理人际关系。学会与人相处也是工程师的必修课。它的重要性甚至超过的技术本身。