The past few days, I've been reviewing some code that looks like it could use some love.
It's part of an adapter, that connect the core logic running in our process with some shared mutable state which is managed by Postgres.
It's code that works, rather than clean code that works. The abstractions aren't very good, separable concerns are coupled to no great advantage, division of work is arbitrary. And yet...
In the course of our recent work, one of the developers noticed that we could eliminate a number of calls to the remote database by making a smarter version of the main query. We're using JDBC, and in this case the change required modifying the select clause of the query and making the matching change in the handling of the result set.
Both bits of code were in the same function and fit on the same screen. There's a duplicated pattern for working with queries, connections, statements, recordsets -- but nobody had come along and tried to "eliminate" that duplication, so the change was easy.
Also, because of changes we've made to the hosting of the database, we needed to change the strategy we use for managing the connection to the database. That change ended up touching a lot of different methods that were accessing the connection data member directly - so we needed to do an Encapsulate Variable refactoring to avoid duplicating the details of the strategy everywhere.
Applying that refactoring today was no more difficult than introducing it six years ago would have been.
YAGNI... yet.
No comments:
Post a Comment