没有人是一座孤岛，可以自全。每个人都是大陆的一片，整体的一部分      —— 约翰.多恩(John Donne)

作为一个前端开发工程师，我们不是孤军奋战，也同样需要和其他岗位相互协作。在协作的过程中，肯定会遇到一些影响效率的问题，针对这些问题，你们有没有制定出一系列的提效方案？这就是今天我要给大家分享的内容，我会通过在实际工作中遇到的一些具体问题，阐述下我们的提效方案，我相信这会给你们带来一些启发的，特别是初入职场的同学。这点很重要，正所谓工欲善其事，必先利其器。接下来我会按照下面的提纲分别给大家阐述。

• 设计师篇
• 后端研发篇
• 多方合作篇
• 高效协作的意义

设计师篇

设计师是和前端合作最多的岗位之一，分为交互设计师和视觉设计师，也可以称为前端的“上游”，从下面这张图也可以看出来。简单介绍下合作模式，首先交互设计师和视觉设计师按照需求把交互稿和设计图制作好，和产品确认无误后再交给前端，最后前端同学拿到交互稿和设计图后将它们转换成代码。看着合作流程不复杂，但是如果处理不当，很容易暴露一些问题。

前期沟通的重要性

前端同学在开发之前一定要和设计师进行一定的沟通工作，否则很可能会造成后期返工，特别是对于那些比较常见并且涉及面比较广的影响因素，更要提前去考虑，这点千万不要指望产品和设计师帮你们想好。这里我大概列举了几点，可以参考下：

• 屏幕分辨率
• 兼容性
• Windows 系统没有苹果字体，可以用 "Microsoft YaHei" 也就是“微软雅黑”替代
• 404 或者 Error 页面（很多设计师都会忘记这两个页面，不知道为啥）
• 针对产品文档里要制作的动画，交互设计师能不能提供一些可供参考的 demo 等等

下面我再通过一个屏幕分辨率的例子来说明下前期沟通的重要性。记得身边有个小伙伴接了一个包含切图的需求，页面不复杂，小伙子拿到页面后，二话没说就开森的开始切页面了，而且切的很快，三下五除二，没多长时间设计图就被转换成了 HTML 代码，活生生的展示到了他的屏幕上。小伙子一脸成就感，非常满意的把作品拿给产品走查，心想产品绝不会挑出任何毛病的，因为自己是严格按照设计图切的，除非设计图有问题。小伙子很自信（这一点很值得大家学习），当他正要继续下面的工作时，产品突然来电说页面底部咋有个横向滚动条呢？小伙子迅速地排查了一下，最后定位到是页面尺寸，也就是屏幕分辨率不对，再对比下设计图，发现设计图也是这样子的。和产品解释了一番，最后产品还是有点儿不满意，想要改，但是小伙子大概评估了下，说改动量很大。当然最后协商还是没有改，试想如果产品很强势非让改呢，那这个锅谁来背？又要搞一遍，造成了重复劳动，事倍功半，非常低效。

这个事情，我总结了下，可能是设计师忘记考虑屏幕分辨率这个因素，就习惯性地做了个大屏幕分辨率的设计图，而前端同学拿到设计图后，也没有去想，上来就直接开始切图，当然这可能和经验有关系。不管怎样，如果他们在前期沟通好，我想完全可以避免这个问题的，所以前期和设计师的沟通非常重要，大家一定要重视起来。

并行协作和减少“请求”次数

在你的工作中，不可避免会遇到一些紧急需求，这里说的紧急需求指的是有视觉设计师参与的，也就是需要出页面的，比如电商公司的大促活动、年货节或者年度账单，再比如因为最近比较猖狂的新冠肺炎而新增的紧急需求，他们的共性特点就是紧急，倒排，很大可能还需要加班赶工。

对于这类需求或项目，前端该如何和设计师高效协作呢？首先紧急需求最怕阻塞了，试想如果在某个环节一直阻塞下去，那需求肯定不能正常上线，因为上线时间是固定不变的。对于出设计图也是这样，前端不可能一直等设计图全部出完再参与，那该怎么办呢？我想大家已经猜到了，就是分批出图，这样有两个好处，首先是保证了出图的质量，毕竟设计图出的快很有可能让质量打折，其次也不耽误前端的切图，设计师出一批，前端切一批，并行协作，等前端切完第一批时，设计师已经把第二批出完了，照这样下去，肯定不会造成前端等设计师的局面，也就是不会出现阻塞的局面，最起码在设计师和前端这两个环节中是不会出现阻塞的。

讲完了紧急需求需要并行协作，再说下如何寻找设计师，减少“请求”设计师的次数。现实工作中我见过很多同学一有问题就给设计师发消息，换位思考下，如果你是设计师，你会不会不耐烦？你会不会这样？

可能设计师当时在忙别的项目，你这样做也许会打断他的思路或者排期。这里面也讲究方式方法的，你可以积攒问题到一定的数量之后，再统一找设计师，非常紧急或者影响比较大的例外。这样当设计师忙完手头工作之后，会统一处理，节省了大家的时间，何乐而不为？如果怕设计师忘记，可以发邮件做下备忘，总之不要一遇到问题就找人家，特别是初入职场的人，最容易出现这样的问题了。

组件化

一提到组件化，大家可能会习惯性的想到前端领域里的组件化，就像下面这张图。但是这里我要讲的是设计图的组件化，顾名思义，其实意思都差不多，就是把一些公共模块提取出来，对一些小组件做到心中有数。这样不仅能让前端合理划分样式，写出后期好维护的代码，也会对设计师自身有很大帮助，比如方便他们更快地组装一个新页面，节省他们的时间等等。

接下来我讲两个对立的需求场景，来帮助大家更深入地理解视觉组件化的意义，当然，这两个需求场景肯定都是带有切图工作的。

场景一

记得我刚进厂子不久跟进的一个需求，那个需求共需要设计 6 个页面，设计师也按时并如数给到了前端。我当时拿到设计图后，首先做的就是挨个查看这几个页面，然后列举出来一些公共的内容，比如有多少种按钮，有多少种可复用的模块等等，目的就是方面编码时好组织样式。这些非编码工作很是耗费时间，但是也不得不做，因为样式组织不好，开发和后期维护的工作都不会很顺利，并且给人的感觉是相当不专业。

场景二

再看看第二个需求场景，页面个数也差不多，但是设计师给的图里不仅有几个完整的页面，还新建了一个页面来放置很多小的组件，比如按钮有几类，有多少种尺寸，有多少种颜色，井然有序，一目了然，并且还提取了很多可复用的模块，当时看到这些很是开心，于是就给了我们那个设计师一个大大的赞，因为这正是自己想要的，以前都是自己去梳理。从那以后，每次需要出设计图，我们都会这么做，因为我们觉得这是一个很好的实践，既节省了前端的时间，又提高了设计师出页面的速度。

从这两个案例可以看出，组件化不仅为自己提效，也会为其他人提效，也就是整个协作团队效率潜移默化地都得到了提升！

后端研发篇

说完了如何与设计师高效协作，接下来谈谈与后端研发（后面简称“研发”）高效协作的那些事儿。研发也是和前端协作最多的岗位，可以理解为前端的“下游”，主要为前端提供动态数据，也就是接口，涉及到接口，不可避免会有联调的工作。下面我会分别从不同的阶段介绍下我们是怎样与研发高效协作的。

未雨绸缪，充分准备

正常的，需求评审完，大家听完产品经理的宣讲，就解散回到自己的工位上，各自开始开发了，相信大家都是这个流程。但是这可能还不够，因为在需求评审阶段，毕竟会议时间有限，讲的最多的是需求，说的最多的是产品，技术层面比如接口都还没有讨论，这时候如果大家开始开发的话，方向对了还好，如果错了咋弄，不就造成时间的浪费了吗？所以建议，在研发和前端听完需求评审后，或者过个一两天，再次约会坐在一起讨论下技术层面的实现，比如某个需求可能前端实现起来比较方便，也可能让研发去实现更容易；再比如一些接口的定义等等。

这样在前期把能确定的技术方案确定下来，能明确分工的提前分好，一些基础的 API 提前定好，做好充分的准备，避免开发中遇到这样那样的问题，期间如果大家对某个需求理解的都不透彻还可以拉上产品童鞋来帮忙。总之需求评审后最好再来次技术评审，这样大家在开发前做到未雨绸缪，开发过程中就会少走很多不必要的弯路，减少很多不必要的沟通时间！

及时沟通，避免阻塞

当前端完成页面重构和基本交互后，要进入数据交互开发了，也就是大家所说的调取接口获取动态数据的环节，此时研发那边可能还没有真实的数据，那么可以让研发帮忙造些 mock 数据。前端同学要及时找研发沟通，并且主动推动研发造数据，可能他们会忘，也可能他们忙于其他逻辑的开发，最好在排期中体现下什么时间能把数据造好，前端同学好进入数据交互的开发。记得有一次，在做一个售后申请的需求，售后嘛，只能等下完单才能有记录，因为预发和生产环境使用的是同一个数据库，假如要等真实的单子，那非要等上几天不可，如果是京东物流肯定会快点儿。我们没有测试服务器，只能提醒研发造些 mock 数据来开发。当然如果有条件还是希望有个测试服务器的，数据库和线上数据库分开，这样可以让研发随意帮忙添加测试数据，风险也低。

上面这个估计大家都没有问题，或者说都是按照这个流程走的。再讲一个，那就是发版的问题。
大家在开发过程中，不可避免会调用研发的服务，这里大多指的是接口。这些接口可能会有问题，可能还会调整，假如研发要调整接口，肯定需要重启服务器，重新发版。由于前端的环境依赖这个服务器，所以当研发发版时，前端就无法正常开发。我接触的项目大多都是这样，可能你们有好的解决方案，如果有可以在底部留言。对于这种研发发版影响前端的场景不可避免，但是尽量还是让大家有序协作，我们采用的方案是，发版前和发版后在聊天工具中及时通知大家一声，像这样。

这样做的好处是可以让大家统筹安排自己的时间，避免阻塞，假如服务器需要半个小时以上才能恢复，就需要邮件告知，其他岗位的同学好灵活安排自己的工作。

巧用工具，事半功倍

测试阶段产生的问题原因很多，有的很好定位，比如简单的前端问题，直接看下控制台有没有报错即可。如果是移动端可以安装 vConsole 等工具协助，使用方法和 PC 浏览器里的控制台一模一样，研发很容易上手，也比较方便帮助前端排查一些问题。下面是 vConsole 的官方 demo 截图，如果感兴趣可以戳链接。

但有时候感觉不是前端的问题，控制台没报错，但是为了提高解决问题的效率，也想排查下是否是接口的问题。很多公司应该都有独立的接口日志平台，当然可能有权限的控制，如果方便可以让研发为前端开个权限，这样的话前端就可以帮助一起查看基本的接口问题，比如接口入参错误，或者缺少入参等等。

善用 README 文件

再说一点，很多同学做完需求，上完线就感觉已经万事大吉，这是不对的。可能下次需求不是你来支持，但是不管是谁来支持，都要做好后期的维护工作。这里讲的维护工作指的是充分利用好 README 文件，不管是前端还是研发，因为通常大家接手一个项目时，首先看的是这个文件，最起码前端是，如果项目中重要的资料（比如接口地址等）没有在这里备份，就会造成后面维护人员再花费很多时间去找其他岗位沟通或者是看代码，长此以往，就会浪费很多人的时间，这些时间完全是可以避免的，长痛不如短痛，请大家开始重视！这个我是遇到过的，记得当时研发换了新人，但是由于前面的研发没有做好维护工作，导致新的研发不断的来找我要各种资料，还好我已在前端项目里的 README 文件里提前做好了备注，将一些资料的详细地址记录了下来！

这个很重要，因为据我了解，很多公司，特别是大一点儿的公司，开发人员更新很快，根本都没有沉淀一些东西，导致后来负责维护的同事无从下手。

多方合作篇

这里讲下多方之间的相互协作，不止是设计师和研发。毕竟作为一个前端，不可能只和设计师还有研发协作，前端肯定会看 PRD 的，肯定会参加需求评审的，如果对 PRD 有疑问或者对某个需求理解的不透彻肯定会麻烦产品姐姐来帮忙的；测试更不用说了，现在都是测试驱动上线，测试大拿会给前端提 bug，只有前后端把 bug 都修复完了，测试大拿们才会拍板上线，毕竟他们是最后一道守护神嘛，当然，你可能还会想到这个。

言归正传，说下我们在多方协作的过程中遇到的几个问题和解决方案。

需求要统一，细节要注意

这里讲的需求是指产品的 PRD，试想，如果大家开发或测试时拿到的不是同一份文档，肯定会出现各种问题：

• 研发会返工
• 测试提无效 bug
• 影响整个协作链的效率
• 导致非必要的口舌之争

所以统一大家时时刻刻看到的 PRD 是相当的重要。

记得在做某个需求的时候，已经到了测试的环节，测试大拿给提了几个 bug，这很正常，但是我在解决的过程中发现，自己写的逻辑是完全和 PRD 一样的，也就是说测试大拿提的是无效 bug。当时很开心，就喜欢这样的，不用改，直接关了就行，而且还光明正大的选择成无效 bug。等到第二天，收到了几封邮件，是关于 bug 的，因为我们的 bug 系统已经关联到了邮箱（通常大家都会这样做），刚开始以为测试又提了新 bug，但是不经意间发现竟然还是昨天的那几个，很是疑惑，就去找测试大拿 PK，结果发现我们两个的 PRD 是不一样的，有点儿挠头了...

无奈之下只能去找产品经理，这不找不要紧，一找竟然发现产品的 PRD 和我俩的都不一样，也就是说这次需求至少有三份不一样的 PRD，产品经理的是最新的。当时我和测试大拿都快气疯了，问了问产品经理，才知道产品经理后来进行了些微调，修改了一些细节，没有及时同步给大家。

这种情况我想大家都遇到过，毕竟大家都各忙各的，难免会丢三落四。那咋办呀？想辙呗，首先三方再拉上研发一起核对下最终的 PRD，研发和前端根据最终的 PRD 分别调整下代码。然后也是最重要的，如何防微杜渐？最终大家找到了一个解决方案，就是只维护一份 PRD，可以采用在线的形式，当产品经理改动时，各个岗位可以收到改动的推送通知，像这样。

如果你们公司有那就最好了，如果没有的话可以找个开源的，比如语雀，再不行就把 PRD 保存到某个地方，产品改哪些地方就邮件给大家，并且以不同颜色标注下。总之要让大家时时刻刻看到的都是同一份 PRD，这样就不会出现上述问题了，也提高了各方的效率。

精准定位 bug 负责人

测试大拿提 bug，大部分是提给前端和研发，当然也有产品，不过很少。在这些 bug 中，有的是提对了，也有些是提错了，处理不好那些错提的 bug 也会影响大家的效率！

记得我们有几次做需求，前端同事收到了很多 bug，这些 bug，一看就不是前端的问题，比如下面这个报错信息。

但是测试同事不知道是该提给谁，他们一致认为，浏览器上的报错都应该提给前端，所以就导致前端同学的 bug 量增加，这不要紧，关键是有的还需要前端去排查，去沟通研发修改，这对于前端来说是浪费了时间，干嘛不直接提给研发呢？特别是新来的测试同学，没有这方面的经验。

我们采取的措施是，对于确实不知道该提给前端还是后端的 bug，测试提给产品，让产品统一去协调和分配，当然有的问题产品凭自己的经验就知道该分配给谁。这对于比较有经验的测试大拿来说，可能不算是个事儿，直接知道该提给谁了，但是避免不了有新血液的加入，如果有新人的加入，我们商量的对策是老带新，让有经验的测试大拿为他们培训一下，这样大家在协作的时候就不会找错人，就会很高效。

妙用项目复盘会

复盘，原本是一个围棋术语，也称“复局”，指对局完毕后，复演该盘棋的记录，以检查对局中招法的优劣与得失关键。通过复盘，棋手可以有效地加深对这盘对弈的印象，是提高自身水平的好方法。至于项目复盘，直白的讲，其实就是回顾过去完成的项目，并对一些关键事件进行分析，从而从过去的经历中总结经验教训，提炼出规律方法论，为接下来的项目和工作提供有价值的参考。

很多人都感觉开会浪费时间，但是我想说的是，这个会议很有必要，表面上给人的感觉是开会占用了一些时间，但是它是为了更好的让大家协作，为了更好的提效，为了节省更多的时间。因为你在开发的过程中不可能一帆风顺的，一些小问题可以私下处理，但是总有一些流程中的问题，或者说需要跨部门沟通交流的问题，对于这些问题如果不及时解决，肯定会影响项目或需求的进度，所以说开会是有必要的。

我们会定期进行复盘会，因为会上确实暴露了很多问题，面对这些问题，我们也制定了适合我们的合作规范，在平时的合作过程中，大家都遵守着这些规范，合作起来很顺畅。假如没有这些会议和规范，我想我们每天都是在一盘散沙的工作，正所谓无规矩不成方圆。

当然这还要求大家都有执行力，都去按照这些规范去做事情，不能脱离规范，不能纸上谈兵。再者对于刚入职的同事或者说新进入的业务线条来说，规范让他们很快适应我们的节奏，避免不知道如何下手！

高效协作的意义

高效协作并不意味着每天都紧紧张张的，反而是为了让每天的工作有条不紊。你可以把它制定成协作的一套规范，有了这套规范，任何项目或需求都可以很高效的被完成。高效协作的方式也不是一成不变的，需要不断的更新和迭代，但是外变不离其宗，它就是为了提高你的协作效率，让你有更多的时间去研究自己的专业知识，从而更好的用于生产；同时也能让你和你的协作伙伴有机会去探索更多更高效的协作方式。现在的社会节奏很快，特别是互联网，再细点儿是前端，让我们以不变应万变，去拥抱这个世界，为自己、为企业、为社会创造更多的价值！

尾声

到这里，文章已接近尾声，但是探索无止境。前端不仅仅要学习很多新知识，工作中的协作也很重要，让我们引起重视，工作里多积累，线下多分享！让我们一起寻找一套通用的高效协作规范，一起携起手来推进前端行业的发展！我们要与其他岗位深入打成一片，合作的力量是伟大的，正所谓一滴水飘不起纸片，大海上能航行轮船和军舰；一颗孤树不顶用，一片树林挡狂风！我们要与其他岗位高效协作起来，化规范为行动，争分夺秒，持续创新，只因为我们是一支敢追求高效的团队，不畏荆棘，勇攀高峰，让项目和需求来的更猛烈些吧！