事故Review：如何在流程上避免错误发生
在19的年底来看我的确是遭遇了一次工作生涯当中的滑铁卢，抛开我自负和不负责的心态和操作来看，其实我只是一个无辜的受害者，更近一步即：我压根不会工作。为什么这么讲？让我们看下当时事故之后我的思考和现在我眼中的19翻车惨案到底有什么区别。当然，我会把2019年底的想法标注，并写明。至于没有明确说明的，那或许是错误的想法，也亦是少年的反思。
前言
在我看来，一个普通的业务程序员，他的成功是伴随着业务的成功而发光。当业务本身就没有什么亮点的时候，评判的标准又回到了衡量工程人员最切实的东西：稳定，高效，可扩展。而普通的业务开发人员往往能够做好其中两点就能Hold住大部分工作的内容，难题往往是如何劝说产品，换言之即学会忽悠。可能没人会喜欢说空话的程序员，但画饼一流的确很影响你做程序员，但却不影响你做一个梦想家和淘金的疯子。而业务的标准就变成了：如何赚钱。赚钱，往往就和字面一个意思：需要存在交易，需要存在价值传递。程序员在这个环节往往承担的角色是线上交易稳定的建设者，不出问题能够高效运转提高交易效率的保障者，以及接入多种交易场景的开拓者。往往这三件事情不会由同一个人来做。而我，在毕业半年之后，鬼神差使的做了一笔交易，谁知道上手就暴毙。
暴风前夜
毕业之后我负责的模块由原先的司导端的简单小工具逐渐转移向订单，中间夹杂着一些用户端数据的外露展示，但究其本身我一直在熟悉业务，也很少接触交易的全流程。只是在跌跌撞撞中了解的一小部分的业务情况。我摸清了整个公司业务的资金流向和交易类型。由于分配的活从来没有超出过能力范畴，基本上都是在能控制的范围内（实名感谢公司老人悉心照顾，有问必答，才能如此顺畅，加之带头大哥比较了解鄙人的水准，所以干的事情也很少出现问题）或许是这些平静让我对自己的代码逐渐有了信心，原来我也可以写真正的业务（雾，为什么不能呢哈哈哈）
逐渐增长的自信让我确信我能做好很多事情，当线上缓存奔溃之后依旧能改回来那些奇葩的SQL让我觉得以前那些天书般的代码也挺简单的，不过我还没有意识到，这样逐渐宽松的流程放养下我在渐渐改变。润物细无声，我自己都没有发现，我可能丢失了稳定特质的重要支撑：谨慎。的确一些惯性思维也成功带偏了我：比如我们做国外业务但是系统账都是CNY，提供的服务时间都是北京时间。
晴天霹雳
在过往的业务交流中，公司提出了正常需求和微需求的区分。而正常需求需要专业的软件工程流程：问题的定义及规划、需求分析 、软件设计、程序编码、软件测试 、运行维护。而细说的话，我记得大学的时候老师就说过：不论是怎样的程序都存在bug，当前前提是不认为确定边界。而软件测试作为验证编码质量和交付前的重要一环，包括冒烟测试到线上回归完成一系列操作，但在我司，微需求却只有一个对应修改功能的测试。这给我埋下了第一个大坑。
二月十八号我接到了一个非常简单的需求：打款币种自动切换。因为打款接口是批量的，我很快写出了程序。的确，前后改了十几行，不到二十分钟。我总是觉得很奇怪，一直对着第三方的文档发呆。产品来催我，问我什么时候能够交付。
在测试来回对我切换的程序进行测试之后。我在日志也没有发现什么异常。于是找我们老大合并代码、上线一气呵成。我甚至在上线之后瞥了几眼线上的日志，不过一切都很正常，线上的程序按照预期打印着日志，在这个空档我甚至顺便修复了一个死锁的问题（真的第一次在生产环境看见死锁，有另外一篇文章，专门写这个事儿~）而这件事就轻易的过去了，就和往常一样。
直到3-01的早晨10点。
“我们账户还有余额，为什么打款报错？有人能帮我看下吗?”
我的目光被财务的提问吸引了过去，看着反馈里的截图我熟练的打日志，几行字母出现在了我眼前：
---- 使用USD转账457，USD余额不足 跳过
---- 使用CNY转账457，CNY余额不足 跳过
---- 使用JPY转账457，JPY Trade Expection：提现金额Limit 15$!
看到这些日志的时候我脑中似乎闪过一个不好的想法：USD/CNY/JPY的钱似乎是一致的！我急忙打开流水表查看了下，内心的不安越来越严重。我紧绷着心打开了第三方打款的API文。文档给了我最后一击：默认使用用户所传的货币源打款！我颤抖着手打开了打款的接口，当望着IDEA编辑框中的CNY时我似乎有点恍惚。
我有点想认错，但却不知道给谁说。我觉得这种事情很离谱。这时候我也想起来之前好友的一句要不再测测，而我却以一句：”不用，就几行的代码“来回绝了他，的确。我吃亏在自负和没有交易灵魂。（仅限写代码这个笨比事情，后面铁锅我背不动）
我如实向老大说明了情况。老大这个时候甚至也陷入了惯性思维，还没有意识到我说的问题的严重性。
在沉默了两秒之后老大突然想明白了，他一脸苦笑的看着我：”先看看有多少是错的。“说着他打开了后台的流水记录，一声不响的发给我一份Excel。并说：”你自己看下吧“
打开Excel之后我也停顿了。所有列标题都是英文，我只能认识一半，比如日期。而这该死的流水对应的币种居然有四种。而我只能向老大询问了下哪一列是实际支出的RMB，对应的币种是什么。可这一对我愣住了：
（铁废物身份坐实哈哈哈哈哈，可是我做错了，我也没有仔细研读该死的API文档，我明白了，有些事情可以放下了）
其实内心有好几秒是奔溃的。但不知道为什么突然感觉就好起来了。事情发生了，按照处理问题的思路，先解决，再追责。的确也不是什么惊天bug。我又是几行代码就修复了。我想这件事情将会成为老大在我职业生涯印象颇深的一笔了吧。
思考
从头到尾，我从头错到位，开发前不认真看API文档，开发中不看上下文代码细节，开发后不关注线上的变化。既然接受这份工作，到目前这个阶段，都属于我的失职。但是究其本身，我们就事论事：作为财务重要的环节，提出了微需求无人有异议（全员降智不重视），测试不了解微需求所有内容（被我套路只测了切换，锅在我），线上不回归，产品不验证（和我没关系，就是单纯的做事有问题）。财务在使用十几天之后依旧没有发现问题（这是最离谱的，钱打多了！我的亲）。在我来看，无论我在这家公司是什么样的结果，我都觉得合乎情理，但是因为我团队丢了一些评优我很抱歉。或许一开始我的谨慎，就能把他们的松懈全部给补上了。但这并不妨碍我是铁笨比的事实。
所以刚毕业，就如我的老大所说：先学会怎么工作，程序员的硬本事是技术，但是”如何工作“，也是非常重要的一环。就这个话语来看我是非常认可的，比如我这次的事故只要有一个环节没有问题，那么事情不至于这么糟糕。
###2019-12 月更新
时至今日，首先我没有被Fire（毕竟性价比男孩），其次我觉得我还是有职业操守（过分对不起人的事儿我没有做），最后更新一个好玩的事情：
其实哪怕到了19年底，几乎当时的人（产品/测试/项目经理/研发老大）都换了一批，该是什么样还是什么样。当改变不了环境就.......
我之前又说程序员做程序三件事：稳定，高效，可扩展。用我一年的想法再来看的话，的确，我依旧是个残次品。哎，安静前进吧。