每个程序员都会遇到的一些有趣的bug.每一次都可总结出一些经验教训.下面是总结的最重要的经验教训,包括编码,测试和调试三个方面.潍坊UI培训为学员提供8对1服务,使学员就业得到保障.
(一)编码方面
1.事件顺序.在处理事件时,提出下列问题会很有成效:事件可以以不同的顺序到达吗?如果我们没有接收到此事件会怎么样?如果此事件接连发生两次会怎么样?哪怕通常不会发生,但系统(或交互系统)其他部分的bug可能会导致事件发生呢.
2.过早.这是第一点"事件顺序"的一个特例,但它确实会引起一些棘手的bug,因此把它单独拎出来说明.例如,如果信令消息在配置和启动程序完成之前就被过早接收,那么可能就会有很多奇怪的行为发生.另一个例子:连接在被放进空闲列表之前就被标记为down.在调试这类问题时,我们总是假定在空闲列表中的时候连接被设置为down(但当时为什么不把它放到列表外面呢?).这是我们思考的不足,没有考虑到有时候事情会过早发生.
3.悄无声息的故障.一些最难跟踪的bug有部分是由那些静静失败并扩展而不是抛出错误的代码所导致的.例如,没有检查代码却返回错误的系统调用(如bind).又如:解析代码在它遇到错误元素的时候只是返回而非抛出错误.在错误状态中持续了一段时间的调用,会使调试变得更难.最好一旦检测到故障就返回错误.
4.If.有若干条件的if语句,if (a 或 b) ,特别是当有链接的时候, if (x) else if (y),都给我引发了很多bug.即使if语句在概念上很简单,但当有多个条件要跟踪的时候依然很容易出错.
5.Else.有一些bug是因为没有正确考虑到如果条件为false时会发生什么而引起的.几乎在所有的情况下,都应该有一个else部分来应对每一条if语句.此外,如果你在if语句的分支中设置变量,那么或许你在另一个分支中也要设置.与此种情况相关的是标记被设置的情况.只添加用于设置的标记的条件不难,但是很容易忘了添加当标记应该再次重置时的条件.留下一个永远设置的标志可能会导致之后接连不断的bug.
6.改变假设.许多一开始最难预防的bug是因为改变了假设所造成的.例如,在开始时,可能每天只有一个客户事件.于是很多代码是在这样的假设下写下的.但是后来,设计改变了,允许每天有多个客户事件了.发生这种情况时,很难改变新设计影响到的所有情况.找到关于改变的所有显式依赖关系不难,难的是要找到所有隐性依赖于旧的设计的情况.例如,可能会有获取给定某一天所有客户事件的代码.其中的隐含假设是结果集永远不会超过客户的数量.
7.日志记录.可视化程序做什么至关重要,特别是当逻辑很复杂的时候.确保补充足够多的(但不要太多)日志记录,这样你就可以说明为什么程序要这么做.如果一切正常,那也没关系,但要是有问题发生,你会很庆幸自己添加了这些日志.
更多潍坊达内培训相关资讯,请扫描下方二维码