Refactoring Bus. Logic

The past couple weeks have had me back into old problems. I had been in each of these holes before, but was back with new requirements. As i looked at both of the functions in the CFCs, i found myself struggling to add the new requirements because the way the functions were defined was not intuitive. In one case, i ended up refactoring the way the logic was working. I should say i separated the logic into two different queries and then used a union to join the result set if needed.

It took me a couple days of going into and out of this function before i was able to see the solution that i ended up using. I was talking to another developer about this and concluded that we need to see things in our own model to understand them before we can enhance something. I was temped at one time to create a new function and simply leave this one that way it was, but i fought that urge and eventually saw a cleaner way to solve the same problem. Be a technician, bot a demolition man. I added a comment in the function to the effect that i hoped the next time someone traveled down this path into this function, that the bus. logic would be clear to them.

Good code to me means clear code, not necessarily fewer lines or clever, but clear to the next person who may be coming into the code to try to enhance it.

The greatest threat to maintainable software? Complexity! Someone said that once.

Moral to the story. Be patience and if code smells, give yourself ample opportunity to re-factor the code in a way that does not smell, is easier to understand and enhance for the next Joe who comes along after you.