Limit your abstractions

“You can solve every problem with another level of indirection” they say. But don’t be fooled! Full quote goes something like: “You can solve every problem with another level of indirection, except for the problem of too many levels of indirection”. And keep that in mind when writing your code.

I’m currently working on refactoring quite important piece of code in big, complex project. Fun thing to do, I enjoy it tremendously. But I’m new to the project and I’m lost in the code. Thankfully I got some sequence diagrams and sequence diagram along with long explanation what this part of system does and why. Then I looked at the code, trying to debug it few times to know where I am and what I’m working with.

What I saw there looked nothing like the diagrams I got. After few hours (days?) I could find some relation between code and description I received but it was way to hard. Even though the system is complex and functionality of this part is not exactly piece of cake, the whole thing had so much code and so many different layers that it is sill nearly impossible for me to tell where am I and what the code does in this place.

Interfaces are cool. Extracting functionality to small, well defined classes is what I like. But once you start jumping between five or six different classes to complete one small action you start feeling that something is definitely not right. At the moment I have opened something like 20 or 30 different classes to go through the workflow, and this is just preparation for actual calculations happening in different place (thankfully this is the part I’m not going to touch this time).

It may feel better to extract class from one piece of code. But I’ve noticed that the same type, Report in this case, is represented by four or five different classes with slightly different naming and functionality. But it is still exactly the same report in exactly the same system! Why not just settle for one, well defined object? Need to get something from database – jump between three or four objects before you will get to actual query.

Flatten your abstractions. Extract classes where needed, but don’t hide everything behind interfaces when not needed. Those are your domain objects, there’s no harm in your main object knowing about exact implementation of one of sub objects, those two are tightly coupled anyway. Sometimes we need to get our hands dirty in all those pesky details. That’s OK, it needs to be done. Extract methods to make it easier to understand. Make code short and concise. But fight the urge to extract every single detail into new class hidden behind interface because it needs to be testable. That’s not how tests are supposed to look most of the time.

So when to abstract things into interface, different class, different layer altogether? I’m not sure myself. Right now I’m just following my guts, making mistakes in fixing them in future when I see that something is not right. One day, I believe, I will master this to create perfect code, but not today and not tomorrow. But I’m getting there, you can be sure!


Learn your shortcuts

How much time do you spend in editor working with code? Debugging it? Hopefully a lot. How much time do you spend working with your keyboard? Hopefully most. Mouses are evil. It takes to much time to move hand to mouse, select option, click, move hand back.

But there’s a better way! Learn shortcuts! Visual studio have lots of them. Resharper too. Web browser? Sure does. Total Commander? Windows? Vim? Shortcuts all the way.

I always tried to learn how to do things with keyboard rather than mouse for more efficiency. Some time ago I started writing stuff in Vim. That’s when I learned mouse is mostly useless when writing stuff. Now I’m back to good ol’ Visual studio with Resharper and I usually don’t even think about touching mouse. And I cringe when someone’s searching menu with mouse or (God forbid) clicks right mouse button to do something.

First – shortcuts are simple. So simple that after few usages, your fingers will remember how to do them without you thinking about what exactly needs to be pressed. Ctrl+Shift+B for build is as natural for me, as Ctrl+S ever was. Ctrl+U+R, Ctrl+U+U and Ctrl+U+L are so natural for me that I had to check this shortcut right now because I didn’t remember it. My fingers do – when I’m in VS they know what to do. F9, F10, F11 – you all know them in debugging I hope. What about Ctrl+F10 and Shift+F11?

But I don’t know all the shortcuts. When and how do I learn them? I go with simple rule of thumb – if I’m doing something once – that’s cool, I can click it. Second time – well, ok – I will go with you one more time, you evil mouse! Third time? You won’t trick me, I’ll google the shortcut and will google it again and again until I’ll teach my fingers how to do it properly. No more pointing and clicking.

And my hands are better on keyboard as well, holding mouse is fine only when I’m shooting at those filthy zombies. Left 4 Dead – here I come!