1.1　为什么你总是下不了班

如果你是一个初级前端开发人员，很有可能并不知道Mock.js是什么技术，我们先抛开对技术的理解来看看一个初级前端开发人员的工作具体包括哪些内容。一个任务被拆分为前端和后端两个部分后，前端和后端开发者通常会先商议接口细节并编写相关文档，然后团队的成员就会开始自己的编码工作。当前端开发人员写完页面静态部分的代码时，后端开发人员很有可能还没有准备好后台的接口。这种情况下，团队的项目经理往往会要求前端开发人员先使用虚拟数据把页面填充起来看一下效果，调整一下样式，等到后端开发完毕后再进行联调，这也是非常合理的。对此，开发者通常都会选择如下几种处理方式。

• 将数据直接写在所使用的代码段附近，等后台的接口开发完毕并进行联调之后再来修改。这是初级前端开发人员最容易想到也最常使用的方式，虽然选择这种方式本身并没有什么问题，但可以确定的是，将来重构代码时的工作量将会非常大，因为需要手动改写每一段虚拟数据，将它们的获取方式改为从后台请求。这里还需要注意的一点是，数据的返回是异步的，如果依旧像对待静态数据一样来编写代码，那么很有可能后续的逻辑会在获得数据之前先被执行，这时得到的结果往往不是自己所期望的，而初级前端开发人员却不能理解到底发生了什么。
• 将需要的数据写入JSON文件，从本地引用或请求。稍有经验的前端开发人员会更容易接受这样的方式，相对于前一种方案而言，它的“侵入性”更小，虚拟数据可以保存在独立的文件中，像普通模块一样被引入，在联调结束后将其移除即可。但以这种方式引用的数据仍然是同步获得的，而联调阶段需要对接的是后端开发人员提供的接口，它是异步返回数据的，如果联调过程不顺利，则很有可能还需要在虚拟数据和真实接口之间来回切换，那么这种方式的协作效率问题就会暴露出来。例如，联调时发现接口出现问题，在后端开发人员修复的这段时间内，前端开发人员自然也需要做一些其他工作，而不是一直等待。可是，联调阶段的代码已经改成前端异步请求后端数据的方式了，后端的接口一直报错会导致前端的整个页面白屏，为了修复与用户界面（UI）相关的其他问题，前端开发人员又不得不将代码改为使用虚拟数据的方式，因此通常只能先把写好的请求代码小心翼翼地注释掉。另外，页面使用的虚拟数据很有可能需要前端开发人员手动准备，面对数组或是嵌套结构较深的对象，手动准备这些测试数据也会消耗大量的时间。
• 等待后端开发人员开发完毕后提供接口。这种方式的确会比较省力，但潜在的风险却很大，因为前端开发人员不得不面对这样一种可能，并非每一位合作的后端开发人员都是专业且友好的，如果他提供的接口一切正常，那自然是皆大欢喜，前端开发人员只需要进行一些字段的检验和调整就可以宣告联调成功了。但如果与你合作的后端开发人员恰好是位新手，那么联调的过程可能就会变成反复刷新页面、协助测试接口、抓取请求log_id等无聊的工作。可能几个小时下来，你除了不停地刷新页面以外，几乎什么进展都没有。如果与你配合的后端开发人员比你更有话语权，或者恰好是你的领导，那么他们极有可能会坐在你的电脑前进行各种调试，而你尽管有其他任务在身也只能耐心等待。最终的结果就是，你需要写很多额外的代码来解析和重组后端返回给你的数据，甚至还有可能因为数据结构的变化而导致前端的整个逻辑需要进行重构。最后，别人的工作都做完了，你却不得不留下来加班。

你为什么总是加班？开发经验的欠缺只是原因之一，更重要的解决方法是，我们需要学习在团队作战中如何高效地完成自己的任务，以及如何更有效地与他人合作，这从来都不是一个靠妥协和忍让就能解决的问题。工作流程的优化对任何团队来说都是一件重要但不紧急的事情，你可以置身事外等待队友来处理，也可以躬身入局自己来推进问题的解决（并不是让你独自一个人来实现的意思），而后者不正是我们作为软件工程师的本职工作吗？