题外-工作方法论

背景：从2020年4月份至今，也工作了快一年了，来总结下我个人的工作方法。本篇博客仅是对自己的一个工作方法的总结。
身为一个前端工程师，每天的工作其实可以用下面的流程来简述：

1. 接到需求
2. 自我评审需求
3. 跟pm对需求
4. 设计需求
5. 实现需求
6. 自我测试需求
7. 给pm测试需求
8. review自己代码
9. 提PR

虽然每天都是这重复的流程，但是往往细细思考，我们就可以发现很多新的东西。我就是一个比较爱思考，但是我动手并不是很勤勤的程序员吧（目前正在自我规避中）。针对上述流程的大框，具体我是这么做的：

• 当我接到需求的时候，会先大概过一眼。因为从入职leader不止一次的提醒我们，不要成为一个机器（纯工具人）。初入职场的我当时还不能理解到这些，仅仅认为我如果可以保质保量完成需求就好，这就是我的工作。但是其实并不是这样的。自己大概过一遍之后，就会对这个需求有一个初步的了解，可以记下来本次需求需要处理的点及自己不明确的点。往往PRD上都会写明这个需求的背景，但是也难免会存在没有标明背景或者自己看了背景但是还是无法理解，这些都可以记下来，等到跟pm对需求的时候去check这些点。
• 当自己已经看过了这个需求，此时我们就可以跟pm去对这个需求了，先是听pm来讲这个需求，在这个聆听的过程中，其实我们自己标记的一些check的问题也已经解决了。可能还会存在跟我们理解有分歧的地方，所以聆听pm去讲述他的需求这个过程我认为真的很重要。
• 当pm讲述完他的需求，我们可以针对我们想要check的部分去跟pm核对。
• 往往核对之后，我都会在用我自己的话去简述下这个需求，然后去问pm，“这个需求是这样的，对嘛？”。通过这样的询问，更可以确保你跟pm想要的需求是一致的，确保不会出现，开发过程中发现跟pm理解不一致，从头开始。
• 当我们跟pm对完需求，就已经对本次需求彻底了解了，可以先写一个设计文档，针对此需求，去设计下如何实现。这样我们不是边写边想，而是按照设计文档去实现我们的需求。
• 当开发完这个需求后，我一般都会自测一下我的功能，记录下自己有bug的地方，然后去修复它，确保下次不会犯同样的小错误。当自测没有问题之后，再去给pm进行测试。这样还有一个好处，就是你给pm测试的项目问题会少很多，时间积累，会得到一个很好的评价哦～
• 当pm测试也没有任何问题的时候。再重新review下自己的代码，然后提pr。

总结：工作第一年的自我工作方法总结，目前还是按照这种方式去进行，可能有的地方存在部分不合理欢迎大家提出意见，我会不断去改善我自己的方法～