写代码前没理清这三大逻辑？90%的Bug源于此

　　去年四月份那回，我原以为改个配置文件顶多半小时，结果被开发按在工位上骂了俩小时——就因为代码里那三个破逻辑没理顺，告警响得跟过年放鞭炮似的，好几台机器磁盘直接爆红，泡面都凉透了还没吃上。

　　那天晚上十一点，开发说新脚本要上线，让我先跑个测试。我扫了眼代码，心想“就调个API，能有啥问题？”结果脚本刚启动，监控群里就炸了——磁盘使用率从30%飙到90%，告警消息刷得比微信群红包还快。我冲过去看日志，发现脚本在循环里疯狂写临时文件，每秒生成几百个，可代码里根本没删文件的逻辑。开发在电话里喊：“我明明写了清理函数啊！”我翻代码翻到凌晨三点半，发现那函数写在另一个分支里，条件判断写反了——本来该“if 成功则清理”，结果写成“if 失败才清理”。

文章配图，仅供参考

　　那天晚上我一边删临时文件，一边跟开发吵架。他说：“你运维咋不提前看代码？”我火大：“我咋知道你会把清理函数写错分支？”他回：“那你咋不测全量？”我怼：“你代码逻辑都没理顺，我测个屁！”吵到一半，窗外天快亮了，我手机又响了——是媳妇打电话催我回家，说孩子发烧了。我挂了电话，看着屏幕上还开着的监控页面，突然觉得特麻木——这破工作，咋就跟救火似的，永远有下一场？

　　其实后来复盘，这事儿本来能避免。我原以为“业务逻辑”最重要，结果发现“异常逻辑”才是命根子。就像去年迁移数据库，我提前把业务逻辑（数据迁移）和数据逻辑（字段映射）写了二十页文档，结果上线时因为没考虑“网络中断”的异常逻辑，迁移卡在中间，旧库被删了，新库没写完，直接导致业务停了两小时。后来被领导按着头学“防御性编程”，才明白——写代码前，得先把“如果失败会怎样”想十遍，比“如果成功会怎样”重要十倍。

　　那天删完临时文件，我跟开发约法三章：以后代码上线前，必须一起过一遍“三大逻辑”。他说：“行，但你得请我喝可乐。”我笑：“行，只要别再让我半夜删文件。”结果上周他又写了个脚本，业务逻辑是“解析日志”，数据逻辑是“存到ES”，异常逻辑是“如果ES挂了就写本地文件”——结果他漏了“本地文件超过1G得自动清理”的细节，我又被叫起来删文件。这次我没骂他，只是默默点了根烟，心想：这破逻辑，啥时候是个头啊？

　　其实我现在挺认了——90%的Bug，真就源于写代码前没理清这三大逻辑。优胜劣汰嘛，逻辑清晰的代码活得久，逻辑混乱的代码早死早超生。就像上周那个脚本，我花了两小时补了异常逻辑，现在跑得稳如老狗；而开发写的那个漏清理的脚本，早就被下线了。下次再写代码，我得先在纸上画三个框，把业务、数据、异常逻辑分别写进去，写不全就不碰键盘——反正被骂的次数多了，也就不怕了。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!