Posted on

Reading Other Peoples & your own old code

Old code is hard to read.  Even your own.  Its not uncommon 6 months down the track, to experience a bit of “what was I thinking when I wrote that?”.  Its one of the first things drummed into me by senior devs at my old work.  The best way to avoid this is to make your code as easy to understand as possible and I believe to do that you need to keep your code modules small (classes & methods) so that they are easy to test. 

But as I try to work with old code bases with long methods and classes with lots of dependencies that are sometimes difficult to test, and with shrinking deadlines to do anything about them, the messages about good practices fall by the wayside.  Its refreshing to see a blog like this, Beautiful Code: A Sense of Direction, talk about the core tennets of keeping things simple, small cohesive classes and refactorings to reduce LOC in addition to a nice example at the start that I read as even your own sh—, um, crap stinks.

BTW, the article made reference to a site that I had come across previously but hadn’t bookmarked which appears to be a great resource on Design Patterns (and Antipatterns) and UML called SourceMaking.com

Posted on

Legacy Java Systems

I’ve had my fair share of working with legacy code.  I don’t think legacy code is a bad thing because its existence means it has addressed the majority of the needs of the business successfully enough to stay around.  However, as time proceeds, the business needs to change in order not to become a historic entity and so legacy apps need to be updated.  This is usually where the frustration comes in.  You have to work with older development practices and styles you may not be used to.  You also may have to source old libraries or application containers in order to get things to build and deploy. 

However, I would like to think you can make a green field out of anywhere. A lot of other people may disagree, but the legacy system does have the advantage of addressing business need that your own ‘from scratch’ green fields app may not (provided the business need is still relevant).  There was a recent article on info q: Eight Quick Ways to Improve Java Legacy Systems that talked about the following areas

  • Tip #1: Use a Profiler
  • Tip #2: Monitor Database Usage
  • Tip #3: Automate Your Build and Deployment
  • Tip #4: Automate Your Operations and Use JMX
  • Tip #5: Wrap in a Warm Blanket of Unit Tests
  • Tip #6: Kill Dead Code
  • Tip #7: Adopt a ‘compliance to building codes’ Approach
  • Tip #8: Upgrade Your JRE

I’ve used a number of these techniques, but there were some I hadn’t heard of before such as the jdbcWrapper that simply wraps your jdbc driver with a logger so you can see what part of your code executes what SQL. (Tip 2)

Using JMX to trigger cache cleanups as described in Tip 4 is a great idea.  Another useful thing I’ve seen is using scripts and creating a Javascript or Groovy console within your app so that live maintenance can be performed on production environments.

Tip 5 touches on breaking dependencies, which is what you see a lot of in the code base I use. I’d like to get to know more about how to do this

Tip 6 advised that the Emma code coverage tool can also be used to find production code that isnt run (in addition to stuff thats untested)

Tip 7 really rang true to me.  Its easier to bring in all your toys under the sun, but without a common plan, everyone will bring in their own frameworks to solve the same problem and make the app even more confusing to work with.  I like ‘toys’ (frameworks, tools, etc) but I know I can get carried away Winking smile