写在前面

来公司也半年多了，总是不仔细，要么发邮件少东西，要么口头听架构师吩咐也会漏。代码bug率也高。
代码质量我自觉是在越来越提高了，也开始使用单元测试了，这非常关键。但是还是不够仔细，而邮件则是依旧少文字，少个注意事项啥的。发邮件出脚本给别人用也是会少，最后让领导来兜底。
虽然都没涉及到钱的业务，但是就这，领导会放心交给我吗？我必须吸取教训，进行改变了。

具体教训

yida要更新的配置未检查仔细，有一处错误！所以需要再发1份邮件。 <- 被测试吊
详细说明:

由于这个需求是不走测试流程的，是直接从开发到生产的，所以只能我自己测试好，检查配置好。
所需做内容其实是将页面配置复制到配置文件即可。
然后我自己是这么测试的，将生产的内容复制到开发环境，然后复制开发环境的页面配置到开发环境的配置文件中，然后我开发环境测了下正常的。我就将开发环境的配置文件新增内容复制到正式环境的配置文件了，便发邮件上线。
结果上线后发现有1处不对，跟生产环境的页面配置对不上！
原因: 虽然理论上从生产复制页面到开发环境，页面配置是不会变的。但是就是有一处是变了。
复盘解决原因: 再来一次，**必须上线前直接检查生产环境的页面和我生产环境的配置文件是否相同**，一一对应！

yida服务上线要实现的某个功能未实现!!
详细说明:

 与上一个教训是一个功能，但是这要拆分开来说。因为这个纯粹是实力即不仔细问题了。
要实现的功能是一样的，上面个是配置错了。然后这个功能配置是对的，但我开发环境根本没测过！因为我口头问了下领导说就加下页面配置就好了是吧，他说是的，然后我就直接上线了。最后我被吊说不是我这么测试的，因为我根本没测试。
我是测试了其他功能，但这个功能我确实没测试。原因我上面也说了我就口头问了下领导我就放心了。坑！所以，这个功能我开发环境也没测，测得话有问题发现了我虽然不知道怎么修复但问领导就好了。

原因: 这个功能还要加1个额外配置才行！
复盘：要加额外配置我确实不知道，是我自己实力差了，这个功能这个服务代码我全能看，应该自己早掌握的。
但首要原因还是我不仔细，以及犯重复错误，口头确认就自己不测了，但责任全在我这。开发环境必须自测，甭管其他人怎么说。
复盘解决: 开发环境必须所有功能自测。

yida服务上线前必须自己打包下
详细说明:

还是前2个一起的功能。但这次是我代码内容导致的，严格来说是开发流程导致的。
当然还是一个原因，没有测试流程，不然很好发现。因为测试无法打包。可惜我没发现，直到上线前一天晚上11点多，我准备睡觉了忽然被打电话说我发的邮件内容服务无法打包。而且我还不知道原因。
最后知道原因我是可以狡辩，因为这次上线的功能是很早就开发好了的(穿插了分支)，当时我自测是好的，然后快上线时候我又单元测试了下，还发现了1个小bug，所以大意了，准备直接上线。
殊不知，我如果去jenkins点一下按钮部署到开发环境，就知道无法部署了。

原因: 服务依赖的某个Jar包我没depoly，忘记了。
复盘: 不管多小的功能，都要严格自测。如果能开发环境再去测下接口，测下功能是最好的。所以不仅仅是自测代码功能，而是能否成功上线也要自测。
复盘解决: 部署到开发环境看功能是否正常。

[代码bug]线上问题，写的监控功能不正常。一直在监控数据。
详细说明: 这是我第一个线上问题。而且功能还是我改过多次代码bug。被测试说了“这个逻辑”.

原因: 2个date类型的变量我用的判断是否相等的逻辑是 ==。
复盘: 必须单元测试，就像马丁福勒说的无论多小的改动他都是编译测试然后提交代码。这就是重构。这次我就是改了后没通知测试去测试，不然也是很好复现的啊。
第二点，不要指望别人在第二轮测试的去测试我的功能。而是要自己在严格检查代码。虽然这个的问题我只检查代码也不会，但我首先要去做。我不就正是没有自测运行的代码吗。

复盘解决: 多小的改动，都得单测。没有单测，也要自己造个数据看下是否跑得正常。否则我以为只改动很小的内容结果会变成线上大bug。
[不仔细] 出sql脚本给别人用，少2行语句。
详细说明: 就是有6个表要改，共要出8个脚本。6个是一一对应修改单表内容的，然后额外2个是统一修改6个表的内容(脚本7)、修改其他表内容(脚本8)。
结果我就在额外2个脚本上出问题了。
因为很复杂，6个表中有一个表有点问题，然后还发现6个表好像是每个表要修改2个内容。所以我是先把5个表的脚本出好，及脚本7（只统一修改了5个表内容）。所以此时我脚本7已经少了直到最后。
然后脚本8我先没出。我先解决脚本1的问题，解决好了。但我忘了每个表要修改2个内容。所以出脚本8又少了啊，我浑然不自知。
带来后果:领导帮我兜底，本来7点多一起聚餐的。他和测试直到9点多才来。耽搁了至少1小时。
原因: 详细说明里有说明。我也没有全部检查，只详细检查了前6个脚本。后2个脚本大概看了下。
复盘: 发邮件上线任何事情得检查3遍才行了。正如我现在提交代码及合并分支很少出错是因为可以检查2遍。而出脚本这个我却并没有。虽然有原因是急着去聚餐，但是也不能影响我这个原则。
必须坚持这个原则了！这次如果检查了3遍，我第一遍肯定能发现脚本7有问题！因为很显然少1个表。
脚本8虽然一遍不一定能检查出来。
所以，必须全部检查！并且检查3遍。
[大意]写接口文档-"加班"也没能完成
详细说明: 周日独自来加班把接口文档写好的，因为周一得评审接口了，然后我又大意了，加上自己也根本不想加班。所以看了看以为不用写多少，可以复制别人，于是我就半小时磨了会洋工就回去了。结果可笑了啊，接口根本不能共用的。是我没仔细看清楚了啊。
日期:2022-01-23
[大意/托大]上个版本需求少改动2个接口
详细说明: 上个版本改动了很多接口，有2个表是加了1个字段，这个字段需要有初始值但我们不是用mysql的默认值而是在新增它时给1个。所以对应的新增查询修改接口都得适配下，这我改好了，然后还有对应的增删改同步接口，这个所谓的同步接口则是提供给第三方用的了，我不是太熟，且感觉原先人写的代码真low，重复代码太多。我便没加思考，也不怎么想改动它的代码，更不能重构，我知道重构了出问题肯定在我。所以我就只改动了同步接口中的新增接口，保证给这个字段赋1个初始值。
然后问题出现了，上线1段时间发现涉及到同步接口那些记录的新增的字段都为null了！
我便知道问题了，肯定是修改的时候置空了。
原因: 确实是修改的时候置空了,原先的人写的代码确实low。接口传参就是这次要修改的参数，但是你如果没有传某个字段，则认为你传的是null，去数据库里改为null，这便是问题。
复盘: 是托大,但归根结底原因是我不会思考，且不能再用业务不熟来当借口了!那我去大厂做不好1件事哪怕是小事，可以以此为接口吗？其次，这原先别人写的修改逻辑是LOW,但我得抓住本质！
收获: 看到其中1个表的相关接口写的shit一样，逻辑都写在ctrl，我不仅不高兴看，而且这次修改的时候也很难发现要把回写那个新增字段的代码加在哪里。
这带给我重构的启示是，真的需要DTO。
具体逻辑是这样的，可能原先就是1个单表的增删改查，很简单。所以修改接口就是接口传参实体类直接转化为数据库实体去更新了。就可以了？NO，中间真的需要1层DTO。就算一开始逻辑很简单。
但后面现在对参数的各种校验，及这次新增的字段，我就可以在DTO那个类中去判断必须该字段不能为null，否则不去保存。事实也是这样啊，公司业务情况下那2张表的新增那个字段不可能是空的。
日期:2022-02-09
后续: 得出脚本修复老数据！还得贾克斯想到的。
然后我写的sql还是有问题，update语句中的set各个字段要用逗号拼接啊！并且查询是否为空要加上or x字段 = '' 2022年2月10日09:22:43

[急切忙于思考且未对比]项目打tag没在master分支上打

发生日期: 2022年2月22日
记录事件: 2022年2月22日15:43:16
详细说明:

jax又反复强调了打tag啥的,我不以为意，我**早就**记得了，要pom版本号加1，合并代码。结果这次真忘了，jax一问我才回答没合到master分支上，且我打tag是 从开发分支上打的。
**一说开发分支我顿觉醒悟，确实是大问题啊**，虽然这分支是上个版本的，理论上和master是一样的。但终归有风险。
看了下我以前打的tag都是从matser上打的啊！

[又是未思考]出的1个简单接口文档不行

发生日期: 2022年3月4日
记录事件: 2022年3月4日20:24:05
详细说明:

早上一来jax就和我说我昨天出的接口文档要改。确实，首先为什么是post我完全忘记了。
其次,返回结果确实返回个{"success":true}挺搞笑的。这样一来，我认证失败有2种返回结果了，确实前端那边解析就麻烦了。要统一啊！我也不辩解说我是抄的前面的人。确实啊！他做了是他的事，我该思考到底那么做有没有用！被叼是被d了，挨着吧。总归是我没认真思考。其实不止2种，因为成功的那种我都没返回code码，就返回了data。这个是文档写了，但我代码没按照那个来。
总之，是我太急了，但总归不管时间，这点小事我是没做好的。
另外，这个接口到底什么逻辑我还没搞懂。我的任务就是复制一下别人接口！

update语句不能是and！

11、今日bug今日毕，必须提问(太考虑他人是不对的)

11.1详细说明

2022年3月23日21:15:20
起因是我负责的页面今天有1个很简单的bug，然后其他两个同事的页面也会有这个问题，测试也都提了bug。
我就放松了，想先看他们怎么改。
于是拖啊拖，拖到5点多没发现他们改，我自己本来也打算肯定是要改的。
但改好后发现我改的出问题，直接点就是说改不好这个bug了。
我发现也不一定是测试提出的改动点是对的，要跟产品确认才行。
我向来不会下班后问别人，于是没有问产品。
晚上9点了，jax忽然直接钉钉问我这个bug怎么回事。因为今日工作计划上我写的bug解决量是4/5，其他人是n/n也就是都解决了。
我不怪jax，肯定是cto也就是领导问的。我也秒回了jax。
但我分析了下:jax他不管的，他直接问的。

11.2复盘

2022年3月23日21:20:13
那我为什么还要考虑其他人呢？考虑产品，所以下班后不问他最新需求改动，结果我自己吃亏。
虽然总的还是我实力不够，bug确实没改对，但我明天还是不能改对，还是得去问产品。既然如此，我为什么不今天就问。
还要谴责自己的，就是懒。我下班前就改好发现我改不对就会早点问产品了。
这里再说下，我也不知道其他2个同事怎么改的，反正他们都n/n了。我也懒得看了。
当然，还有最重要的1点是我心态又变了，想的是反正会TC,所以不好好工作，是大忌啊！

12、没算好就指出不扣餐补(不思考即话出口是不行的！)

12.1详细说明

2022年4月12日09:59:35
烦啊！zsj花了很长时间说这次疫情影响，我们普通员工大概扣了6%左右，我算了下差不多的但没算仔细，因为一开始我还以为就扣了个餐补的钱呢。我也知道了他们经理级别工资是真高，至少是我2倍。其实我对公司完全理解的，毕竟jax也说了3月份就是一直亏损，确实，5月份如果也不好，就1个季度没了，那可能都要裁员了。
jax问我们有什么想法，A,B都很虚伪地说没有。我就应该跟着他们说的，我想说的是是当做扣餐补吧，结果jax反复追问我餐补这消息从哪里来的，他可能以为我说的是我餐补也被扣了。
烦！

12.2复盘

2022年4月12日10:03:01
后悔，要么直接不说，省的多BB。要说之前也要在脑海里想清楚啊！表达意思错了。且追问时候我不能继续理清楚餐补就财务告诉我的。

工作中吸取的教训(持续更新)相关推荐

有限元分析中的常识（持续更新）
有限元分析中的常识(持续更新) 介绍一些学过有限元的人都不得不超级熟练掌握的基本常识. 文章目录有限元分析中的常识(持续更新) 通用符号基本不等式 Cauchy-Schwarz 不等式 Hölde ...
暴雪应该从《争霸艾泽拉斯》中吸取什么教训？
转眼间,距离<魔兽世界:争霸艾泽拉斯>最后的8.3版本上线已经过去了几个月的时间,整个系列的下一部资料片<魔兽世界:暗影国度>上线的日子也逐渐接近,在那之前玩家们能做的事情也仅 ...
Linux快速工作使用指令经验（持续更新）
文章目录 ls出所有的文件 cp不要提示Y/N Devic or resource busy tar -zxvf解压本篇文章是记录本人在工作中Linux的使用cmd,持续更新. ls出所有的文件我 ...
从Bitly构建分布式系统中吸取的教训
在五月的Bacon会议中,bitly应用开发主管Sean O'Connor 讲解了bitly开发人员从构建一个月处理点击量60亿的分布式系统中吸取到的相关教训. \u0026#xD;\u0026#xD ...
工作中的自我反思[实时更新]
本篇将一直记录自己工作中犯的错,需要注意的点: 1.class,click等需要命名的地方,命名的名字一定要注意.例如,上传文件的点击事件,它的标签为你就不要取名为upload了.这样当你想要快速找到 ...
工作中常见问题汇总（不定期更新）
基于工作中遇到的一些问题,总结一下经验: 单双引号的区别大家都知道 php 里双引号可以解析变量,单引号不可以,其实换行符等特殊情况也需要双引号处理. $aWhiteIP = explode('\n ...
日常工作生活中的做人做事道理[持续更新ing]
1.凡是预则立,不预则废 2.不能用特殊案例说明事情本身的发展规律 3.任务不能拖,需主动出击,想方设法完成 4.工作要有细致化的沟通和安排 5.解决问题和安排任务可以逆向思维的去想 6.问题要举一反 ...
mac电脑循环次数多少算新_ARM架构电脑之路，苹果需要从微软Surface ProX中吸取哪些教训？...
如今,大家都知道苹果已经铁了心要彻底转向ARM架构处理器,那么在这过程中,苹果有什么地方需要注意的吗?要知道,其实苹果并不是第一家提供采用ARM架构处理器的电脑产品.微软在这几年也在积极投入到ARM架 ...
从 Notion 分片 Postgres 中吸取的教训(Notion 工程团队)
https://www.notion.so/blog/sharding-postgres-at-notion 今年(2021)早些时候,我们对 Notion 进行了五分钟的定期维护. 虽然我们的声明指 ...

工作中吸取的教训(持续更新)