Posted on October 05, 2014
Dealing with legacy (accepted euphemism for manure) code is an integral part of every company that develops software. You cannot escape it; you cannot avoid it, you can only roughly manage the level of it in the codebase. And because of that, every piece of code eventually gets to the point where it has to be up-cycled so it will meet with the new business requirements. What it, usually, means is that it needs to be faster, better and stronger. And this is what we will do today. We will start by looking at some awful code, analyze the shortcomings, figure out how to overcome them and, eventually, turn this piece of legacy into a scalable service.
Let’s start with a code sample. Initially, I’ve planned to write something bad, but then my luck turned, and I saw
py_mail_check.py in my
~/misc. Just by the name I knew it was good, and cat didn’t disappoint. Let’s have a look
What a mess it is, and I do not mean it in just one way. Luckily enough it came bundled with the mail_list file:
So let’s start from the top. This code seems to take an oddly-formatted file, process every line of it for email details and try to login to that email address. If the credentials are ok, we save the result to file “good”, or if they are wrong then to file “bad” instead. A simple concept but the implementation is lacking, and it creates quite a few issues for itself:
Those are all major issues, and we will be fixing them all very soon. But before we get to that let’s fix one issue I didn’t mention, but is the most important one – writing a test. If your code doesn’t come with a suite of tests then how will you know whether it’s working? And while tests do not necessarily have to be automated, there is nothing wrong with going over a checklist, they have to be there. And in written form, not in your head. To write a good test you first need to define what are the use cases and their expected results. Here we have two:
The flow of such test is fairly simple:
Writing automation for this checklist, I will leave to each reader, consider this as blog-homework that won’t be graded but is a good exercise!
With test ready we can finally touch the code. I want to embed the habit of writing a test before any code into your brain as it will benefit your greatly in the future. The very first thing we should do is to fix the issue that may crash our application – the two massive lists. As it is now, the script buffers the results of its work before writing them down to file. Quite frankly the buffering part here doesn’t make any sense (and it rarely does) so we should just get rid of it and replace it with a direct write to the right file.
Now, with the danger of crashing already out of the way lets refactor this code into something more readable. The very first thing to do will be to move all the logic of processing a line into a function. Since it will be checking emails, we will call it check_email. While doing so, I took the liberty of moving definition of bs outside of try; catch block and refactoring the variable names to something sensible.
Isn’t that pretty? In couple easy steps, we have transformed pile of manure into something that is not only works, but is also easy to understand and comes with automated test to ensure that it’s working as intended. But we are not done yet as there is an outstanding ticket left – making it work with more than one line at a time.
While python comes with many excellent options for parallelizations, in case of this script I find multiprocessing.Process to be most suitable. For many reasons, but most important ones will be that we don’t care about controlling amount of workers, or need to exchange any data between them. It is also easiest one to implement – just have a look:
That is all there is to it – two lines of code, and now you will be utilizing every piece of CPU that is there to spare. The way it runs it will create processes as fast as possible, so keep that in mind as with large volumes amount of emails to check it may bring loads beyond what is sane. But don’t worry, having thousands of processes like that will, most likely, not cause any instability contrary to what some people say. But if you are concerned about it, feel free to replace the launcher with more controllable solution. A quick hack would be put a sleep() after starting each process.
And that is it for the first part of the article. While it may not seem like we’ve done much, we did quite a lot. Becuase the process you’ve seen here can be applied not only to small random scripts. By applying it, you can chop down and rework any piece of code you will find, including large spaghetti monsters that plague large systems. All you have to remember is to keep on breaking it down into functions, and writing tests before you do so. Small steps get you far.
In the next part of the, up-cycling series, we will convert this script into a clog of a large machine that is messaging system. We will also, with the help of behave, put our tests into much more structured manner and see how, as a result of all this, maintenance and expansion suddenly became very easy.