单兵作战只能分配给自己的模块，团队协作才能让产品快速高质量上线。有正则必有负。要想提高团队合作效率，首先要分析是什么阻碍了开发进度。一般来说，项目的预估时间比较紧。如果正常的话，上线的时间也不会相隔太远。中途如有变动，会根据反馈实时调整进度。但有的时候，代码能稳定地发挥其固定的作用，人却不一定，不同的行为会导致截然不同的影响。负面影响全局干扰在最近的一个项目中，在进入测试阶段时，一些新版本功能已经通过了第一轮测试。但是代码并没有变有的时候测试突然就出一堆bug，之前的一些功能已经不能正常使用了。请注意，一旦遇到类似情况，在不更改主要功能代码的情况下，突然出现大面积的bug，对于前端来说，要么是后台挂了，要么是兼容性问题，具体手机型号或者系统版本等等。还有一种是不应该出现的错误，就是其他团队的分支代码影响整个项目。导致你的功能异常，比如css样式覆盖，js变量覆盖等操作。现在回想起来，我当时的操作是先查看函数异常的原因，发现vuex和vue-router参数parmas失败了，但是为什么莫名其妙的失败了，谷歌了好久，我也有一直怀疑人生。由于之前有过类似的协作经历，对自己的代码机制还是有一点信心的（技术熟练程度决定了排错的思路和方式），于是开始查看同事日志中记录的gitlab的日志，又找到了一段前不久提交的代码。这段代码的定义是在全局路由中做一些操作。在这里，我也犯了一个错误。看到对方写的评论了。只是当你第一次登陆xxx，然后就没有了低头看代码的功能，然后你就开始怀疑人生了。超过半小时的时候，应该想办法解决一时解决不了的问题，和同事沟通或者放松一下，换个思路等。当调查持续了一个多小时小时，我问我的同事。同事说前不久在ios上进行了一次全局操作，因为需要开发一个新的功能，所以每次在ios上切换页面，重新设置vuex和vue-router的参数parmas。在这里，不说排查问题和定位问题的能力，这里只能提醒大家，如果知道自己的代码会对大局产生影响甚至颠覆，请务必在群里声明，或者至少与您的同事口头声明。当然，尽量不要生成非全局可控的代码。没有人能保证你的代码不会影响之前的功能或者同事的模块。耦合是一种能力，声明是一种态度，也是协作Way.tips：有的团队会进行codereview，一种是提交的时候进行review，一种是提交之后进行review。不管是哪一个对代码的质量负责，比如上面提到的错误，如果进行review的话，在release中都会进行测试，这种错误是不应该出现的。团队是否没有审查流程并不重要。大多数时候，不要养成执行别人规则的习惯。你必须有自己的独立思考。我有自己的优良习惯，团队没有，但不妨碍我定期复习。上期我讲了提高效率的方法和技巧。还可以加一个，在加班或者定期review的时候，可以及时检查自己的代码和同事的代码，查漏补缺。协作时间之前的某个时间，没有任何通知就进行了测试，并且在周六加班进行了冒烟测试。前后端没有加班，也不知道要测试。所以造成了几次严重的影响，同样是不该犯的人为问题。一是前端没有放出最新的测试版，因为群里既没有邮件也没有官方声明周六上线测试。周六的测试是最后一个打包的版本。情况几乎可以说是白试了。好在测试的版本只是功能一致，只是部分样式没有跟上进度，所以没有造成巨大的时间浪费，影响也不大。二、在平时工作中，前后端在发布第一个版本时，很少有人会主动在群里提一下，或者发个正式的邮件声明（虽然有时候也不需要太正式），导致测试提示网络错误，或者使用旧标准测试新代码（比如突然改了一个新需求和ui，但是测试不明），导致测试过程出现bug或者被打断（见下文）。在效率上，可以避免很多不该出现的问题，一句话就搞定了。其次，方便别人也是方便自己。发布版本的时候，还可以注明当前版本，发布的内容（更新了哪些功能等），以及一些其他的说明，让事情有据可查，更容易让别人看懂。但在几家公司发现，无论是刚入职的新人，还是混迹已久的老油条，都不会过多关注一些团队和沟通细节，或者懒得操作，宁可事后指责，也不愿事前注意。Tips：在中国没有使用电子邮件的习惯，即使是在工作属性重的工作场所也是如此。如果不是强制性的，别说邮件，连聊天软件都懒得回复。如果没有必要，连口头内容都不会出现。建议大家多用邮箱，至少要用群或者有聊天记录的通讯工具。其实归根结底，首先是工作态度的问题，愿不愿意配合配合，其次是工具的使用。其次，要注意的事情，最好的工作时间是所有员工都在的时候，有问题一定要及时处理。不可能等别人下班了再解决。这不会解决问题。事情应该有优先次序。（很重要，思维方式）建议上班时解决需要与他人合作的问题。紧急和重要的问题可以留到下班或加班或解决合作问题后。权限问题测试的过程往往需要重复运行一个过程。但是，一个进程往往在运行后固定了数据状态，不可能再创建另一个运行账户或者每次调用后台清除数据（只有前端）。虽然假数据也是可以的，但是有些逻辑还是需要真实的反馈，比如登录，短信验证，身份识别，订单提交等。一般的开发，有本地环境，测试环境，正式环境，至少在本地环境和测试环境，数据可以临时操作。如果有管理后台，建议获取运行测试环境的后台面板，对自己开发的模块做一些流程设置操作，比如更改用户状态等。如果没有后台管理，也可以用sql直接操作数据库（前提是对数据库和表结构略有了解~具体可以问后台）。其他人来重置数据，他们可能一直很忙，没有时间帮助或关注您的需求。其次，直接操作数据库是权限很大的事情，哪怕只是本地环境，也要尽量避免产生脏数据，影响其他进程。有时候需要复现一个bug，必须经过一些流程，操作繁琐，定位困难，通过后台修改数据库会快很多。总的来说就是测试你拥有的权限。你尽量有的也一定有，比如管理后台、数据库等，没有的话只能让相关模块的人尽量配合。避免出现有时间但进程卡住无法运行的情况。这种现象真是浪费时间，浪费时间。已经很久了。Tips：当然，还会有一些其他的权限，比如代码合并权限，发布测试和在线权限。这涉及技术和态度的意外因素。关注那些有时间有技术但你不会操作的东西。积极作用。积极的方法可以简单概括为合理的分工、明确的职责、模块化高效的沟通机制（聊天软件、任务面板、邮件等）、定期检查、及时调整（codeReview、每日、每周、大小会议）)与正面影响相比，我倾向于排除负面影响。即使正面影响不大，但至少不会影响效率和进度。要知道，大公司、小公司，其实最混乱、最致命、最核心的，从来不是技术和能力，而是团队的管理和协作，人与人之间的沟通和行为。tips：正面影响会在下篇详述文章。
