目录
写在前面
新公司入职一个月了。
同刚毕业入职一样，带着恍惚、憧憬，以及对未来、对新伙伴的期待心情，入职了。
全新环境，全新框架，全新制度，全新朋友……什么都是全新的，只有自己还是旧的自己。
所以，很多东西需要时间来磨合，需要时间来融入。
老规矩，每当迎接一个挑战的时候，不管是搞定了它或者是被它搞定，总归是要做一个总结的。
好了，本文不是来煽情的，是来总结问题的。在我看来，这次新工作的交接，其实有太多的问题了，引以为戒。
开发背景
springboot+vue（前后端分离），我做后端。
我没做过前后端对接的项目，刚开始以为应该自己会很容易接手，实际上却是眼高手低，结果真的仅仅只是差强人意。
遇到的问题
开发规范
开发规范不用说了，命名方式、代码风格、注释风格、日志风格等等等等。
每个公司规范虽然大差不差，但是仍有细节方面不一样。
新公司新框架，规范问题更是需要自己来调整，有时候更得需要打扰公司前辈来协助。
mybatis重复造轮子问题
众所周知，mybatis一个痛点就是每个新功能的增删改查都需要创建一套Controller、Service、Dao、Domain、Mapper，尤其是Domain和Mapper，全都是重复造轮子。
我刚入职，光一个功能的增删改查，加上修改一些开发规范，用了两天时间。
于是乎，我搞了一个自动生成增删改查代码的小程序。
手写简易的MyBatis代码自动生成器，适配自己的项目，再也不用重复造轮子了_秃了也弱了。的博客-CSDN博客
空指针
空指针问题非常严重且致命！
不管是对象、字符串等等，执行任何一个操作的时候，都要考虑空指针问题。
最最离谱的一个空指针问题就是，int数据类型拆箱装箱时报的
Integer i = null;
int j = i;
类似这样，实体类A中字段类型为Integer，实体类B中字段类型为int，结果A中字段为null，赋值给B中字段，就报了空指针。
SQL条件
多表关联时，一定要注意sql条件！缺少任意一个条件可能就会导致致命的问题！
尤其是涉及count、sum等等，还需要注意null的字段。
做管理系统，查询性能真的很重要，注意sql的关联条件，注意大表驱动小表的定律，注意防止索引失效，注意子查询的效率，注意java循环中尽量不能使用sql等等。。
以及自己 刚学到的
mysql实现upsert（没有就新增，有就修改）_秃了也弱了。的博客-CSDN博客_mysql的upsert
MyBatis的collection和association的使用详解，我们都懂啦_秃了也弱了。的博客-CSDN博客
if判断要加足
不管是空指针，还是一个方法多地用，都需要用if来隔绝一切可能会发生的坏事。
不要将某些字段某种场景并不会用到，也让它执行到！因为你不知道它里面藏着多少坑（如上拆装箱空指针问题，一种场景有值另一种场景为null，谁能想到一个实体类中的字段，竟然用了基本数据类型的……）。
测试要充分
由于时间比较紧张，中途又修改了部分重要的需求，所以时间更加紧迫。
一直在赶进度，测试非常不充分，都是公司前辈帮忙测的，所以问题非常多，改了测、测了改，磨光了自己的耐心与信心。
其实bug出的多，不光对接我的前端头疼，我自己也很头疼……
所以，发布一个接口的时候，能多测测就多测测，不要一味的图快，正确性真的很重要。
接口设计要考虑好
这边都是接到原型，后端出接口设计，前端来对接。
所以，后端接口要设计好，缺字段少字段的，联调的时候也会很浪费时间。
同时也要把握好自己的开发节奏，不能手忙脚乱，出了问题或者被催工之后，一定要冷静处理，拆东墙补西墙的做法不可取。
提交代码要谨慎
提交的任何一句代码，都不能影响主流程！
因为项目中打印的日志全都是sql语句，没有controller入口日志、没有uri日志，除了mybatis的sql日志，其他什么也没有。
所以在服务器上查日志是一件很痛苦的事情。
于是，我耍了个小聪明，使用AOP拦截了所有的Controller，打印了一下入参、出餐、uri、登陆者，简单测了一下就提交了代码。
问题来了，测试环境直接崩溃了，应该是部分请求的参数解析不了，大量报500错误，就让人很难堪，最后紧急修补，才导致了这场闹剧。
所以！提交的代码一定要谨慎谨慎再谨慎，千万不能影响到主流程！
心态很重要
不管遇到什么事情，我相信一个成熟的人永远第一时间是选择担当+面对，而不是逃避+偷懒。
就算再难再复杂、再不熟悉的事情，其实只要用心，一切都会迎刃而解。
心态很重要，沉下心来，勇敢面对挑战，积极面对自己的不足，微笑面对身边每一个可爱的人！
融入团队而不是让团队融入你
一个软件的产品，总是会有一个迭代的过程，而自己也只是一个小小的开发人员。
刚拿到公司代码权限的时候，自己就已经将原公司的自己代入了新公司，不禁在心里发出了疑惑：为何定时任务不与业务代码分离开？为何很多功能要自己开发而不是用早已成熟的开源框架？为何这样为何那样……当然也有惊艳的地方，感慨公司的架构真的很厉害。
也许公司有自己的考虑，也许是自己多虑了，其实没有完全了解一件东西的时候，是没有发言权的，那就让新公司、新的小伙伴、新的我一起进步吧~
希望不会磨灭自己对技术的热情与初衷。
写在最后
有错误，我接受，知错必改。
有挑战，我也接受，来者不拒。
有喜乐，同样接受，工作亦是生活。
最后，愿一切都好，顺利转正。
