7 deadly sins of a software project

Maintainability is the most important value of any developing software product. Maintainability is measured in the working time needed by a new contractor to study a product before it starts making significant changes to it. The more time spent on this, the lower the maintainability. In some projects, this time tends to infinity, which means absolutely unsuitable for any support or modification of the product. We believe that there are 7 fatal errors that lead to the creation of such unsupported products. Here they are.

Antipatterns

Unfortunately, all modern programming languages ​​have too much flexibility. They allow too much and prohibit too little.
For example, Java is not opposed to putting an entire application in a single “class” using 5000 different methods. Technically, the application compiles and runs, but this is a well-known antipattern called the Divine Object .

Thus, the anti -pattern is a technically permissible development method, generally known and erroneous. In every language a lot of such antipatterns; their presence in the product is similar to the presence of a tumor in a living organism. As soon as it begins to grow, it is already impossible to stop it. Ultimately, the whole organism perishes. The whole software product becomes non-repairable and must be rewritten.

As soon as you have allowed one anti-pattern, they immediately become more and more, and this “tumor” only grows.

This statement is especially true for object-oriented languages ​​(Java, C ++ , Ruby, and Python), mainly because they took a lot from procedural languages ​​(C, Fortran, and COBOL).

Always try to treat your project with enough skepticism and do not relax if it “just works.” The sooner you diagnose a problem, the easier it is to cure it.

Untracked changes

When working with any software product, you should at any time be able to explain what has been changed, who did it and why. Moreover, the time required to get answers to these questions should be measured in seconds. For most projects this is not the case. Here are some practical recommendations:

Always use tickets. No matter how small the project or the team that serves it - even if you work on it in splendid isolation, always use tickets for any problem that arises. Explain in two words the essence of the problem, fix your assumptions. Use the ticket system as a temporary repository for any information relevant to the problem. Capture everything that might make sense in the future when someone else tries to grasp “ something strange is happening to the product.”

Link to tickets in commits . There is no need to teach that every commit should be accompanied by a message. Commits without messages is quite a nasty thing; nevertheless, just a message is not enough. Each message must begin with the ticket number you are working on. Many web services , such as GitHub, automatically link commits to tickets, improving the traceability of changes.

Do not delete anything. Some web services for hosting IT projects allow you to rewrite the entire branch that previously existed on the server. This is just one example of how you can destroy the history of a software product. On such web services, many delete comments in discussions to most tickets so that the discussion looks cleaner. This is fundamentally wrong: never delete anything. Give the history of the software product the right to exist, no matter how bad or confusing it may look.

Ad hoc releases

Before delivery to the end user, each software product must be packaged. If it is a Java library, it must be enclosed in a .jar file and unpacked in any storage. If it is a web application , it must be deployed on a platform, and so on. It does not matter whether the product is bulky or not, there are certain standard procedures for tests, deployments and delivery forms.

The ideal solution is to automate this procedure so that it is possible to execute it from the command line with one command:

Many projects are far from that. The processes of their release are always something magical, when the person responsible for this (also known as DevOp) has to click on certain buttons here and there, log in somewhere, check certain indicators , etc. Such releases are called ad hoc releases they are typical for the entire industry.

There can be only one tip: automate the process.

Volunteer static analysis

Static analysis - this is what “combines” the code. By making him look better, we ensure his best work. However, this happens only when the whole team must follow the rules dictated by the static code analyzer.

Be sure to use a code analyzer. In most projects where a code analyzer is used, developers simply make a beautiful report based on it and continue to write code further - just as they did before. Such a “volunteer” approach to static analysis does not do credit to a software project. Moreover, it simply creates the illusion of good quality.
Static analysis should be a mandatory step in the product development pipeline, and its rules should not be ignored.

Unknown test coverage

Test coverage is the degree to which the software passed the integration test. The more coverage, the more code was executed during testing. Obviously, high coverage is a good thing.

However, many developers do not know what their coverage is: they simply do not measure this indicator. It is possible that they conduct some tests, but no one knows how deeply the software is being tested, and which parts of it have not been tested at all. This is much worse than the bad test coverage, which you told everyone you met.

Of course, high coverage is not a guarantee of high quality. But unknown coverage is a clear indicator of problems with the functional reliability of the product. When a project falls into the hands of a new developer, he or she should be able to make any changes and see how this affects coverage. Ideally, test coverage should be checked in the same way as static analysis, otherwise the build will fail if the coverage is below a certain level (usually 80%).

Continuous development

Under the continuous here means development without time frames and releases. No matter what type of software you create, you should often make releases and change it. A project without a clear release history is simply unsupported software confusion. All this is because the ability to support a product is if, for example, we are able to understand you by reading your code.

Looking through the source code and the history of its releases, everyone should be able to determine the intentions of its developer, say, a year ago, what is happening now, future prospects , etc. , etc. All this information should be in the source code.

Some web services for hosting IT projects , such as GitHub, have strong tools for creating such information. If they are - use them to the fullest. Remember also that any binary version of the product must be available for immediate download. You should be able to download version 0.1.3 and test it right now if the project is currently working on version 3.4.

Undocumented Interfaces

Each software segment has its own interface through which it is supposed to use it. If it is a web application , there are web pages that the end user will see and with which he will use the application. Each interface must be documented.

Like all the above, this fact refers to the ability to support the product. Any new programmer begins to study the project from its interfaces, and everyone must understand why an interface is needed and how to use it.

We are talking about documenting for the user, not for the developer. In general, we are against the documentation inside the software: working software is much better than clear documentation for it. But this does not apply to "external" documentation, which is supposed to be used by users.

End-user interactions with software must be documented. If your program is a library, then its end users are developers who do not develop the product, but simply use it as a “black box”.

All of these criteria are used for open source projects.