As an application grows, it becomes increasingly difficult to make changes. It is mainly due to dependencies. One module depends on another, which depends on the piece of data. You change one part, and all the changes cascade through all the dependent modules.
Of course, the degree of impact depends on how well you designed the project. But in any case, there is one golden rule, the bigger the project, the more connections and dependencies there'll be, and the more difficult it will be to change things.
The only effective way to check if everything is good is through automated tests. You've probably noticed that Hexlet automatically checks all the exercises. These are the same kind of automatic tests. Often tests are written before the code, which is the case with Hexlet. The tests are there, but you still have to write the code. This approach allows you to check the performance of the required code quickly.
Automated testing is a pretty big topic that no professional developer can avoid. The sooner you learn how to write tests, the better you'll become as an expert and the more reliable your code will be. But writing tests is a whole story. We designed Hexlet courses in such a way as to influence you to open test files and analyze their code. The more often you do this, the better. If you do not know what to do, look at the tests.
Writing tests (especially pre-code) is part of a methodology called XP or extreme programming. It includes best practices to help you write quality code. Here is a list of them:
- Testing
- The planning game
- The customer is always nearby
- Pair programming
- Continuous integration
- Refactoring
- Frequent small releases
- Easy design
- System metaphor
- Code design standards
For full access to the course you need a professional subscription.
A professional subscription will give you full access to all Hexlet courses, projects and lifetime access to the theory of lessons learned. You can cancel your subscription at any time.
