前端工作7个月的总结

好久没更新了，每次登陆都会看到朋友们点赞收藏我之前写的帖子，承蒙抬爱。

现在工作也七个月了，我想要来分享一些工作后我总结出来的心得体会。

大道理人人都懂，其实分享出来也不一定可以给朋友们带来帮助，不过怎么说呢，大家可以或多或少看到工作共同存在的无奈吧，让我们一起探讨如何处理这些让人不爽的时刻。

一、工作一定要写工作文档。

工作文档分为三种：需求文档、需求变更文档、发版前的debug文档。

我推荐使用excel去记录。

首先，需求文档大部分人都不会写的，因为产品会做好原型图提供我们参考。我一开始也是对着原型图做前端的页面设计的。后来我发现几个弊端：

①原型图是产品设计的，也就是说，如果在你工作过程中，产品修改了原型图，你是没有证据说明对方做了修改的，那么可能你之前的工作就要推翻重做了。当然，因为产品做好原型、确定需求的时候，一般都会开一个需求会议，项目组的所有人都参与，所以这样的事情不会发生。（发生了就是很严重的信任危机了）

只是我觉得，如果是和自己有关的工作，都尽量把资料存档在自己手上，这样才是最保险、最安全的做法。

②产品的原型图一般是基于那个画原型图的软件设计的，里面的页面风格是一种比较呆板的格式，一般做出来的成品会比原型图好看。所以说原型图可以参考的内容是：页面的布局、交互的内容。而页面上有很多细微的样式设计是需要前端自己主动设计的。一开始我刚入职的时候，做页面就很呆，对着原型图做好了就完事，然后产品提了好多需求啊，让我二改、三改、四改，有一次甚至提出了26个需求，我就被迫加班了。我们都很无奈，产品觉得：“页面就应该越美越好”，而前端觉得这个需求原型图没展示出来，为什么要做？

所以你需要自己主动设计一些内容，一些能够使用户体验感更好的小的设计都加上去，在做好第一版以后跟产品确认，然后将这些【前端自己新增的、原型图上没有的需求】记录在【需求变更文档上】，同时将这些需求以文字形式发给产品看，留下聊天记录，方便之后你们battle的时候马上找到证据。

这是我总结出来的减轻工作量、减少低效沟通的好方法。

第二：记录需求变更

我第一次做项目的时候，我的产品和领导都对我的项目很关心，提出了很多改进意见（我当时确实是不擅长做样式设计，所以做出来的页面不太美丽）。其实改进意见很多，让我修改，是ok的，问题是他们两个没有沟通，都是单独给我提需求的，然后就提出了很多冲突的需求，我改了四五版以后真的累了，于是就把我们三拉个群一一确认最后到底是要什么样的样式。这个过程，因为改了太多版本了，很多需求他们都忘记了是自己提出来的。。。。所以就是我吵架根本吵不赢，我的工作量没有人承认。

其实作为打工人，中间改了多少个版本都无所谓，我们只要按照需求去写代码就可以了。

这件事让人不爽的点在于：明明是他们沟通不当、害我徒增了很多工作量，我却没有证据说明这些，只能自己把委屈给吞下去了。

这件事背后最重要的逻辑是：你的工作量一定要是可以被承认的，你的每一个工作都是要有工时的。一定要建立起这种意识，不然不小心打白工才知道懊恼。

第三、记录debug的过程

一般来说，有的时候需求比较少，我们就只能自测了。毕竟项目组不大，我们没有测试员，自测的时候自己发现bug就马上改正了，产品发现bug就会发信息过来，聊天记录就是满满的图+需求，很乱。这个时候就要马上记录下来bug的来源、细节、以及到底是前端还是后端的锅，这样方便自己复盘，也方便上线后的验证。

二、工作完成后，尽快把进度推进，把问题抛出去

一般产品上线会经过以下几个过程：产品和业务对接，确定需求 → 产品制作原型图 → 项目组开需求会议，将需求说明给所有人 → 前后端一起开发、自测通过 → 将代码部署测试环境、验收 → 在某个时间点发版，这个时候要项目组所有人一起等发版成功、然后验收。

在我们公司，一般发版是需要提前4-6天申请的，所以发版的日时间是具体到某天、几点钟的。

一般等到代码都开发完毕，且部署到测试环境后，距离发版还有两天时间。这两天的时间，产品会反复测试、提出改进意见。

那么我们会遇到的让人不爽的情况有哪些呢，以及如何应对呢？

①产品迟迟不验收，在发版当天下午，距离发版还有两个小时的时候疯狂提出改进意见。

这个时候要改代码就很烦啊，因为怕赶不上发版，那开发的程序员就压力很大。而且修改完以后还要打包、部署到测试环境，这个过程是比较麻烦的，也可能存在测试环境和本地环境有差异的情况，那么就要反复部署、反复测试。就算需求不难，也不想要在这个时候被提出新的需求好吧！

处理方法：

①开发完以后马上催产品验收，这两天时间尽量让对方及时给自己反馈。（遇到很拖延症且厚脸皮的产品，那么这一步就无效）

②在发版前，上午就在项目组的群里说明已经自测通过，礼貌邀请项目组其他人一起测试。

③在下午三四点，再次发起邀请，并且说明自己将在17：00/17：30封板。

虽然封版还是可以修改的，但是怎么说呢，封版毕竟是一个态度，就是我已经完成了我的工作了。如果这个时候产品还要给你提出新的需求，说这里的样式太丑啦、那边的icon改一下、这里的宽度改一下这种鸡毛蒜皮的小事，对方就会显得很小题大做，或者说给别人一种感觉：“ta为什么不早点提出这种需求，而是在封版后才来吹毛求疵”。

你要先把自己的工作做完，然后告诉别人你做完了，把问题抛出去，那么进度就会到了“产品验证通过了吗”，和开发就没啥关系了。如果出问题了，那么问题也不在于你，而是在于产品没能及时发现问题、及时提出新的需求。