程序员,时间都上哪儿了
晚上调试修复了一个线上的小 BUG, 花了2个小时, 加上昨天花费的时间, 总共大概3个小时。
BUG 是这样的: 一个 API 返回的 JSON 串是一个对象数组 [{field1: 'xxx', field2: 'xxx', 'source_cidr_ip': 'xxx'}, {'field1': 'xxx', 'field2': 'xxx', 'source_group_no': 'xxx'}] , 有一个字段名称是可能变化的, 大多数时候是 source_cidr_ip, 极少数时候是 source_group_no , 所采用的 JSON 解析库是 JACKSON-lib , 这个库对要填充的对象定义有一些要求: 所声明的对象的属性必须包括所有 JSON 串中的字段, 若少了则会报错, 若多了则会填充为 null. 而我定义的对象中只包含了 field1, field2, source_cidr_ip 三个字段, 忽略了 source_group_no , 结果当返回含有 source_group_no 字段的 JSON 串时, 就会出现解析异常。
为什么花了这么长时间呢? 按理来说, 这样的 BUG 只要查看一下日志, 是很容易定位的; 原因可能有如下三个方面: 1. 返回含有 source_group_no 的 JSON 串出现的概率非常低, 也许只是最近才出现, 否则应该早就报出异常了; 2. 出现 BUG 的时间距离开发的时候已经过去了近 7-8 个月了, 料想到是这些细节坏事还真是不容易; 3. 这个解析异常可能被多线程中的代码“吃”掉了(切忌把异常捕获了却什么都不处理!), 以至于没有看到。
令我痛心的是, 这样一个小 BUG 就耗费了大概3个小时! 如果把调试时间加到开发时间上, 那么这个小小的展示功能实际上是耗费了4-5个多小时! 由此, 我想到了, 程序员, 时间都上哪儿了 ?
BUG, BUG! 无休无止的 BUG! 程序员就要和BUG 相亲相爱了。BUG 是无法避免的, 然而, 如果在开发时能够更加仔细一些, 更加苛刻一些, 是不是可以减少调试时间? 减少这些不必要的调试, 是不是可以节省出更多时间,用于更有意义的事情上? 扪心自问, 是不是花了 1个小时开发, 又花了2个小时(常常是一点一点地累积出来的)不断地调试和修复?
那么, 如何减少调试和定位BUG的时间呢?
(1) 在开发时尽量苛刻一些, 充分测试, 对代码质量充分重视,勿急勿快;多花时间开发和测试,比多花时间调试可要有趣得多。
(2) 开发时考虑可扩展性和可变性,做好防御措施;比如上述就可以采用更好的库或方法,屏蔽掉未预料字段的影响。
(3) 仔细做好关键日志记录,在出问题时有关键线索可以快速定位问题所在;切忌认为不可能出问题而不作记录。
(4) 已知小BUG及早修复,避免在未来不恰当的时候放大成更大的麻烦。
从另一个角度来说, 程序员应当对自己的时间非常敏感, 毕竟, 技艺永恒, 生命短暂; 多留点时间给所爱的人!
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 全程不用写代码,我用AI程序员写了一个飞机大战
· DeepSeek 开源周回顾「GitHub 热点速览」
· MongoDB 8.0这个新功能碉堡了,比商业数据库还牛
· 记一次.NET内存居高不下排查解决与启示
· 白话解读 Dapr 1.15:你的「微服务管家」又秀新绝活了