If you only do what you can do, you'll never be more than you are now.                                                            如果你只做力所能及的事，你就没法进步。

---

一、概况

        在经历了三个多月的新院统战项目，我负责的后端建言献策模块已经基本实现，可能还存在一些bug或者隐藏的问题因素，在后期的测试中发现会一一改正。在此期间，也发现团队的合作，交流是必不可少的。

二、收获

1）思想方面

        （1）抓紧时间，保证不逾期。在此项目中，并不像以前那样，一直拖延，而是在课余时间，分出精力，来使得自己的工作可以更快的完成，不耽误团队整体的时间，提升团队效率。就按这次来说，如果后端接口没有及时完成，那么不仅自己的交付日期会延期，还会导致前端拿不到接口，使得前端只能拿静态数据去测，不知道自己写的模块是否有问题，也会使得前端不能按时交付，导致逾期。如此来看，如果自己这一块不能够按时交付，那么很有可能会影响整体项目的延期。

        （2）不抱怨，有效沟通。在此期间，其实有些时候会遇见自己写的接口老被前端提出要改，比如要多传参数，或者自己在swagger上测试没有错，但是前端却说不对等，最后发现是前端问题等。其实在一开始的我是真的比较无语，也有些生气，自己这本来bug改的就多，前端还一直催催催，一个字就是烦，但又不得不处理此问题。不过在后期的工作中发现，其实主要还是因为自己写的接口不是很完善等，使得前端在调用接口时候，很多情况下是自己这里没有考虑一些因素而产生的问题，比如为空的判断，区间问题等。                                                              总的来说，遇到此问题，前端和后端应该相互理解，理清问题所在，然后在最短的时间内去有效解决问题。

2）工作方面

        （1）需求明确，理清思路。我们在要完成一个需求的时候，首先一点是要了解需求是要干什么的，需要哪些数据，以及有什么要注意的地方等。在开始写的时候，必须要思路清晰，保持大脑的活跃。有些情况在写的时候突然一走神，想些别的事情，在回过头来，发现不知道要干什么了，这就很纠结。我们可以在写的时候先写注释，要写什么东西，这样即使走神，回过头来看时也能很快发现自己接下来需要干些什么。在写完时，通过swagger或者测试类等，测试自己的接口是否有问题，可以多传一些特殊值进行判断。

       （2）活用debug。debug真的是非常有用，有时候我们看着自己写的接口没有问题，但是数据却压根不对，这其实是很头大的一件事情，因为不知道错在哪。比如在写两个集合copy的过程中，虽然copy过，但是数据却没有做任何改变，而且还能运行成功。这时候我们可以通过debug进行打断点，来依次查看我们的程序是哪里出现问题。

       （3）SQL语句能拆的尽量分开写。我在看一些人写的sql中，发现有的sql语句真的是看的都头大，一个sql语句有十来行，关联了不下四个表。虽然能实现功能，但是对后期的维护以及自己去看等，都是很影响效率的。因为我们现在知道什么意思，并不代表以后知道是什么意思。而且在维护人员进行维护时，他也不知道你到底要干什么，不知道怎么搞。所以我们在写sql语句时，能拆的尽量分多次查，但这也并不是绝对的，还要看一些场合下是否合适，看具体情况来定。

        （4）多询问。主要是我们在写一些功能的时候，用到了一些其他技术，比如rabbitmq等，如果我们自己搞，那么或许还要花费一些时间，这时候我们可以先问一下是否有此功能。就比如我在前段时间写限流时，写到一半，发现工具类中已经提供了这个功能，那么就不必在花时间自己去写了。

三、不足

1）思想方面

        （1）心态的调整。有些情况，我们的心态可能会处于一个低谷期，就是感觉自己不知道的太多了，或者是写完这个功能不知道该干什么了。这时候我们应该去回想还有哪些方面要改进，或者还需要学什么相关知识等，不要使自己觉得不知道该干什么或者感觉什么都不会，有心而无力。其实这也是对自己心灵上的一种提升和进步。

        （2）对事情的积极性。这段时间，发现自己很大一部分时间都是在不停的搬砖，没有用到什么新的东西，使得效率不是很理想。

        （3）划水。有时候去的比较晚，浪费很多时间，这也是一种不好的现象，应该改正。

2）工作方面

        （1）知识点的缺乏。在此期间，发现很多知识有的忘了，有的几乎都不会，必须要补充扩展。比如redis，现在只会在springboot中去用，而没有去系统的学，rabbitMQ跟这个情况差不多。数据库中还有很多东西需要去学习，不仅仅是普通的CURD。git 还需要在学习，就比如昨天合并个冲突时，合并了半天，然后退回去两个版本，最后都没搞定，真的当时有点心态崩了，因为代码都没了，最后通过idea中的history找回来的，git 的用法也不是很熟练。

         （2）交流不够好。就比如在写rap2的时候，前后端都没有统一好参数等问题，使得后期调用的时候出现很多问题，而不知道怎样去改正。

四、经验教训

综合以上，结合了三点需要以后改进的问题。

（1）知识的储备还非常欠缺。还需要学习很多知识。这个知识我觉的应该去系统的学习，而并非是参考几篇博客就能解决的事情。

（2）沟通交流。在项目刚开始时，就应该跟前端交流好都需要干什么，具体怎么做等，需要花费一些时间，而不是表面只说一下，这样后期处理的时候还会遇到很多问题。而绝大部分是因为前后端没有更好的交流。

（3）明确提交代码。提交代码后，一定要确保自己提交的是自己想要提交的，而不是提交后才发现提交错误，出现很多不该出现的问题。

五、计划以及努力方向

1）在这次项目中，发现自己还有很多东西需要去学习。

近期学习规划：redis学习，git的补充以及算法和专业课的学习。

2）通过这次项目，我其实已经感觉对于前后端，更比较趋向于后端，在写后端的时候，虽然碰到很多问题，但是并不是没有任何思路，而是可以通过自己或者百度等解决。打算着手去写后端。