“大多数开发人员只是想写新的功能,他们不想使用维护和修补漏洞”。这也是大多数开发人员是错过的乐趣和好处就是发现和修复bug。
每个错误都可以教你一些东西。
反馈是一个关键，它是敏捷开发的主要原则之一。单元测试和迭代开发技术更快地提供反馈。与单元测试你的代码是否有效的问题上得到反馈,和每个交付版本你可以听听客户认为的新特性。错误报告是另一种形式的反馈您的代码。一个错误的可以有许多不同的原因。一些可能性是:一个简单的编码错误(比如一个嵌套的if语句,你最终在错误的分支),或者一个错误的假设你(也许传入的消息并不总是有某些字段,所以你有一个空指针异常),或有缺失的要求(你应该回答消息以不同的方式,如果一个给定的参数存在),或客户使用软件在一个意外的(但正确),导致错误。
在这些情况下,您可以学习如何代码,它是关于你的产品或系统的作用。例如,当我在Tilgin VoIP开发产品,有一个情况我们收到了一个错误的信息,导致我们的软件循环下去。消息所包含元素使用tag-length-value编码(电磁阀)参数,长度值元素的总长度。这样你可以跳过未使用或未知元素向前跳“长度”的字节数。在这种情况下,长度值是零,所以跳过我们指向相同的元素后,指出在跳之前,导致无限循环。这个bug前,仔细检查我的代码长度值太大值会导致阅读过去的消息缓冲区。不过,在那之前,我从来没有想到,一个零长度可能是同样糟糕。
自己的代码变得更容易调试。
当你花时间故障问题和修复bug,它不会花很长时间,直到你想让自己的代码尽可能容易调试。这是令人沮丧的不所有可用的信息。一个非常常见的问题是不包括动态信息的异常。例如,假设有代码,预计值范围在0 – 20。有多少次你看到一个异常,只是说“非法价值”?不告诉你如果你想找到一个bug。如果例如21日收到,应该说“非法值:21日不在范围0 – 20”。它有助于包括允许范围,肯定有助于包括当前值。当前值可能是21日或-128年或65535年。所有这些可能给你一个线索是什么导致了它,你不从一个普通的“非法价值”。甚至Steve McConnell打破这个规则在某些地方的优秀作品代码完成。例如,在第15章中有一个例子,一个意想不到的发现类型的字符,但错误消息不包括字符的问题。每次你找到并修复一个错误,你需要问问自己:我应该做有什么在我的代码不同,以消除错误避免未来再次出错吗?有什么我应该做,使这种错误更容易避免发生在未来吗?
你和客户会很高兴。
正如我所提到的,为什么我爱编码、编程的乐趣之一就是做对别人有用的东西。你得到同样的踢修复一个缺陷,但在不同的时间尺度。提供新功能通常需要一段时间,但一个bug修复可以在一个小时内完成。每个固定的错误让你感觉你是完成一些东西,这是一个伟大的感觉。有点矛盾,修复一个缺陷会使客户满意。如果没有一个错误首先,不会有需要修复它,那么为什么他们应该快乐吗?然而,我的经验是,他们乐于接受一个bug修复,尤其是如果它是快速解决。每个人都知道总是会有缺陷。重要的是,有人准备修复它们很快被发现时。
解决问题是有趣的。
许多程序员喜欢解决问题,像数学难题,编程挑战,数独或填字游戏。甚至谋杀谜团饲料解读:你看看线索,试着找出它的发生而笑。调试和修复bug是相同的。每个错误都是一个新的谜题找出。经常看到一个新的错误报告的时候你的第一反应是:这是不可能的吗?怎么能这样呢?这是当你开始寻找线索。日志怎么说?从系统错误报告吗?此时系统中发生了什么?最近任何改变——新软件,配置更改,交通干扰?让找出开始!这些都是四个原因我喜欢调试和修补漏洞太多。你的经验是什么?
后记：月小升认为，正确的策略是没次编写一小段代码，就多加测试，把bug消除在集成之前，越在前期检测，越容易查到bug，而且后期调用无bug的模块，团队作业效率会高出很多。不过bug总会有的，面包也总会有的。
