Month: March 2019

How To

Best practises for working with legacy code

Episode 1 – how to organize lost code and deal with it without panic.

There is a nightmare that keeps haunting and haunting developers. It’s called refactoring of an existing product. It is not a secret to anyone, that a legacy code is often considered to be developer’s worst enemy, but at the same time we all know there are situations when there is no room for developing the project from scratch, e.g. because it’s an existing commercial product or simply because it has been continuously developed for 10 years already and the client does not have another 10 years or any other means to develop it again. It’s not a secret that such kind of jobs are not the most desirable, but they happen and give you a choice: to sit down and cry or to take it and find a solution.

Fortunately, you are not alone – since we have already saved a number of projects since the beginning of our company in 2002, we consider saving somebody’s butt as one of our core expertises. Fighting for a better world for developers, we have decided to share our knowledge, experience and interesting cases to write a series of blog posts about refactoring and taking over development of existing products, which appears to be one of the most hated problems in modern software development.

Let us start then, enjoy responsibly!

In the first article we should obviously start the first steps to follow when starting to work with an existing codebase developed in Java.


So, there is a nightmare out there that keeps haunting java developers – you are taking over an existing project with a huge codebase provided by the client in the form of ZIP archive. Not scary enough? Good, but what if we add that the project is already in the production stage and it is unknown which version of the code is installed on the production server?

Since it is a production environment, you cannot afford the risk of overwriting the existing working copy by something new and possibly breaking it.

And of course, as it usually happens in such kind of jobs, the developers who originally developed the project vanished, so you are in a major trouble.

Of course, we all agree it is better to avoid getting such projects in the first place, but at the same time we all agree as well that sometimes shit happens and you have to do your best to deal with it.

But don’t worry, you are not alone. Below you can find our time-proven practises coming out of experience in dealing with such situations for more than 10 years already.

Step 1: Don’t panic

Abracadabra First of all, understand and accept the fact that in order to sort this puzzle out, you will have to spend some time on investigation. This work is in some part related to the work of an archeologist, who is moving step by step toward the translation of the cuneiform he found.

Remember to stay very careful and for no reason on earth should you hurry. You should backup everything that is possible to backup – folders on the server, etc. and only then proceed with the next actions.

Below you can find some battle-tested recommendations that will help you to solve this issue with no one harmed.

Step 2: Information

Get from your client all the information possible about the source code structure, technologies used and exact versions of the libraries. It often happens that customers has some indirect information on this topic, probably in any correspondence with previous developers – emails, chats and calls.

Step 3: What is running on the production?

Take a look at what is currently working on the production server, like which application server, which version of Java, exact versions of libraries (a hint: in some cases you can calculate that by the names of jar files).

In great majority of cases, the project was most likely created and compiled in the same version of Java as the one on which the production server is running. But, there is a chance that it was not.

To make sure, take any of the classes from the server and use JDK’s utility javap.

If you run this command: javap -verbose <YOUR_CLASS>.class, you will be able to find in the output something like that:
minor version: 0
major version: 50

Now, the meaning of major versions is following:
J2SE 11 = 55
J2SE 10 = 54
J2SE 9 = 53
J2SE 8 = 52
J2SE 7 = 51
J2SE 6.0 = 50
J2SE 5.0 = 49
JDK 1.4 = 48
JDK 1.3 = 47
JDK 1.2 = 46
JDK 1.1 = 45

Thus, you now know the Java version in which the project was compiled.

Step 4: Is our source code valid?

Knowing the correct version, now is the time to make sure the source code that you have corresponds with the classes installed on the production. To do this, apply the following trick:

  1. Compile the source code in the version of java in which the classes on the server were compiled.
    see previous step
  2. Use the decompiler and decompile the resulting classes to a folder. For example, using decompiler plugin built into JetBrains IDEA you can run:
    Destination folder FOLDER_TO_DECOMPILE_TO must exist before you run this.
  3. Use the decompiler and decompile the classes taken from the server to another folder.
  4. Use any folder comparison tool to compare files obtained as a result of decompilation.
    For example, you can use WinMerge utility.

As a result, you will receive a list of files in which mismatches are found. If you are lucky, then there will be only a few or no such files at all.

Step 5: Recover the source code

As the next step, you need to work with each file separately. Where the difficulty lies, is that at this stage of the project you probably still don’t know how everything is arranged within it and which version should be kept. You can use the following methods:

  1. Save a list of such files somewhere and remember to give them special attention in the future and be very careful about them.
  2. If possible, make changes to the source code in a way that will make it as close to the state of production as possible. It is better and safer to spend time on re-implementing the lost changes than to install unverified and unpredictable code to the production.
  3. Use a version control system (such as GIT) so that you can later understand what you changed and what the initial state was.

The above methods should give you a better orientation in project’s codebase and most importantly make you feel more confident and convenient with the project as a result. Now, when you finally can understand that mess and see the correlations with it, it will make it a lot easier to work with the project and move to the next big stage, which is refactoring. However, since that’s a topic not only for a separate article but rather a series of articles, we will give some more recommendations on it in the following chapters.

Technologies / Web development

Java vs PHP

A battle more epic than Helm’s Deep siege.

Since the beginning of time, people have always been fighting because of various reasons and using various weapons. For food, for territory, for lands, gods, women, politics and many other reasons, using rocks, bows, swords, guns, artillery and many other weapons.

Fortunately, nowadays most of the battles we take part in are only intellectual and with much less harmful means. We can battle over who makes the dishwashing, what to watch on tv, or… what programming language to choose. The last one has actually gone out of control on 21st century to become a field of a heavy battles between the developers of each technology, with any means necessary.

That is why, it’s a great topic to elaborate on, especially that just as in majority of such intellectual conflicts, it is hard to get a straight answer on what is better. Actually, the best answer to this question in the answer I absolutely hate: IT DEPENDS.

To not leave you with such an inaccurate answer, I’ve let myself to make a short comparison that could help you to understand what programming language will be best for the backend of your project.

Programming vs. Scripting

Basically, the first thing to start with is the main difference – Java is a general-purpose programming language while PHP is a scripting language designed for web (PHP initially stood for “Personal Home Page”). That’s great, but what does it actually mean? In a short word, Java applications are compiled into so called “byte code” and run in a virtual machine on any platform that supports java, while code written in PHP is by default interpreted at runtime by web servers. Java’s general purpose means that you can develop an application of any complexity, it might or might not be related to web.

Again, great, but how does that affect the application? Generally, the programs that are compiled very often run faster than code that has to be interpreted by an interpreter first (interpreter is a PHP environment installed on the server in this case). What is more, many of errors related to syntax are detected at the compilation stage, like e.g. invalid calls.

Still, obviously the technology is going forward and so are the solutions, so let’s take a deeper look at what are the advantages and disadvantages of Java and scripting languages.



  • Being world’s most popular programming language, Java has developed a large number of libraries. Thanks to that, we can use a lot of existing libraries instead of spending time on writing a custom code for typical operations.
  • Java is time-proven – have always been there and will probably always be there, while scripting languages have fashion-based ups and downs dependable of their popularity.
  • J2EE, one of the most popular Java platforms, is designed for enterprise projects, while scripting languages are designed rather for smaller applications.
  • Multithreading – out of all programming languages, Java has one of the best developed solutions for multithreading, which makes it easily handling multiple threads.
  • In Java, a lot of errors are detected at compilation time.
  • Change requests costs less in comparison to scripting languages, due to strong typing instead of dynamic. This means that when you need to change something, the compiler will detect if it is not compatible with code dependant on it and therefore throw an error.
  • Easier debugging due to the same reason as mentioned above as well as thanks to architecture of JVM, which means cheapest support.
  • Java is a general-purpose programming language, while PHP was originally designed as a web language. This “web” origin sometimes lead to tricky architecture or require a mix of multiple languages in order to implement something, which is not directly related to web.


  • In general, Java requires higher qualified developers. Sometimes you need a few more code lines  than in PHP to implement something simple.
  • Because of the above, if your project is not a rocket-science but rather a simple application consisting of popular features, the cost of its development will be a bit higher when using Java.
  • Requirements for hardware are usually a little bit higher.



  • Developer can usually write the code faster, which affects project cost on first stage – development of MVP is a bit cheaper, which could be a good solution if you are thinking about testing your idea.
  • Lower requirements to the server, especially in terms of memory.
  • Is easier to learn by the developers and therefore requires less experience with coding from developers to work effectively with it.
  • Large number of libraries for various purposes.
  • Cheaper hosting.


  • Higher cost of changes due to dynamic typing. That is because there is a bigger chance to break existing functionalities, as dependencies and typing are not checked by compiler.
  • Costs of maintenance grow exponentially with project size.
  • Less opportunities of adding more complicated functions (e.g. complicated mathematical algorithms).
  • More problematic in terms of backward compatibility.


As you can see, it is not straightforward at all whether Java is better than PHP, or the other way around. Both languages have their pros & cons as well as a number of libraries that can reduce the cost of work and therefore a question of which language should you use is rather dependable on the type of system that you want to build.

PHP was designed to simplify the life of web developers, and it successfully meets its purpose. You can develop and deploy web application within few minutes. But as usual, this simplification has its downsides, in particular, when you need to develop something not so obvious or something tricky – it becomes much more complicated than in java.

Usually, using a scripting language becomes a success-blocker when the project evolves and grows. Big projects that were created with scripting languages require much more effort to manage and maintain. Sometimes at certain stage there is a need to add something tricky to the project, for which scripting language is not enough. So project owners have a choice either to have a mix of languages or to re-write the project from scratch using another language, which is an extremely painful business decision. Still, if you are building a small or medium-sized application, PHP may surely be the right choice.

So, what language will you choose for your project? If you are still not sure, you can type us a message. Our consultant will be happy to hear about your idea and advise the best stack.