“The difficulty with working with a programmer is that you cannot understand what he does until it is too late,” Seymour Cray.
Let's understand the terminology:
Test code is code that is covered by unit tests. Unit tests are tests that allow you to test functions, methods, classes, components. Do they perform the functionality that is expected of them with the specified input parameters.
Accompanied code is a code whose logic can be traced well at a glance, new functionality is added to the existing one at minimal cost and without an insistent desire to rewrite everything from scratch. Such code is usually distinguished by conciseness, a good naming, weak connection of classes and functions.
There are several groups of people who can evaluate your result:
- product owner
- analyst (evaluate your work according to acceptance criteria);
- fellow programmers (for them the uniform style of your code with the rest of the code is important, as well as the absence of errors from the point of view of programming);
- testers (make sure that the code does not break the previously realized potential).
As you can see, the criteria for evaluating your work are different for all 3 groups, but all have one thing in common – absolutely everyone needs a testable and maintainable code.
We turn to how to write it. To do this, you must follow simple rules. You will find them in the Code Style project, you can also use the best practices of other companies. Many rules are universal, some are applicable to certain languages, but all of them help to make the code more readable, easier for other developers to understand and to avoid bugs.
What will help you write the accompanying code:
- Learning the Code Style of the project – there are many examples on GitHub for each programming language (Airbnb, Google and others),
- Mandatory passage code review,
- acquaintance with the project code written by more experienced colleagues,
- the study of design patterns.
To make your code more convenient to cover with tests, stick to the following recommendations: use clean functions, put common code into utilities, do not pass unnecessary information to methods, separate logic and visualization from the model, try not to use singleton and implicit dependencies.
Over time, compliance with these rules will become a habit, and your code will already be adapted in advance to write unit tests.
Feel free to seek the advice of more experienced colleagues – learn how they write code, ask them to rate the code you wrote, ask if everything is clear in the logic of the code.