Growing Object-Oriented Software, Guided By Tests (chapter 15)

When adding new functionality, don’t be afraid to refactor existing acceptance tests. However, we should do one at a time!

Code is becoming a little hard to follow now, trying to keep Java code in my synapses is nicht so gut

Perhaps use enums rather than just integers to convey more meaning in the code. Enums are especially good when we have multiple related values :) They can also be great when we have a state machine in our code.

The authors’ mention that switch statements are not considered OOP - I think the alternative is to create objects that respond in a certain way when passed a message. I’m sure there is a refactoring tactic in Martin Fowler’s ‘Refactoring’ book that discusses this. They decide to attach methods to an enum to remove the switch statement.

The authors’ notice that to implement their next piece of the system, they would be duplicating a lot of code. So they take the opportunity to refactor to make their lives easier going forward. They note that this duplication could have been spotted during the initial project planning, however, they also note that it is really difficult to get the design right the first time. The author’s contest that it is better to hit the critical parts of the system as early as possible, and refactor the pain points away once they reveal themselves. If we have a good test suite this should be relatively painless!

The authors’ say that they make use of a custom error type (something like DefectException) to show when an area of code has been reached that is caused by the programmer’s error, and not a runtime issue. Handy tip!

Grab-bag of tips:

• Focus on the single responsibility principle.
• Iterate in small chunks when refactoring, rather than biting off more than you can chew. It will help to stay agile.
• Be sensitive to when things are inefficient (duplicated code/effort). Can the process be streamlined? If not right now, maybe note it down and come back to it.
• Be open to change. I will say it again: The only constant in software development is change, and that includes the internals of a system! Refactor, refactor, refactor! Make the code cleaner, and easier to understand. Future maintainers of the code will thank you (it will probably be future you!).
• There is usually more than one solution to a problem - be open to exploring different approaches.

I have all but given up on trying to read the Java code at this point, I am just trying to extract some language agnostic nuggets of information :D