Software developers often think about how to create and release an information system (further mentioned as IS) only. But if the IS is really important for a customer business it can live for years and it could be changed in process, being adopted to changing business logic of a customer.
When you need to implement new requirements in an already released system you will often face next problems:
There could be many reasons for these problems, but one of them is a code quality. In this article I will tell you about some of our approaches to create a code that would let us to minimize chances of facing the above problems.
We should speak only about the code quality and will not mention architecture, development framework choice, quality assurance, project management and other important aspects. Perhaps we will talk about them in the next articles.
So, what could be done to improve quality of a team code?
As we already know, version control systems are used for code storage, code access for all of the developers, resolving issues with parallel work of several developers and providing the opportunity to rollback unsuccessful changes. Yes, that is all correct. But, as an important addition to this, version control system is a part of an inner system documentation, and quite unique one: it helps to determine when one or another behavior was implemented and why this change was done.
So, we have two main requirements for the working with the version control system:
The main code quality criteria for us is its understandability. If the system is growing and it is actively used then its code is much more read than written. Often you will need to change the code much later than it was written, and, often too, you will not be the original author of it.
So, how to obtain easy to read code:
Same code styling rules often seem to be unimportant, but, practically, it gives a serious improvement for the team work as a whole. Not needing to “mind-switch” when reading the different parts of the code significantly helps on understanding the code fast. And more, the code styling rules help to avoid insignificant changes in the version control system.
The code must be accompanied with documentation and inner comments. Most companies do have strict requirements to entirely cover all the code with comments and, also, describe in detail the structure and the behavior of the code, up to a single class, in an external accompanying document. From our point of view this pattern is not very reliable, because it leads to too much labor costs and it is often the risk that comments and documentation would differ from each other. As a result, you will need to read the code anyway after you have read the documentation. It is much more productive to concentrate on writing code that is understandable without any specific comments and use comments only in most complex and unevident places of it. And the external accompanying documentation must describe its architecture and behavior on quite a high level instead.
Of course, this is all about the system’s inner code. All external API must be completely described and documented.
Very important and effective variant of a comment is a comment in a version control system, like we told above. This comment is always time bound and change bound, so it never could grow old. So, this comment is never needed to be kept in an actual state, but it always allows to understand who, when and why did a specific change to a system behavior.
You never can automatically check how understandable your code really is. The only way to control it is the mutual code review by the developers. Any changes or additions to our code are always reviewed by other team members. This process helps us to complete next tasks:
Code reviewing is done by the members of a project team. At first, this insures knowledge share about a system between the team members. Second, this increases effectiveness of a code review, because, obviously, the reviewer must know what the reviewed code must do and the end purpose of doing it. Otherwise, the reviewer could only find syntax errors, typos or obvious mistakes, but he could not find the flaws with business logic realization. Usually the review is made by a team lead, but the developers review each other’s code too. The code written by a team lead is also reviewed by other developers.
After a review, found errors and flaws are fixed and then code goes to a new review iteration. Functionality implementation is count done and ready for testing only if the last review did not add any issues. It is well known that the sooner you find the error the easier and less costly is to fix it. Making a release to a test environment and getting test reports from QA takes more time than a code review inside a development team. So, fixing the issues by regular code reviews is going significantly faster.
All patterns mentioned above usually work great as a whole. Version control systems and specific code styling rules allows for effectively reviewing and correcting the code, and code reviews help to control understandability and quality of the code. As a result, modifications of a system are usually done faster, and release for the QA department contains less errors. QA department does not take so much time to register and recheck the evident errors and could use more time to test some complex system behavior. And so, as a result of it, the customer gets more quality product.
Based on our rich experience, the implementation of the above-mentioned practices helps several of our systems to work for our customers for years, being regularly expanded and improved according to changing business requirements.