没有人是一座孤岛，能够自全。每个人都是大陆的一片，整体的一部分 —— 约翰. 多恩(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，测试提给产品，让产品对立去协调和调配，当然有的问题产品凭本人的教训就晓得该调配给谁。这对于比拟有教训的测试大拿来说，可能不算是个事儿，间接晓得该提给谁了，然而防止不了有新血液的退出，如果有新人的退出，咱们磋商的对策是老带新，让有教训的测试大拿为他们培训一下，这样大家在合作的时候就不会找错人，就会很高效。
妙用我的项目复盘会
复盘，本来是一个围棋术语，也称“复局”，指对局结束后，复演该盘棋的记录，以查看对局中招法的优劣与得失要害。通过复盘，棋手能够无效地加深对这盘对弈的印象，是进步本身程度的好办法。至于我的项目复盘，直白的讲，其实就是回顾过去实现的我的项目，并对一些要害事件进行剖析，从而从过来的经验中总结经验教训，提炼出法则方法论，为接下来的我的项目和工作提供有价值的参考。
很多人都感觉散会浪费时间，然而我想说的是，这个会议很有必要，外表上给人的感觉是散会占用了一些工夫，然而它是为了更好的让大家合作，为了更好的提效，为了节俭更多的工夫。因为你在开发的过程中不可能一帆风顺的，一些小问题能够私下解决，然而总有一些流程中的问题，或者说须要跨部门沟通交流的问题，对于这些问题如果不及时解决，必定会影响我的项目或需要的进度，所以说散会是有必要的。
咱们会定期进行复盘会，因为会上的确裸露了很多问题，面对这些问题，咱们也制订了适宜咱们的单干标准，在平时的单干过程中，大家都恪守着这些标准，单干起来很顺畅。如果没有这些会议和标准，我想咱们每天都是在人心涣散的工作，正所谓无规矩不成方圆。
当然这还要求大家都有执行力，都去依照这些标准去做事件，不能脱离标准，不能夸夸其谈。再者对于刚入职的共事或者说新进入的业务线条来说，标准让他们很快适应咱们的节奏，防止不晓得如何下手！
高效合作的意义
高效合作并不意味着每天都紧紧张张的，反而是为了让每天的工作井井有条。你能够把它制订成合作的一套标准，有了这套标准，任何我的项目或需要都能够很高效的被实现。高效合作的形式也不是变化无穷的，须要一直的更新和迭代，然而外变不离其宗，它就是为了进步你的合作效率，让你有更多的工夫去钻研本人的专业知识，从而更好的用于生产；同时也能让你和你的合作搭档有机会去摸索更多更高效的合作形式。当初的社会节奏很快，特地是互联网，再细点儿是前端，让咱们以不变应万变，去拥抱这个世界，为本人、为企业、为社会发明更多的价值！
序幕
到这里，文章已靠近序幕，然而摸索无止境。前端不仅仅要学习很多新常识，工作中的合作也很重要，让咱们引起器重，工作里多积攒，线下多分享！让咱们一起寻找一套通用的高效合作标准，一起携起手来推动前端行业的倒退！咱们要与其余岗位深刻打成一片，单干的力量是平凡的，正所谓一滴水飘不起纸片，大海上能航行轮船和军舰；一颗孤树不顶用，一片树林挡狂风！咱们要与其余岗位高效合作起来，化标准为口头，争分夺秒，继续翻新，只因为咱们是一支敢谋求高效的团队，不畏荆棘，勇攀高峰，让我的项目和需要来的更剧烈些吧！