A Tale of Bug Fixing: Thinking Beyond the Immediate Solution

This article presents a story about bug fixing that teaches important software development lessons.

Part 1: The Bug

A customer reports Bug #3890: A program shows an error "SpeedCalculator::compute() has a division by zero situation." The developer opens SpeedCalculator.php and finds:

1

2

3

public

function

compute() {

return

$this

->distance /

$this

->time;

}

The Quick Fix

The developer quickly adds a check:

1

2

3

4

5

6

public

function

compute() {

if

(

$this

->time == 0) {

return

0;

}

return

$this

->distance /

$this

->time;

}

After fixing similar bugs in RatioCalculator and MoneyCalculator , the team believes the problem is solved. A month later, another bug appears—the program doesn't crash, but customers find incorrect calculation results due to the return 0; modification.

Part 2: Step Back and Think Deeper

The developer steps back to analyze: Why does this happen? Because $this->time is being assigned 0. A better solution is to validate at the setter level:

1

2

3

4

5

6

public

function

setTime(

$time

) {

if

(

$time

== 0) {

throw

new

InvalidArgumentException(

"Invalid value"

);

}

$this

->time =

$time

;

}

This ensures data validity. The developer then copies this pattern to RatioCalculator and MoneyCalculator , and handles errors in the presentation layer.

Part 3: The Real Question—Understanding Requirements

The key insight: Instead of fixing a bug, should we discover a general requirement? Why do customers enter 0? Because they make mistakes.

Do we only need to prevent "speedCalculationForm = 0"? Do we only need to validate data in "speedCalculationForm"? Or should we validate all user input?

The article suggests using existing third-party validation frameworks rather than building custom solutions.

Conclusion

Programmers love technology and want to implement what customers ask for. However, we need to look at problems more comprehensively. We should understand WHY they提出这样的需求, not rush to find solutions.

Does the customer really need "a glowing button that dodges mouse clicks"? Or do they need another feature they don't understand, which you need to help define? This applies to developers too: Do you really need to open a file and write information, or do you actually need a logging system?

Step back, look at the bigger picture and complete information. Programming is about solving problems, not just writing code.