团队合作

团队合作

需要关注以下几个点：

• 增加代码可读性 —注释

• 提高重用性 —公共组件和私有组件的维护

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

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

• 制订规范

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

---

增加代码可读性 —注释

　　我们在开发过程中，大部分都是需要多人来合作开发的。大体来说，可以分为两种情况：
　　一种是事先商量好，有组织有计划的分工合作，我们称其为“直接团队合作”好了；
　　另一种是事先并没有考虑到的，因为种种原因需要你去维护他人开发过的系统，我们称之为“间接团队合作”。
　　不要断定你现在编写的代码，将来一定不会有其它人来维护，“间接团队合作”常常是出乎意料的！就算你十分确定这代码只可能由你自己来维护，也一定要做好“间接团队合作”的准备，因为哪怕是你自己写的代码，时间一久你再来看它，一样会觉得它十分的陌生！
　　无论是“直接团队合作”还是“间接团队合作”，一个保证代码可读性良好的绝佳武器就是注释。关于注释一个好的说法：“一个好的代码，注释要占1/3的篇幅”。虽然是有些夸张了点，不过它表明了注释的重要性。

提高代码的重用性 —–公共组件和私有组件的维护

　　团队合作很容易产生的问题之上就是冗余。如果没有事先先做好规范，很容易出现这样一种情况：工程师甲在A页面上为了实现某种效果写了一段代码，工程师乙在B页面上遇到同样的问题时又重写了一遍。如果系统升级，这个效果需要改变，那么工程师甲和工程师乙都需要更改这部分代码，明显是一种资源浪费。
　　避免出现这种冗余的最好办法是根据代码的重用度，把它们分成公共组件及私有组件两类。设计公共组件时需要考虑让接口具有弹性，并且高度模块化，这是很考验能力和经验的工作。
　因为公共组件在设计之初就是考虑要被很多人很多次的重复使用的，如果公共组件一旦被修改会造成很大的影响！所以我们需要对公共组件的稳定性保持高度警惕，不允许轻易做修改。一般来说，公共组件对于绝大部分人来说只具有“读”的权限，不允许他们进行修改，只对少数公共组件的维护者提供“写”的权限。关于“读”和“写”的权限问题，可以通过相关软件来控制，例如SVN，也可以通过“规范”等形式对团队成员进行约定。
　一般来说公共组件需要由专人进行维护。负责维护公共组件的工程师需要将公共组件做好注释，必要时甚至需要提供规范API文档和演示Demo,其他工程师在工作中如果遇到需要高度重用的模块，而公共组件中尚未提供，可以向维护公共组件的工程师提交需求，由他来添加相应的公共组件。
　私有组件因为不考虑其他人的重用的问题，所以对于修改操作会自由的多。但不要忘了，虽然你的私有组件不会被别人重用，但仍然可能会被他人修改，所以必要的注释还是需要的。

冗余和精间的矛盾 —选择集中还是选择分散

　　有了公共组件和私有组件的区分，可以有效的避免代码的重复。但又会带来新的问题 ——如何组件公共组件
　　一般来说，合理的前端架构中CSS和Javascript都是会提取公共组件的，如何组件公共组件是需要权衡的。如果没有将公共组件载入系统中，那么组件是没法被使用的。一个最好的办法是将公共组件全部打包好，然后一次性全部载入，这样可以保证所有的组件都是可用的。这样的好处是方便加载，但加载的代码量可能过大，而很多代码事实上是没有被使用到的。另一种方法是将代码精确划分一小块一小块，然后按需加载相应的模块。这种做法的好处是灵活，保证代码的加载量小，但坏处是用起来比较麻烦。
　　我们在组织公共组件时，组织的粒度越大，文件越集中，加载和管理越方便，但无用代码越多；组织的粒度越小，文件越分散，加载和管理越麻烦，但无用代码越少。我们要加载方便就要适当舍弃精简性，要保证精简性就要适当放弃加载的方便。我们需要认识到一点，完美的解决方案是不存在的，我们只能在冗余和精间中尽量找到最佳的平衡点。

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

　　很多同行容易犯一个错误，就是拿到一个任务后就马上开始写代码，其实这并不是一个好习惯。
　　对于简单的独立的页面而言，这么做不会有太大的麻烦。但是，对于一个中大型的项目来说，如果在还没有一个考虑成熟的前端框架前就开始动手写代码会带来非常多问题的，比如代码冗余、多人合作容易冲突、代码组件没有规率等。
　　犯这种错误往往只有两个方面的原因：一方面可能是工程师本身经验不足；另一方面可能是客户和Boss给的压力很大；拼命赶工期。如果是后者，我们一定要顶住压力，客户和BOSS往往可能不了解技术，它们可能更希望尽快看到工作成果。如果在没有一个成熟的框架前就开始写代码，很可能会出现先快后慢的局面，越到后期开发速度越慢，反复修改bug、打补丁，系统的开发和维护成本越来越大。如果一开始不急于马上进行开发，而是先根据用户需求进行分析，先考虑好框架，会让整个开发过程更有规范，更流畅，是一个先慢后快的过程。
　　前期的构思非常重要。具体来说，构思的内容主要包括制定的规范、公共组件的设计和复杂功能的技术方案等。一般来说，前期构思占整个项目的30%到60%的时间都算是正常的。要知道磨刀不误砍柴工！

制定规范

　　规范对于团队合作来说是最重要的。它能有效的指导团队成员按照一个统一的标准进行开发，尽量让开发过程平滑，减少不必要的冲突，提高开发效率并保证软件的质量。
　　规范会随着制定者的风格而不同，没有一个统一的标准和准则，主观性非常强。因为规范的好坏会直接影响到整个开发过程，所以它通常是由团队中经验最丰富的人来定制的。正是由于规范的主观性强，所以不同的公司有不同的规范。

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

只要有一定经验，构思良好，有完善的规范，尽管最终代码可能有好有坏，但团队合作在技术上并不太可能出现大的困难。团队合作最大的问题还是来自于团队中成员之间的交流。不同的工程师的说话方式、工作习惯、性格特点也可能各异，工作中出现观点不同的情况在所难免。不同的工程师在处理这样的问题时表现的态度也不一样，有些比较温柔，有些则可能有些强硬，有些可能比较容易接受他人的观点，有些则可能固执己见。如果处理不好，可能会产生火药味，让大家带着情绪工作，影响开发进度。
工程师往往更专注于技术，不太善于处理人际关系。比起复杂的人，大多数工程师往往更喜欢非黑即白，非0即1，非true即false的代码相处。学会与人相处也是工程师必修的一门课，它的重要性甚至超过了技术本身。
切记，自己能独立决策的问题都是小问题，要与人合作商讨的问题可能会是最大问题，要学会与人相处。