一星期的加班感悟

一.情况

本博主在周五接到了一个不幸的消息，有一个合同很着急，任务有很多没有做，这就意味着周末开始要加班了，不过很好的情况是，公司周末不会去公司加班，而且平常很少有周末加班的情况。于是本博主在周日的时候在家加了一天的班，需求大概明确，业务基本了解了，就开始撸代码了。周一的时候接着搞功能，并且postman测试接口。就这样持续了一个星期，每天都是晚上12点下班，这个周末也是第一次要求来公司加班，调程序。情况大概如此。
下面是我自己分析为什么会出现天天干到12点，一星期后还是存在问题，直到今天结束。

二.问题：

1.需求明确不到位。

具体到需要什么数据，报表之间的显示跳转等问题。一定要先把需求搞明白，这就好比产品让你去东，你去西。不明白及时问产品。这是最基本的东西，也相信大家都明白这个道理，但是又有多少人在还没搞懂需求，或是有什么不合理的地方提出疑问等问题。

2.数据库创建不明确。

在建立数据库字段的时候没有理清数据之间的关系，确定好到底需要什么数据需要存入数据库。导致在做的时候需要什么字段会往数据库添加字段，不需要的字段又会被浪费掉，删除的话也会影响实体类的修改等。导致底层频繁修改。底层都修改了，那么业务层，显示层紧跟就要修改。这一套下来，改变的时间会花费很多。

3.没有先写接口文档

没有写出接口请求参数，和页面显示数据。这会导致在没有理清业务流程的时候遗漏接口之间传递数据的情况。以及接口参数的命名等问题。在设计好的前端静态页面，少看一个显示字段，获取页面传递时调用接口返回需要什么数据等。这都是在书写接口文档时应该考虑进去的。

4.没有画业务流程图

这样会导致逻辑混乱，在编写代码的时候写一部分想一部分，这样会导致等待功能完成进行自测的时候，发现逻辑错误，开始回去修改逻辑代码，原来的逻辑又要重新梳理，这样会浪费很多的时间，所以一定要先梳理逻辑，画出流程图，数据之间的转换，以及数据流向等梳理清楚，否则一旦出现逻辑混乱和就要回去修改，甚至修改主体逻辑，导致编写的代码全部作废。如果逻辑梳理清晰，那么在发现逻辑不清晰的时候，拿出流程图回想一下，这样就不用在想当下的逻辑是什么，又可以继续编写代码。
有的时候我们认为任务很紧，比较简单的逻辑不用梳理，在脑袋里已经形成，也认为不会有什么大的出入，而且新手也更喜欢上来就撸代码，认为很简单的逻辑不需要画流程图。把页面显示字段都包含在内，其他字段用时候在创建等。这都是我们在着急情况下比较容易犯的错误，当然我自己也是一样，有的时候，觉得脑袋思路很清晰，直接开始撸代码，想尽快完成编写代码工作，多给自己留些时间进行自测，以及更多的异常测试。但最后却是小bug存在，有的缺少字段，接口之间的数据调用缺少等情况，甚至有的逻辑出现设计偏差，导致重新梳理逻辑，改变逻辑等错误。
虽然这几天很累，但是我觉得还是很有收获的。当完成时间达不到自己的预期时间时，就要思考到底哪里出了问题，和如何进行解决，虽然这次的任务并不是很重，业务 逻辑代码不是很多，大部分主要是报表相关接口，基本的增删改查，但我自认为的时间已经出乎我的预计时间。所以这次的加班给我带来了很多的思考。
切记：在编写代码的时候一定要做好充足的准备，看似其他的流程很浪费时间，其实它们都是真正能为你节省时间的事情，编码应该放到最后，只要有了流程图，接口文档必要条件，编码也会很顺畅，根本不需要在进行太多的考虑，而且结果往往离设计不会有很大的偏差，bug也相对减少很多，这才能使你的编码效率大幅度提升。

三.总结

总结一下作为开发人员编码流程：

1. 确定需求并画出时序图（时序图可能对于新手来说很难，因为服务间的调用不是很清楚，技术上可能也有很多的限制。在分析问题调用方面比较困难，有的公司也会帮助你画出时序图，但如果想要往上层走，这是必须的技能，还是要不断锻炼的）
2. 根据需求确定所需数据并定好数据库字段（基础）这个步骤真的很重要
3. 编写接口文档，确定请求参数以及页面显示参数的命名
4. 画出每个接口的流程图
5. 编写代码

四.结束

一定要强制按照步骤来，否则一定会让你吃亏的，目前博主已经吃两次了。
这篇就是我加了一星期班的感受，如果你和我一样，参考下我的步骤，尝试执行一下，相信一定可以为自己节省出很多的时间。
当然如果存在什么见解和更好的方法，或者是我有什么错误，欢迎评论，我一定会虚心学习，谢谢！！