This metric gauges how much code a programmer needs to explore to find the troublesome segment, starting from the initial error trace.
To illustrate this concept, let’s look at a simple example.
Imagine an Invoice with an empty Customer field, resulting in a null value.
When this invoice is processed, a null pointer issue arises in the process function.
Two scenarios emerge:
- Optional Invoice Customer Field: It’s acceptable for the Invoice’s “customer” attribute to be empty. For example, an invoice in progress might not yet have a specified Customer.The error trace precisely points to the problem. Since the process function should handle empty customer entries, the solution lies within that function.Here, the distance to the core problem is short. A brief distance provides quick feedback for anomalies.
- Mandatory Non-empty Invoice Customer Field: Now consider a situation where the customer field unexpectedly remains empty. The solution isn’t within the process function. By the time the invoice reaches this function, it’s already compromised. The issue might originate from incorrect invoice storage due to a faulty repository load function. Thus, scrutinizing this code is necessary. The problem might extend further – investigating the database could reveal incorrect storage.Importantly, a different microservice manages Invoice object storage. Analyzing this microservice is crucial; any attempt to store a corrupted invoice should fail early.In this context, the distance to the core issue is significant. Navigating through multiple classes, possibly crossing application boundaries, is required to identify the root cause.
Lesson Learned
Reducing the core issue’s proximity is vital. This can be achieved by minimizing the amount of code exploration. Excessive movement across files or applications burdens developers. Quick failure or state validation can save substantial time and effort.