平安科院项目总结

到目前为止，平安科院项目算是到了尾声，这是我参与的第一个正式项目。从正式排期到现在一个半月的时间，项目的战线拉得意外的长，其中也是出现了很多情况。因为是在半成品环境的基础上的项目，并不需要重新搭建环境，主要的任务就在于业务开发，我在本次项目中主要是负责后端的一些不太复杂的业务接口，例如加密解密，查询和超管添加、密码重置这几个。

1、收获

在项目中最直观的就是技术方面的收获了吧，之前一直都是自己写一些小的东西，并没有接触到多人协作开发。及时最后自己写的前后端分离的小项目，也是由于前后端都是自己来完成，很多地方都是欠缺考虑。在这次的平安科院项目中，熟悉了多人开发的大概流程，以及其中需要注意的很多地方。因为是第一次接触正式项目，无论是在技术上，还是思想和工作方面都摸索到了不少收获。

1.1 技术成长

 第一次参与多人协作开发的项目，学到了使用git的基本使用流程，也是切实体会到了git的便捷之处。由于是前后端分离项目，少不了要学swagger的使用。在项目中才接触到了hutool工具包的使用，到现在对hutool的大多数功能还是没有尝试过。因为在开发规范中约束了自定义sql要完全使用注解来完成，学到了在mybatisPlus的注解sql中通过script标签实现动态sql的方法。了解了java8的stram流的几个使用方法，还没有了解完全，计划后面花时间，学习并总结一下。比自己写小项目时更加熟悉了枚举的使用，了解了lamda语法。虽然都是些零碎的知识点，但是也都是平时我所欠缺的地方。

1.2 思想成长

相信自己，在刚被安排到项目小组里面参与后端开发时，其实是很忐忑的，觉得自己很多地方都还不行。害怕自己在项目中会出现代码冗余，规范性不足，bug一堆的情况。在开发初期我表现得确实不太行，一个接口写了两天，在项目中期才发现，sql逻辑还是错的。但是，经验和能力是在项目中收获的，大家也都是从不会到会的，无非就是那些逻辑。接到任务的时候应该去思考该该怎么实现，从哪入手，遇到问题就去问，千万不能自我否定。

对分配给自己的任务负责，了解自己的能力，安排好时间。在最初排期的时候，遇到的第一个问题就是排期不准确。不了解自己的能力与任务。虽然当时觉得尽可能给自己安排了足够的时间，但是还是逾期了很长时间。大量的时候花费在了熟悉项目和了解不熟悉的知识上。即使到现在可能如果再有项目，我给自己排期可能还是会出现不合理的情况，但是总的来说要比当时一点规划都没有全凭感觉的状态要好很多。

要多问，更要带着自己的理解去问。首先要敢于问，出现不懂的地方，或者是又不明确的需求都要敢于去问。但是问的前提是自己再问之前去研究过这个问题，并且有自己的理解，问的问题具体到点，而不是问一下怎么办，为什么这种问题。

注重总结。一直以来，我都知道我自己是一个不擅长总结的人，这也是我学术不精的一个比较重要的原因。但是在项目中会遇到很多问题，也会遇到很多之前没有接触到，或者是看到过但是没有用到过的各种知识点。如果不总结的话，过不了多久就会遗忘，做完一个项目如果没有总结的话，收获几乎可以说是没有。在这次项目中，我的总结还是不足，不及时。一些知识点的总结，只是在每日问题中记录下来，在后来很多个知识点统一总结的，其中可能有一些没有记下来的，现在也想不起来了。但是还是要把自己还记得的收获全部记录下来。

1.3 工作经验

在正式开发之前要明确需求。需求不明确的话，后期大概率会有需要大面积修改的情况。大面积的修改往往是最浪费时间效率最低的。在这次项目中我就出现了，需求没有了解明确，按照自己的理解去写业务，写完以后才发现功能与需求不符合。几乎就是老白干了。并且在项目正式开发之前，关于业务需求，以及其中会出现的难点，讨论了好几天。还记得当时我还有些奇怪，为什么要一遍一遍的确认业务需求，没想到的是，及时前期做了挺充分的准备，在后期开发中仍然遇到了之前没有考虑到的问题，可见需求明确的重要性，毕竟用户需求是一个系统的根本。

要与项目成员多交流多沟通。在开发初期，我是在906，而小伙伴在910，他课还非常多总是见不到，并且我第一次做这种协作开发，也不太擅长业务交流。导致我们两个的代码在一些功能上有重合，产生了冗余，并且service层的代码看起来很杂乱。并且由于交流不及时，开发效率也很慢。在后期大家坐在一张小桌上，一有问题就及时交流，开发效率快了不少，产生问题的几率也是小了很多。

在下手之前，要捋清楚思路，最好能明确的画出来。开发过程中，每一个接口需要走哪些流程，会出现多少种情况，每种情况相应的处理方式都应该大致考虑到，在完成接口时才能避免出现各种问题。在我些查询接口时，由于是多表查询sql语句挺复杂的，在没有彻底捋清思路时就妄图写好sql。可想而知后面写好以后，出现了不少问题。最终还是和小伙伴一起把各种情况画在了本上，并且通过多条sql分情况实现的，所以还是交流很重要，思路也很重要。毕竟自己的话也是可能会漏掉一些细节，这个时候就需要寻求外援。当各种情况清晰的列在本子上，按逻辑写好的功能基本不会出现问题，这样即使在功能实现了一半被打断，后面继续编程时逻辑也不会混乱。

2、不足

2.1 知识储备不足

在这次项目中更加清楚地认识到我的编程水平和其他人的差距，例如rides，token与jwt还有很多地方都掌握的还不够。还有数据库的sql优化能力不行。对半成品环境的了解也很少，而且摸索这个环境也很吃力，到现在对环境的掌握也不多。在编程的过程中，有一些在学习时学过，但是没怎么应用过的知识，在项目中应用时还得重新学习一遍。对redis，token这些知识学习的不够，在框架的基础上还能勉强使用，但是具体了解并不深入。

2.2 工作问题

没有写好接口文档，并且没有完全根据接口文档来开发。在正式开始写项目之前，需要在rap2上写好自己负责的接口的接口文档。当时由于对需求的了解不足，而且各个字段也没有按照数据库的字段来。而且在开发过程中还没有完全按照接口文档来，导致了后期前后端在交接时出现了不少问题。

没有测试用例，开发后期测试困难。这次开发项目，从一开始就使用swagger测试，完全没有写测试用例。在前期写单个接口时，使用swagger进行测试还没有发现什么问题。但是前后端交接以后，所有的接口基本完成，但是这个时候就是bug层出不穷的时候了，使用swagger测试不够直观，并且很繁琐，因为一些接口并不是拿来就能调用饿，需要的参数可能需要先由其他接口生成在调用。就容易出现改bug几分钟，测试几小时，各种权限情况测试下来，确实花费时间不少，效率极低。

对数据了解不足。在项目中数据库的每一个字段都需要了解其作用，看起来是很简单的事情，但是在字段很多很繁杂的情况下，就很容易出问题。就在这几天因为对权限表的id和level代表的意义以及作用不够了解，在开发过程中做了不少白费功夫的事情。不清楚改用id来识别身份还是level。最初根据id来识别身份后来因为添加了其他需求，大面积修改将id识别修改为了level识别。结果学长告诉我们level只是用来标识权限等级的，用level识别身份会出现问题，只能重新动工在修改回来。每个字段一定有它的功能，在使用之前一定要了解清楚，否则可能会出一下不可预料的问题。

环境认知不足。在本次项目中，因为对使用的半成品环境过于不熟悉。在开始的时候对一些环境中本来就实现的功能，进行了重复开发。不清楚环境本身的缓存机制，在加密解密过程中也是遇到了不少坎坷。即使到现在，开发的功能与环境中的一些功能仍有一些冗余的地方。

3、后期规划

经过这次项目发现了很多知识盲区，后期计划把知识盲区先学了。包括redis，token jwt验证，java8的新特性学一下，还有找一套设计模式的视频看一下。感觉和他们在一些问题的处理上境界跟不上，设计模式还是必须要学的。

说是接下来平安科院会有第二版，但是还是想接触一下前端开发。一方面巩固一下我的vue知识，另一方面对比一下自己在前后端的状态，为以后的发展做准备。