本文大约2500字，看完本文大概需要10分钟，如有错误，请指正。

这篇文章其实不能说是怎么避免加班吧，也不是教你们如何偷懒，就是个人的一些经验，如何高效的利用上班时间，让你在上班的时候就干完活了，来减少加班。我会讲述一个项目从立项到上线每个阶段中前端的职责和如何更加高效工作。

产品

一般产品会把产品需求整理出来之后，会让有关人员一起开项目启动会，告诉我们要做什么了，这时候前端就要密切关注产品经理的动向。

为什么要开这个会呢，我相信在座的大家一般都是乙方公司比较多(外包，定制化的需求，等一些做saas系统，包括一些大数据平台公司)，对于甲方提出的需求，因为有些产品，他不是很懂技术，因为某种原因，答应了甲方的某种需求，你就需要结合实际情况，告诉产品，我做这个东西，难度如何、需要协调哪几个部门、大概要多少时间，甚至是做都做不了的情况。例如，导出一个几十万数据的需求，听起来很简单，做后台的就知道难得一批，比如你去知网查重一篇论文，知道为啥要等很久吗，知道为什么不是你一查重就能导出查重数据吗？多说一点，产品要有能力去判断做出这个需求带来的价值，要能计算出这个需求所带来的价值比。还有一点就是，需求不要只把功能做出来就好那么简单，而是你做出来，有人觉得好用了，并且付费购买了你的产品，才是真牛逼，就好像很多广告，瞎起标题，你一点进去，三秒就进入圣贤模式了，那不是白干一场了吗，做了还不如不做。所以，产品牛逼，开发肯定没那么累，加班肯定次数会少一点。

还有就是，需求确立之后，我就没见过不改需求的，有些是被砍掉的需求，那当然是最好，还有一些是修改的，还有就是一些增加的，这是比较麻烦的。尽量持续关注产品，当他说出，这次改完再也不会改了，改了的话就放到下一个版本上，你才能放心。

然后就是跟前端比较切合的，意淫大法，一般需求出来的前两天，你的任务还是比较轻松的，这时候可以搭个架子，或者用以前搭好的架子，然后对着交互图或者原型图，大概的写一些页面布局，逻辑等，为后期省时间，别在那瞎等设计图。

跟后端约定接口，确立字段

这个比较简单，就是约定接口，是get 还是post还是delete等，后端返回2000是什么意思啊，自己协商一些自定义返回信息，你前端要什么数据，让后端给你，就是前后端衔接起来，防止未来你做完，后端改数据，你前端也要跟着改，好的公司，后端不但会给你字段，并且有详细的api文档，甚至有一个mock环境，你根本不需要考虑数据问题了，开发起来不要太爽，还有就是差一丢丢的，有字段，有文档，自己前端mock数据，我也有写过相应的mock文章，网上也有类似mock的在线工具(要备份好)，然后前后端都开发完联调一下就好了。最重要的就是，一定要让api落实到文档上，后期好维护，开发的时候也减少了低效的频繁沟通(有些开发很讨厌写代码的时候老被打断思路)。

设计

切勿让设计占用太多时间(按计划时间)，为什么这么说呢，因为项目经理给的时间是死时间，比如说客户下个月1号就要用到这个功能，你这个月15号才项目立项，设计就花了你十天，你开发+测试也就只剩下5天时间，所以，各个部门要并行执行，边设计，边开发。设计一般是需要挺长的时间去出设计图的，你要跟设计说好，我要做移动端哪几个页面，或者哪几个组件先给我出设计图，因为设计是不知道你是先开发哪个页面比较顺手的不是吗，设计师出完图，不要立马发给前端工程师，拿着设计图，去找产品经理，我这图您觉得怎么样，产品经理点头之后，再给前端，前端收设计图的时候一定要问设计，产品看过这图没，防止设计乱改图，乱抛锅给你，这里核心就是，千万不要让设计带你节奏，主动权掌握在自己手上。

设计图出来后，跟之前写的逻辑结合。

这个就是初级前端、中级前端、高级前端都会做的事情。切图，上逻辑。但是做出来的效果却不太一样，我这里说一下，不要拿着ui死磕，要考虑很多ui没有展现出来的情况。常见的例如有是否居中，比例怎么样，文字超出的情况。页面颜色，字体。手机兼容性，例如刘海屏，全面屏幕(设计师压根不会给你设计这些手机，还是按照i6的格式)，滚动加载还是上拉加载，节流，页面渲染性能，甚至是一些用户体验的地方，还有一些就是经验的问题了，只能慢慢去积累，经验到了，开发的速度就快了，第二点就是，有一些效果或者特效，做的成本高，其实是可以跟设计大佬们协商的，可能人家只是一时冲动想搞搞新玩意，并不是特别适合用在本项目上，也有一些情况只是设计的无心之举，在前端实现来看却难到不行的情况。

联调

我觉得联调其实就是自测的一种，保证产品的可用性，也防止一些后端偷偷的改了接口没跟你说，这时候你就能发现了，一般联调是算在开发里面的时间。

测试

一般分为test,beta阶段,test和beta其实只是不同的环境，为什么要搞多个环境了，因为中型一点的公司，产品都不止一个，每个站，互相关联，又不同域名怎么办，登陆一个系统所有的系统都自动登陆那就要有sso了。举个简单的例子，例如test环境只可以允许跨域，走的只是http协议，但是beta就不可以跨域了，还升级成https的协议了,你在test好好的，到了beta就发现不行了,所以这是有必要的。在这里前端需要去跟后端甚至是运维协商,如何配置静态路径，如何配置路由,保证应用的安全性,再根据商量出来的结果写各种环境的配置文件了，例如会用到gulp webpack等。这点很重要，不然你切环境花费时间，测试是会停滞不前的，一定要和运维要协调好环境相关问题，跨域啊，http htpps、集群之类的相关问题，不要每次当前环境测试好好的，一切换到别的环境就gg，个人觉得测试的时候只能在配置环境上节约时间了。还有就是尽量把问题暴露在测试阶段，尽量少在正式环境出bug。虽然我一直说挤时间，但是在这个阶段，节奏应该是放慢的时候，不要赶时间，没测试好就说测好了。

项目验收

测试逻辑通过后，就代表这个项目是可使用的了，立马进入项目验收阶段，分为设计验收(是否按照设计图的颜色值，边距值，响应式，适配等)，产品验收(按照需求文档，一点一点的过)，运营或者需求方(老板)验收，为什么要这样做呢？因为可以避免以后被抛锅。

上线

这一步已经代表这个项目快要完成了，按照上面的做法，估计还是有充足的时间的，最后，再看看有没有bug,其实在这里前端犯错的几率就很小了，就算是有bug出现，一般也只是影响体验的bug,至少功能是正常的。例如，我曾经就遇到过，在beta环境好好的，一切到正式环境，有一些地区的用户访问不了，有一些却可以，这种百分之90是服务器运维那块地问题。上线这部分前端一般都是考虑浏览器缓存那块，还有静态资源上传到cdn，就是如何让页面快速呈现到用户眼里。当然如果用户群体很大的话，可以选择较少人使用的时间段去发布等。

监控

一般通过埋点来监测系统的一些加载问题，异常报错，用户行为等数据的收集，例如谷歌的一些api performance onerror等。

总结一下

沟通非常重要，产品经理不要惯着甲方，项目经理不要惯着产品经理，前端不要惯着设计。

答应我别做舔狗好吗。