就是代码写完了,通过了测试,但是自己有时间上线前还是会反复检查是否有问题.

工资不值得我焦虑（

按流程来，准备好应急方案。这俩搞好了锅就扣不到你身上了

代码和人总有一个能跑

拿奴才的工资，操皇帝的心

多少钱干多少事，又不是你自己的公司

前端没得焦虑，后端代码是有绝对的对错的。前端把接口对接上就没有对错之分，顶多算是页面不好看

一般来说，真出次事，自己有经验就习惯了，毕竟测试都通过了，还能找到开发，那要测试有什么用。

做后端，测试覆盖率到位，每次修改都有相关测试代码，一般还是比较放心的。

单元测试呗，你把覆盖率提升到 100%，就不会焦虑了

代码层面：多输出日志，多写注释
业务逻辑：钱和订单类的逻辑多注意（拉上产品和测试一起扛），关键环节有降级或者屏蔽开关（一个 true/false 变量）
上线运行：紧盯运维要监控数据图，及时发现及时补救

都通过测试了还焦虑，说明测试问题很大啊

刚工作半年，总担心有问题。我发现代码写的越多，bug 肯定是越多的，等再多遇到几个 bug ，我估计就释怀了。

每次都出问题，自然就不焦虑了

这种焦虑的心态适用于所有方面，每个人都会犯错，是个人就会犯错，适当焦虑谨慎挺好的，不过于焦虑就好，试着把犯错的焦虑丢给测试吧，测试可以把焦虑丢给人性，大厂的技术文档也是会有错别字的，火箭也是会爆炸的，世界是个巨大的 xxxx ，是没办法要求自己不出错的，有时候经常越紧张什么越来什么。

做好灰度流量控制, 有问题及时回滚, 预先想好数据修复方案. 上线后及时验证

出问题就改啊 不然搁那弹 500 吗

用正确的框架，正确的语言，写正确的代码。

不在乎就行了。

会烦燥但焦虑是还好 工作是工作
选用好的技术是很重要的 但工作就不要多想了
工作上还很多杂七杂八因素 选择权很多时候也不在你身上

老实讲现有流行技术太关注细节了 用起来一点也不飘逸

还有无用的设计是满满都是 有更好更懒惰的解决问题方式不会被采用的

只要不写单元测试，程序就同时处于正确和错误两种状态；
遇到线上事故时就宣称"我的本地环境没问题啊"，熟练运用"网络波动""缓存异常""用户手滑" 三大免责三连

单元测试都没用的 程序从入口到运行会经过很多东西 只有掌握每个环节才能控制不利因素到最低 否则就是增加成本 然而分权本身就会增加成本 鱼与熊掌不能兼得 独裁与民主各有利弊

对问题分级，最坏可能性如果也不过如此就随他，如果可能导致严重灾难仔细一点不是坏事

面对未知仔细？苦力活被转移到你身上就不会这么觉得了 什么都要就是有人要犠牲

什么级别的代码，自己心里是有数的，如果是支付系统，账目一定不能出错，如果是个管理系统，原始数据一定不能丢失，守住这些底线，其他错总能弥补，就不用太担心

这不是废话吗 要是事情都象想像的那么容易这世界就不是草台班子 每个人都知道什么成果是最好的
但要达成你说的目标不是单纯你把标准列出来就可以的了 我一直觉得这种言论过于草率乐观

1:写的越多，出错的可能性就越大，接受吧
2:多打日志，起码错了能快速找到问题并解决

写了一个看门狗，定时检测和定时重启，重启是最好的 GC ，HAHA

不写代码就不焦虑了

刚上班吧，过段时间就好了

单元测试、E2E 测试来覆盖， github.com/LinuxSuRen/api-testing 这是我开源的 E2E 测试工具

把业务建模在类型系统上, 让编译器替你检查出大部分问题.
你要是还焦虑的话, 说明你是先天形式化验证圣体

你多发生几次问题就不焦虑了

跑去做了测试。
之后又被公司调成运维。

我是上链路追踪埋点 + 钉钉通知