Category Archives: Uncategorized

Tons of Small Classes

When I do Clean Code Training or if I discuss the topic with coworkers one argument comes up over and over again:

“But if I have split all my code in those tiny methods and classes, how will I find anything? I’ll have to navigate through dozens of files!”

The problem with this argument is: It is not that wrong. And I have certainly seen code where I had to navigate a dozen classes very carefully in order to understand what is going on.

If you look at it from an abstract point of view it looks like it even has to be this way. If you want to completely understand a piece of code it’s certainly best, to have it all in one piece on the monitor. You can go from top to bottom, line by line. If you have lots of little methods and classes, you in addition to that have to navigate through all that classes and methods, keeping track on from where you called this piece of code. Obviously these are additional tasks that just make your work harder!?

I still insist this argument is wrong. The mistake is the premise that the task at hand is to understand all the code.

It is very limited what you can keep in your brains working memory at any given time. So for any non trivial program the task to completely understand it is not feasible.

The real task at hand is to

  1. limit the amount of code you have to understand
  2. make it as easy to understand as possible

The key to that is abstraction!

Let me ask you a question: How often do you use a HashMap or what ever the equivalent in your preferred programming language is used? Probably many times a week, right? But how often do you actually look into the source code of a HashMap? Probably next to never! We just know what a Map does and that a HashMap is one very good general purpose implementation of it. That’s all we need to know about it. We just use it. We just know how it behaves. We just understand what is going on when it get’s called.

If your abstractions, i.e. your methods and classes are just like that, you don’t need to look at their source code most of the time. You just read the name and you know what it does. You probably don’t know how it does it. At least not in detail. But you don’t need to. If you know what it does, you know enough to decide, if you need to step into that class or not, for what ever you try to achieve right now.

Of course if what your classes and methods do isn’t as obvious as a get on a HashMap you still have room for improvement.

Logging Antipatterns

As we hopefully all agree good logging is a great asset. Yet I come across aweful styles of logging (and sometimes produce them myself). So I guess it is time for a small Antipattern collection.

No Logging at All
Exception Handler without any code are an obvious example of this, but reading a configuration file without giving a hint which whan you are reading and what you found in it also belongs in this category
Wrong Log Level
logging the discovery that you can’t connect to the database of the application in DEBUG level, or logging entry and exit points of method with ERROR level are typical examples. Always remember: Once in production the log level will probably risen to WARN or ERROR and you gonna still want to see the important messages, don’t you?
Catch Log Throw
In a catch block the exception gets logged and then thrown again, possibly wrapped in a new exception. When this anti pattern is used in many places the result is a log file that contains every stacktrace in a dozen repetitions and variations. A nightmare when you try to understand what is going on.
Logging to stderr or stdout
System.out.println and ex.printStacktrace() are easy and fast to write, but their result will probably disappear in /dev/null once your application is running on a production server.
Complex Logging Statements
When the message for logging gets constructed in a convoluted way with lots of function calls, there is a serious risk that you end up with a NullPointerException instead of a proper logging entry. This is especially true when we try to log inside a catch block. After all something went wrong in the first place, so NULL values a everywhere

The Cost of Modularity

Lego is such a great thing because it is made of simple components. When you build something out of it you can take it apart and build something different out of it. It is fun. If a piece breaks you can take the model apart, replace the broken piece and reassemble the whole thing. Great.

Of course this modularity comes at a price. Building the model of a fighter jet from Lego is much more difficult then building it from a plastic construction kit. Also the result of any Lego based attempt will look a little ‘bricky’. On the other hand, try to build a ship out of your fighter jet construction kit.

So there are benefits to modularity and there are benefits to sacrificing this modularity.

This is pretty obvious, isn’t it?

Yet in software development modularity is required almost every time, without considering the cost of modularity.

Also in software development modularity is sacrificed to budget and time pressure immediately, often before testing and documentation, also without considering modularity.