1、一次写代码时的失误
那天是晚上，我们课题组内这个项目团队的负责人（也就是我们的小领导）需要一个实现方法要我来写。要的感觉对我来说很急，我就很仓促的写完了。
关键是写之前，他又站到我旁边，看到我本地代码有变蓝的，也就是那几个配置文件改动了，他就一顿对我狂喷，说这些代码你怎么能乱改呢，你知不知道这些是啥你就乱改。可关键是，我就改了一下生产环境的和开发换的服务器ip,因为我要用远程的，而且这几个配置文件也没有上传到git上，只是在我本地改的，我自己用。反正最后我又给改回去了。
【这点的结论是：如果你觉得是对的，但你感觉可能会遭到上司的反对，那么你最好的做法不是按照自己的做，而是按照上司的习惯和要求做，不要自己没事找事】
然后，在这这种心情不好的情况下写代码，难免会出漏洞，因为你的思想受到了情绪的影响。再加上上司要的紧，我写完也没重新运行就提交上去了，这导致的结果就是，当团队另外一个人下拉代码后，发现运行不起来了。原因是新写的实体类中，有个Date类型的写成了Data类型，导致无法跟xml中的sql匹配，因此运行不起来。然后，他又看到说我的方法没有写进接口里，而是直接在impl中写了，可问题是，他也没跟我说是在哪里用的，我以为他只是在impl中有用到，然后又是一顿狂喷，说我怎么不写接口。
【这点的总结是】：
写完之后，一定要重新运行，启动之后，认真测试好接口再提交。还有就是，一定要问清楚需求是什么
2、第二次是要直接在库表中添加数据的操作
有天接到甲方的通知，要直接给他们库里添加写数据。他们把注册的账号和密码发了过来，我对照着库表，一点一点找这个账号下的用户id，然后发现他的企业信息没有，我就给它绑定到了新的关系表里，这一绑，出错了，导致第二天他的几个服务账号直接登录不上。然后就把情况反馈给了我的上司，然后上司就把我叫过去，又是一顿狂喷，说了很多，虽然那时候，我已经发现了错误的原因，就把关系表里新加的那几条数据给删了。但是，后续又加的别的关系表里没有删。上司发现后，就全部给删了，我前天晚上做的工作相当于白做。
【这点做出的总结是】：
如果某一块不是你负责的，你就不要瞎揽活，就算是让你做，你也应该找负责这一块的人先沟通交流好，或者告知上司这个情况，而不是自己扛下来也不说。主要是，如果事情做成了还好，做不成会死得很惨
3、第三次也是有一个需求要把那个字段的数据放进去
这次，我先在navicate中写好了SQL，然后复制到xml中做了简单的微调，接着就是写查询抛出类，检查一遍无误后，就启动运行了。运行后发现没问题，并且还直接开了前端，测试这个地方有没有加进去，测试也成功了，库表中的字段数据也有了，我以为这时候就是成功了。
关键点来了，这时候，突然发现我应该加个判空的，就在后面加了一个判空条件,前面那个是写对了，后面少加了一个非，因此就没走进条件内的语句。当时我也没再次运行测试，大意了，就直接提交了上去。提交后，我还在团队群内说了一声，上司特地问我测试通过了？，我说通过了。过一会，团队另外一个人测试，发现还是没有加进去，就有询问上司是咋回事，上司又找到我看了我的代码，我才恍然发现条件写错了。这才又改了过来，提交了上去
if (contractId != null “”.equals(contractId )) {
orderInfoVO.setOrderContractId(contractId);
}
【这点的总结是】：
如果你测试好了，在提交之前就不要再改代码的任何地方。而一旦你改动了哪怕很小的一个地方，也要重新运行，再测试通过了才行。
反映出的背后的哲理是：不要心存侥幸，否则一旦出事就凉了
4、第四次是生活中的错误
一天下午，团支部的群内，发出了通知，说晚上有党员推优大会，希望大家都尽量参加。就在实验室内举行。当时我看到了这个消息，只是一晃而过，没有记在心里
下午五点多的时候，室友发来消息，问我打球不，因为我前天晚上就跟他说了今天没事的话可以打球。所以就想着安排一下打球的事：吃饭、回去换衣服，拿球，打球。打到了快八点的时候，室友想去商场购物，说现在时间还早，我就犹豫了一下还是说去了，这时候打开手机，才看到有提醒说7点半要开会进行推优，顿时就不爽了，怎么把这事给忘了。然后室友让我把球先放到我们实验室，再出去逛商场。上电梯的时候刚好碰到了师兄们下来，问候了一句就上去了。
本来，我是打算打完球，去实验室在看会论文，写完文档，这下全被打乱了。
【这件事给我的教训】：
第一，在安排某个事情之前，先看看自己有没有这个时间点还有别的事情要做的和没完成的，比较一下重要程度，再做决定
第二，不要轻易给别人许诺，去不了就是去不了，不要硬抗硬撑，也不要委屈自己求全别人，因为这样有时候反而会让人觉得你这么好说话，没啥骨气和主见。最重要的是要学会说不，勇敢大胆的说不，敢于反驳而不是别人说啥就是啥