What notions do we produce, when we think of low quality software? Probably, we think of programmes filled with bugs, that are the cause of problems in working with them, or even before launching them. During the software development process, inheriting low quality code, and the necessity to work on it is often a much bigger challenge, than designing a solution from scratch. There is a reason, that employment offers for programmers often contain benefits such as an argument informing that work will focus on a new project, and not on software with a lengthy history, bad documentation, on which, through years, many people have been working, with whom the company doesn’t have relations any more.

Code smell and design smell

In theory, a safe programming language is the one, in which the compiler will not allow for code compilation, when there’s an error in it. Furthermore, each case of such a faulty code piece, should be well described in the programming language documentation. The strenuous debugging process, i.e. finding programming bugs, that impede code compilation, is an incredibly important part of developer’s work. However, in practice it turns out, that even the safest language and the best compiler are unable to protect the project from, let us put it delicately, not entirely successful logical concepts in code. Often, a simple problem is solved in a very complicated and hardware strenuous way, and still, is not a bug in a strict sense, and will not be detected by the compiler. This results in software comprised lines of code counted in tens or even hundreds of thousands, that are based on a flawed solution, and therefore, will never work right.

In this situation, we talk about code smell. There are many factors, that make us face this phenomenon. Among those that occur most offen, one should primarily list all duplicates, i.e. the appearance of the same part of code in many places. Programmers often allow themselves to design software in a way in which each change must be applied to many classes at the same time. That is what we call shotgun surgery. Essentially, code smell can be found on every level of code: in entire application, but also in particular classes or methods. On each level, we distinguish particular types of complications (as, in this case, we cannot speak of bugs in a strict manner), and each of them may result in code that will be useless as a software. Apart from code smell, we also distinguish design smell, i.e. missed ideas, however not in terms of programming, but rather architecture. In that case, we speak of entire flawed concepts, and not only repetitions of code blocks.

What is software refactoring? 

In case of software, which bears the mark of code smell (or design smell), a casual source code check up in search of smaller bugs will not do, as sometimes entire components must be rewritten. It is possible that an old, low quality code together with numerous models already built over it don’t function properly. As we already mentioned, sometimes it is best to discard such a code and start from scratch, however, one cannot always afford that option. Backwards compatibility, wide distribution, an enormous number of dependencies with other programmes, are only a number of reasons, for which even the worst quality code must be taken under a process, resulting in elimination of the code „smell”, i.e. the process of refactoring. This type of process drastically increase the performance of the programme, and simultaneously, do not expand its functionalities. The entirety is focused on quality.

One may say, that the primary aim of code refactoring is eliminating redundancy, i.e. an excess of appearing elements. The process may be associated with the golden rule of the economy of reasoning, i.e. Occam’s Razor which states that entities should not be multiplied without necessity. In the colloquial 21st century, the motto assumed the form of the KISS acronym, meaning – Keep It Simple, Stupid. Therefore, refactoring primarily aims at freeing the code from elements that reproduce their functions. Afterwards, the entirety is adjusted to the adopted standards and good practices, in order for the code to not only be clear, and comprehensible, but also to fulfil its functional applications, and, after compiling and execution, to work in a way satisfactory for the user.

Finding the excess class in 50 lines will not be a problem, even to a beginner, but what if a programme is comprised of hundreds of thousands of lines, overlapping in their evolution through many years?

Such project may surely outgrow many companies, and we are mostly talking of situations, where discarding software is no solution, e.g. by reason of the aforementioned necessity to ensure backwards compatibility. Refactoring is extremely time-consuming, therefore, some organisations cannot afford to transfer all resources to execute this one task. Obviously, that is where outsourcing comes in. There is no lack of expert teams, that forged code refactoring into their specialisation, and posses knowledge, experience and tools to execute this process more efficiently than the programmers employed by the company itself. By the way, it is worth to turn attention to the aforementioned tools. We already mentioned, that refactoring is, in many cases, a strenuous and schematic work, primarily based on detecting and eliminating redundancies. Does it not sound like a perfect job for machine learning algorithms, or, as some would prefer to call them, artificial intelligence?

How about machine learning?

Well, yes and no. It is correctly expected, that we are capable of training algorithms effectively, so that they can detect defined patterns on the basis of machine made models. This way, one may successfully apply automation in detecting redundancies, and eliminate code smell. However, the reasons for which the code requires refactoring, are obvious and clearly visible. An example is the design smell, a shortcoming on the level of concept of solving a given problem. The best frameworks of machine learning available at the moment, provide us with artificial cognition, however, machine cognitive processes are not capable in terms of observation and conclusions. It is a common argument of programmers, who are confronted with the perspective of technological unemployment that awaits them. Indeed, one may teach a machine to write code, and it is possible that it will be generated this way in the nearby future. However, we still do not posses larger accomplishments in teaching machines to solve problems, and exactly this process constitutes the initial and most significant element of the job of a programmer.  

Refactoring has a future and a lot of already existing systems will need to be modernised.

The aid of machine learned algorithms will not always be helpful here, as issues may lie much deeper, not only in redundancies of particular code fragments. For the majority of time, flaws and missed concept ideas will be detected only by humans, and it will be best tackled by people with experience in refactoring. In this situation it is worth to consider commissioning this incredibly time and resource consuming process to external companies. Take advantage of outsourcing.

Do you want to ensure your system is developed with respect to industry standards?  
Read about our software audits services, improve your system and enjoy your business’ growth.