ArtemKondratyev.net - Programming - Articles

[Back to articles]

Developer's Dream

Introduction

What do developers want more than anything else? I suppose I can tell. Well, there are just two things that can make them happy (not coffee, actually):

First, they want to be sure their code works when they check it in.
Second, they want to know they can easily and quickly reproduce the bug if it happens.

Aren’t these the same things that the world waits from them? I guess these are.
So why do developers sometimes check in code that they never executed? And why they often spend so much time fixing their simple mistakes? Is it because they are bad programmers? My answer is NO. I don’t believe in malevolent, lazy and careless developers. Every developer wants his/her application to work fast, correct and to bring happiness to others. But here could be obstacles.

The bad environment is a reality.
The bad architecture is a reality.
The bad infrastructure is the thing that I’m sure that it exists.

These things break our dreams and make the bad habits so tempting.

Everyone will do things right way if this will be the easiest option.

I will try to make my suggestions concerning how someone can turn these dreams to reality. They are basically directed to the system architects and project managers. But I think they will be loved the most by developers.

How to be sure the code works.

It’s not too hard:

Your code should be accessible.
You should have the representative data to pass to the code.

Let’s look closer.

Your code should be accessible.

The code isn’t accessible when all the functionality is hidden somewhere inside. Somewhere inside could be in the background, server-side processes. This also could mean in the private parts of the code.

The code is accessible when you can easily and quickly execute any part of it.

Make all the functionality to be accessible through public methods.

Don’t hide a bit more complex than trivial code inside classes. The bit more complex than trivial code is the one that you would like to test. You need to have an ability just to call it and not to waste hours trying to bring the system into the state in which it calls your method instead of you.

Don’t be afraid to write the code that’s purpose is just to make testing more simple and nothing else.

I encounter the heavy opposition all the time I work in the software development industry when I propose to do some extra thing that don’t implement some functionality. In spite of popularity of the test-driven development theme, one of the strongest stereotype still be the following: “Tests are utterly complementary”. Don’t forget that tests are the first user of your application.

Write test frameworks.

If it is too hard to access the code executing in the background, execute it in the virtual environment. Spend some time to create this environment. You will get happy as a reward.

You should have the representative data to pass to the code.

Sometimes it’s very simple to call the code but it requires the object that is too hard to create. The good example is the database stored procedure. You can call it very quick but sometimes you should have the whole database in the right state to get the meaningful result.

Collaborate with testers.

From my experience, testers often have different useful things as backups, system snapshots, scripts, and so on. At least they have more of these things than developers. So, often it’s enough to just ask.

Request time to prepare test benches.

From the other side, you can always do it yourself. If testers can, why don’t you? It’s not so obvious. The answer is that you do not have a time. When you need to implement some feature that can be implemented for 2 hours, you want to implement it for 2 hours. You don’t want to spent whole day preparing the representative data, writing the test suite, making the process reproductible and so on. Not because you don’t like it, but because of you fear that your boss will not understand this. If your boss is the lead developer he/she can just say: “Man, I can write it for five minutes. What’s the problem? Don’t waste your time – our goal is to supply features, not amusing ourselves”. I don’t actually know how to choose a right boss, but it is an option to think how to argument your will to create some falsework.

How to reproduce the bug quickly.

You should write messages to yourself.
You should have the system state snapshot to reproduce the bug on your PC.

Well, let’s look closer again.

You should write messages to yourself.

When something goes wrong you would like to know the details.

When you write the error message text remember you will be the reader.

That exactly what I mean when I say “Write messages to yourself”. Think what you would like to see in the message when you will read it. Don’t put the string like “Import failed: something wrong” in the message. Try something more specific, for example "Failed to import customer. Bad [date of birth] format. The value is: [value]". Fortunately, it’s all under your full control.

You have a right to log everything that you need.

There are always persons who don’t like details. They tell that users should not see call stack, the system administrators should not know what we do with its system. That people wants to save disc space that log consumes, and to keep the production code clear from logging actions that "litter the code". They want you to be clairvoyant that can find the error without any evidence. Be reasonable, anyway) Consider the ability to apply filtering when logging.

You should have the system state snapshot to reproduce the bug on your PC.

Sounds good, isn’t it? But this ability cannot be reached without significant efforts. System architecture should provide this feature. For example, if your system architecture doesn’t contain the business layer, the user interface will interact with the database directly. In this case you will need to have the whole database backup to reproduce the situation. It’s an option when you test the system, but try to get the backup of actual production database! Impossible – because of VERY large size and the security policies.

Consider the way to store the part of data that depends on the entity that caused an error.

For example, if you use the dataset in your application layer to store the data, you can easily serialize the dataset into the Xml file. But if you will not have the ability to restore the dataset from the Xml – you will get little benefit from this feature.

Consider the business logic layer.

The business logic approach actually gives you a pretty great number of advantages. One of them is the ability to test you system disconnected from the database (you can create objects in memory only). Another one is the strong-typed access to the database entities (in the database you typically use primitive types only, not classes as in the C#, for example). After all, it gives you a pleasure to write code on higher level of abstraction (delivering your from low-level details, such as cross tables). All these features make you life easier and the development - more rapid. But in the current context we are interested in the ability to store the actual system state with serializing the business objects graph on the tester/user workstation and deserializing it then on your PC. In this case you get that part of data what caused an error.