让协做“飞”起来

没有人是一座孤岛，能够自全。每一个人都是大陆的一片，总体的一部分 —— 约翰.多恩(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，测试提给产品，让产品统一去协调和分配，固然有的问题产品凭本身的经验就知道该分配给谁。这对于比较有经验的测试大拿来讲，可能不算是个事儿，直接知道该提给谁了，可是避免不了有新血液的加入，若是有新人的加入，咱们商量的对策是老带新，让有经验的测试大拿为他们培训一下，这样你们在协做的时候就不会找错人，就会很高效。

妙用项目复盘会

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

不少人都感受开会浪费时间，可是我想说的是，这个会议颇有必要，表面上给人的感受是开会占用了一些时间，可是它是为了更好的让你们协做，为了更好的提效，为了节省更多的时间。由于你在开发的过程当中不可能一路顺风的，一些小问题能够私下处理，可是总有一些流程中的问题，或者说须要跨部门沟通交流的问题，对于这些问题若是不及时解决，确定会影响项目或需求的进度，因此说开会是有必要的。

咱们会按期进行复盘会，由于会上确实暴露了不少问题，面对这些问题，咱们也制定了适合咱们的合做规范，在平时的合做过程当中，你们都遵照着这些规范，合做起来很顺畅。假如没有这些会议和规范，我想咱们天天都是在人心涣散的工做，正所谓无规矩不成方圆。

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

高效协做的意义

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

尾声

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