VBM on Android - Ruthless Refactoring

Quinn Gil -

I was looking at the code today to see if I could use the new Moshi 1.4 and thought I should poke about to see if there's any obvious changes out the network layer I could/should change.
I've modified the build.gradle to pull in Moshi 1.4 explicitly; and it still builds; so Woo! Even if I don't have modifications in mind, it's keeping the system up to date with the latest to minimize any migration pain later. Which is one of the practices that should be followed.

While poking around looking at our the system so far; I found that one of my methods in the ItemAdapter.java didn't have code coverage... WHA?!?!?! ... So... huh... apparently didn't TDD this effectively. Maybe you caught it early on in this process; I missed it. But I discovered it now. Having Code Coverage visible in the IDE is a crucial aspect to TDD; truly being able to see the Red-Green change; it's HUGE. I only knew I was missing the entire ItemAdapterTests.java file was missing because that line had a red block next to it.

I also saw that my non-supported/implemented toJson method also doesn't have tests; but SURE - we don't support serialization. It needs tests. I've added these tests. A little renaming; cleaning up.

I am writing about these because it's these tiny things.

  • Test missing on a one line method. A SINGLE LINE!
  • No test for a method that ONLY THROWS AN EXCEPTION!
  • Returning null instead of throwing.
  • Small name change to improve communication of intent.

These small things are how you maintain code that clearly communicates. These are the small things that a software craftsperson needs to clean up as they work in code.
Keep the code clean, tested, and communicating - It'll improve everyone's experience.

Ward Cunningham recently tweeted

And it's this kind of concern over the code that I strive for. If there's the slight mental processing of "What exceptions is this handling?" then the code can be improved; And it should be done.

While this post shall focus on building out the UI to display the top stories; there's always time to improve the code when you've find places for it. Big changes should be a new task/chore put on the board to be done before the story/feature is finished. Don't get too distracted, but make it visible when something needs to be refactored; and make sure it gets done.

The changes as of this refactoring are available on githib