Sometimes you make a change in your software that has repurcussions on other parts of the system. For example, a method you're working on that used to return a domain object can now return nil. You have to track down what those repurcussions are and make sure that the other code isn't adversely affected. In cases like this, it's usually too risky to just make the change and count on testing to determine if anything breaks. But determining what's affected can be a long and involved job. Sadly, the best answer is usually to just to do that job. Make yourself a checklist or a map as you go and do whatever you need to do to make sure you've fully studied the impacts of your change. This due diligence can prevent many hard-to-find bugs in the future.
Download