《代码走查实践体会与总结》由会员分享，可在线阅读，更多相关《代码走查实践体会与总结（12页珍藏版）》请在金锄头文库上搜索。
1、调测之前我们能做些什么？代码走查实践体会与总结手机事业部软件一部 蒋荣摘要：今年事业部正在大力推广软件的代码走查活动，因为代码走查是成本相对比较低的一种 发现缺陷的手段。但是即使是这种简单的活动，似乎在项目中推广起来还是举步维艰。这里面包括 项目压力、观念、方法等诸多原因。本人在做代码走查方面方法改进和推广的工作，几个月下来， 收集了一些值得总结的问题和方法，特总结于此，希望能给同行一些指引。代码走查的重要性很多人可能耳朵都听出老茧了，本文不想涉及过多的理论化的口号，也不想 引用一些大家都不知道是否真实的业界的统计数据，主要是本人的一些亲历体会和认为可以推荐的 一些方法共享给大家。期望据此展开
2、这方面的方法和经验的讨论，而不是仍然停留在做与不做的阶 段进行无休止的徘徊和争论。关键词：代码走查调测调试测试缺陷写程序“三分编，七分调”？我刚毕业开始做软件开发的时候，所在的不正规的软件部门没有正规的测试手段。对故障以及 故障会意味着什么也没有什么深刻的体会，反正只要能写出来完成差不多的功能就行。开发人员代 码写完了大概跑一跑，崔得急的话可能马上就拿到现场去试着用，有时候还得在现场直接改代码。 后来在修改过程中逐渐发现，很多时候花很少时间就已经完成编码的模块，但从开始调试到最终基 本稳定要花几倍于编码的时间，而大部分情况都是在处理一些不大不小的小故障，这其中定位故障 几乎花了 80%的时间。
3、在纳闷中我问我的师傅，师傅告诉我写程序就是这样，所谓“三分编七分调”， 以后你就习惯了。于是我如获至宝似的获得了一个真理，在调试解决故障上花时间似乎是必然付出 的代价，也没想去找什么捷径。这种懵懂的过程一直持续了很久，到后来逐渐有所改变。因为经过一段时间的磨练，自己也积 累了一些所谓的经验的小窍门，我发现有时候当有些故障出现的时候，凭一些经验即使不用调试代 码，直接阅读代码居然能大概定位到一些问题，这样给自己节约了不少的时间，因为毕竟调试和跟 踪总是很耽搁时间的。再后来我也开始当师傅了，新来的兄弟似乎在重复着我原来的过程，有时候 他们遇到故障的时候，我便提出来让他们尝试别先急着调试跟踪，先分析
4、一下现象后大概阅读一下 有关的代码，就算是猜吧！运气好的话也许不用调试就找到问题了呢？虽然不保证肯定能行，但是 花一点时间试一试，万一搞定了不是很节约时间吗？有很多次居然可以奏效。到那个时候我对我师 傅的话开始有点犯疑，因为我发现在调试之前，似乎还是有其他办法可以试一试的，而他居然从来 没有给我提起过。我一直有个习惯，假如我在自己肩膀上发现了一条虫，除了飞快的拍掉它后我还会把自己全身 都来个大搜索，因为我担心身上其他地方还有，我母亲说这个习惯是因为我从小就胆小，但是我辩 解说既然肩膀上有，那其他地方肯定不排除啊，呵呵。我不知道自己这个习惯的来源，有趣的是这 个习惯居然体现到了我的平日的编码习惯
5、中。只要发现了一种典型的错误做法，我会不自觉的检查整个模块是否有同样的错误。这个习惯我一直沿用至今，他至少提醒我错误一旦被发现，同样的错 误不要在一个模块中重犯。直到后来我才明白，原来我所体会的这种习惯有一个更正规的名字，叫 做代码的“专项走查”。后来有缘进入了 ZTE，对代码安全性和正确性的要求更高了，才知道代码走查是软件开发过程 中非常重要的环节。但是很遗憾，我当时所在的ZTE部门在这个方面仍然不是做的很好，大家面 对强大的项目压力和现场故障，所能做的都是不断的测试和调试，阅读代码只是根据个人定位故障 的习惯随意采用而已，并没有提升到一个很严格的研发过程中来。但是有几次故障定位的经历使我印
6、象特别深刻。其中一个是我在培训时候给大家讲过，当时我 们的一个语音服务器在辽宁的一个地方出现了故障，现象非常严重。由于是在线系统不能停，我和 几个开发人员每天都是半夜开始加班编写调试模块跟踪现象，累了几天晚上，仍然毫无头绪。忙乱过后我们静下心来做了仔细分析：（1）这个平台在国内外几十个点都在稳定运行；（2）辽 宁这个平台话务量特别大；（3）辽宁这个平台刚开始一直没有问题因此有一个累计过程；（4）重新 启动后故障依旧证明故障出现在具有记忆存储体的处理逻辑中。经过分析我们发现，由于我们这个 平台唯一的存储体就是采用一种hash算法的内存数据库，这个数据库纪录了语音的索引并定期保 存到磁盘印象文件。
7、我们把重点放在这个内存数据库模块上，由于这个模块比较独立，于是我发动 所有开发人员对这部分代码进行地毯式阅读，尤其关注引起语音索引混乱的数据问题。最后，一位 开发人员在代码中找到了原因，是一个纪录语音复用个数的数据定义太小，当转发次数超过64K后 发生归0溢出，造成语音定位混乱。问题好像就这样解决了，但其实还并没有完。发现这个现象后，我们立即怀疑是否还有其他地 方涉及这个参数的地方定义是否也有类似的问题？于是我们继续阅读了相关几个模块的代码，发现 在程序的启动模块中由于需要对数据库进行数据整理，与此相关变量同样定义小了，也就是如果我 们只修改前面提到那个地方暂时解决了问题，但当系统由于某种原因
8、发生双机倒换而重新启动的时 候，那个问题又会冒出来。当时我们冒了一身冷汗，每个人都觉得很庆幸，至此修改完后问题彻底 得到了解决。经过一些教训后我总结出几个结论： 只要程序是人写的，肯定就有缺陷。 调试代码环境要求高，有些时候根本不允许调试（比如现场）。 阅读代码没有任何环境要求，只要有源代码，随时可以阅读。 调试代码每次只能定位到一个缺陷。 阅读代码可能找到一批类似的缺陷。 带着问题有针对性的阅读代码可以提高成功率。基于上面的结论我们可以总结出这样一个原则：当故障出现后，定位故障除了采用跟踪调试的 手段，有时候直接阅读代码也许是不错的选择，并且一旦发现一个故障，通过阅读代码有针对性的 扫描整个
9、模块相类似的错误通常可以找到更多的错误。当然，谁也没有否定调试跟踪的重要性，我 只是在想，假如有10个故障依次需要调试跟踪，其中能有5个故障可以尝试通过阅读代码而定位， 是否总体上可以节约一些时间？为何都钟情于调试和测试？前面啰嗦了那么多，无非就是想说明有时候通过阅读代码定位故障在成本上有时候很划算。但 是我还是觉得有点不满意，因为定位故障虽然多了这样一种选择，但是毕竟是故障已经发生了，我 们是根据故障现象有针对性的去阅读代码。为什么我们不在故障发生前来阅读代码呢？大部分程序员（包括我自己在内）编码完成后第一件想做的事情就是先“编译”，编译如果出 了一些错误和告警便一个个找原因并修改；编译通过
10、后就尽量能整个程序连接在一起“运行”，运 行出了错呢？开始仔仔细细的逐个跟踪找原因，最后一个个原因找到后基本运行通过了。上面是正常开发的一般做法。那么当发现故障后我们是怎么做的呢？我们首先想到的是复现故 障现象，然后分析大概位置，最后通过增加一些跟踪信息等手段去逐步顺藤摸瓜，只要现象容易浮 现，一般还是能定位到原因。我们多数情况下都是这样做的。写完代码后我们很少主动的去阅读和检查代码，即使有时候阅 读代码，也是当故障出现后为了解决故障被动的针对性的阅读代码，就像前面我举的例子一样。我 一直在考虑，我们宁愿花大量的时间一个一个的调试排除故障，却不愿牺牲哪怕一次故障调测的时 间来做一次广普性的代码
11、检查。同样是排除故障，一个是通过发现故障后“调测”跟踪，一个是通过“阅读”代码广谱查找。 我常常把这两种方式做一个比喻：前者正如某个人生病了上医院治病；后者正如某个人主动的到医 院进行健康检查。大家能得出什么结论吗？至少我觉得以下几点可以达成共识： 生病就医的言下之意是一种被动就医，已经生病已经付出了代价。健康检查的言下之意是一种主动行为，可提前预防。 生病就医太有针对性，花很大的成本最后就治愈了一种病，综合成本高。健康检查是广谱性的体检，花一定成本一次可能查出多种病状，综合成本低。 生病就医发现的病症大部分已经是晚期，一般都很严重了，医治成本和代价都很高。健康检查发现的病症大部分都是早期，一
12、般有治愈希望大，医治成本和代价都较低。 生病就医的最佳结果只能是治愈。健康体检的最佳结果是健康，因为可主动指导和改善生活习惯，减少病状发生。很遗憾我们大部分人对健康体检的常用托辞是“我工作很忙”。有趣的是这种说法和软件开发 中“我项目压力大、时间紧”的说法多么的相似，只不过所有项目到最后都在忙着找故障，而再也 没有谁去关注如何预防故障的发生。因为当故障已经出现的时候，解决故障变为第一要素，却没有 人考虑过这是一个周而复始的循环，是否有人考虑过能否减少这种事情发生的次数。当然，谁也不会否认，当一个人生了重病后是肯定要医治的。问题的关键是我们不能总是经常 性的等生病后往医院跑。耽搁一点正常的工作时
13、间，或者牺牲或延长一次生病就医的时间做一次健 康检查，用于指导改善你的生活习惯，不是更好吗？我相信大部分开发人员如今对“代码走查”这种预防性活动还是有很正确的认识，问题是为什 么在强大的项目压力下在“故障调试”、“新功能开发”和“代码走查”之间总是把前者放在最重要 的位置，而把“代码走查”放在可有可无的次要位置呢？我总结了几个原因： 没有可供检验的结果：“新功能开发”和“故障调试”都是不可逃避的，因为二者都有明确的最终结果作为目标检验标准；“代码走查”没有明确的最终结果，做了没有？做得怎/么样？没有标准就没有监督和审核的标尺，项目很紧的情况下，也就变得可有可无。 没有可控制的中间过程：“新功能
14、开发”总是要编写代码，“故障解决”总是要跟踪调试； 但“代码走查”的过程没有固定的模式，读程序快慢与否、认真与否全部没法掌控，既然 过程不受控，自然就容易马马虎虎。 没有固定统一的方法：在没有故障提示情况下，盲目的流水帐似的阅读代码，最后变成不 同人按自己的方法随意的走马观花似的大概略读一下代码，时间长了觉得没有效果，也就 疲了，最后不了了之。 效果影响信心：在代码走查中某些模块中没有发现什么缺陷，由此对自己的阅读代码查找 缺陷的能力产生潜意识的怀疑，从而认为在其他模块中发现问题的可能性为零，最终放弃 这种低成本的查找缺陷的机会。 完美主义：用完美主义的眼光来挑剔代码走查，认为既然强调“代码走
15、查”的重要性，那 么应该可以发现绝大多数缺陷并解决之，否则我宁愿不做。 没有目标：在问题没有暴露前找问题，不知道该如何找。什么问题都想找，东一榔头西一 棒，最后晕头转向，多次失败的情况下，最终放弃。 枯燥乏味：“新功能开发”是一个创造性的活动，“故障解决”带有强烈的目的性，唯独阅 读代码是被动的在一大堆符号中寻找缺陷，在没有明确目标的情况下，确实很乏味，甚至 最后都忘记了自己的最终目的。2小时做一个尝试我时常在想，在我们编码之后调试之前，牺牲一次故障调试的时间，就算是尝试，给自己的代 码做一次代码走查，哪怕一个缺陷没有找到，这个应该不算是多大的冒险吧？做这样一个尝试并不难。首先，做一个深呼吸（
16、可省，呵呵），然后给自己做一次心理暗示， 你只需要先保持这样一种简单的想法就OK 了： 代码走查不可能解决所有的问题，我的目的是减少遗留到后面的缺陷数量。 我只花一次普通故障调试的时间作为代价（比如2个小时）。 如果我代码走查找到1个这样普通的缺陷，我的代价就收回来了。 如果我找到2个这样的普通缺陷，我就赚了。 如果我找到2个以上这样的普通缺陷，我将是非常幸运的，证明这是一次非常划算的尝试。 如果连一个像样的缺陷都没有发现，没关系，我损失不大，不就2个小时吗？也许我加加 班就可以补回来，或许证明我的代码故障不多，不是好事吗？下面怎么做呢？同样的，抛弃完美主义，你不需要怀疑自己的方法和能力，更不需要怀疑自己 漏掉某些缺陷，你只需要简单的反问自己： 我代码中所有的数组是否都保证绝对不会越界？
