免费发布信息网网站,活动策划书,网站调研怎样做,成都广告设计公司排行我曾经做了两年大型软件的维护工作#xff0c;那个项目有 10 多年了#xff0c;大约 3000 万行以上的代码#xff0c;参与过开发的有数千人#xff0c;代码 checkout 出来有大约 5 个 GB#xff0c;而且 bug 特别多#xff0c;open 的有上千#xff0c;即使最高优先级的… 我曾经做了两年大型软件的维护工作那个项目有 10 多年了大约 3000 万行以上的代码参与过开发的有数千人代码 checkout 出来有大约 5 个 GB而且 bug 特别多open 的有上千即使最高优先级的 showstopper 也有上百。分享下我的 debug 的经验 —— 优先解决那些可重现的可重现的 bug 特别好找反复调试测试就好了先把好解决的干掉这样最节约时间。 对于某些 bug 没有头绪或者现象古怪不知道从哪里下手找有经验的同事问一下思路因为在那种开发多年的大型系统里经常会反复出现同样原因的 bug原因都类似改了一处过一阵子另外一处又冒出来而且无法根治。比如我那个系统里有个特别危险的 API接口参数比较难用一旦有人用错了某些情况下就会出诡异的现象解决很简单找到调用这个 API 的地方把调用方式写对就好了。为什么不根治呢因为要保持兼容性不能改接口了。Windows 系统里就好多这种烂 API。问下老员工吧说不定他们都遇到过好多次了。 放大现象有些 bug 现象不太明显那么就想办法增大它的破坏性把现象放大。这只是个思路具体怎么放大只能根据具体的代码来定。比如美剧《豪斯医生》里有一集怀疑病人心肺有问题就让病人去跑步机上跑步加重心肺负担从而放大症状。 二分法定位把程序逻辑一点点注释掉看看还会不会出问题类似二分查找的方法逐步缩小问题范围。 模拟现场有时候我会问自己如果我要实现 bug 描述的现象我要怎么写代码才行比如我遇到一个死锁问题但是检查代码发现所有的锁都是配对的没有忘记解锁的地方而且锁很简单就是一个普通的临界段保护几行赋值语句而已。这样的代码怎么写才能让他死锁呢我想如果让我故意制造这样一个现象只有在上锁的时候强制杀掉线程了。既然这样就可以去看看有谁强杀线程了没有。 制作工具针对某些 bug 编写一些调试辅助工具。比如我那个系统没有完善的崩溃报告虽然也有 dump但是分析出来的 callstack 经常不准。于是我为解决崩溃问题编写了个工具会自动扫描代码在每个函数入口和出口插入 log以此来定位崩溃点。 掩盖问题虽然这样做有点不厚道但是有时不得不这么做。有些 bug 找不到真正的 root cause但是又要在规定时间内解决那么我们就可以治疗症状而不去找病因。比如用 try catch 掩盖一些奇怪的崩溃。不到万不得已不要这么干未来可能会付出更大代价。
