As soon as the developer gets into the company and gets the task, it often turns out that he needs to join the overall project of some team, rather than writing his code from scratch.
Any code has its own logic, is based on certain principles, it contains patterns and technologies specific to the team to which the programmer has joined. But how to quickly begin to understand someone else's project, while it is hardly small, and the documentation is often either not at all, or it is insufficient and inaccurate?
We remind: for all readers of "Habr" - a discount of 10,000 rubles when recording for any Skillbox course on the promotional code "Habr".
')
Skillbox recommends: Online course "Profession Frontend Developer" .
In fact, the best documentation is the code itself and those who created this code (provided that they are still somewhere nearby, and have not left the company). How can you reduce time costs to a minimum and quickly get to work, making your contribution?
I have repeatedly encountered this situation in the last 15 years of my work as a programmer, and here are my thoughts on this.
Project Goals and Objectives
The first thing you have to do is spend some time trying to figure out what task (s) the application whose code you are creating does. This is a global challenge; deciding it, you can handle everything else.
You can not work on a project without imagining why it is needed at all. A common understanding will allow you to more quickly understand the details. In addition, your own work will be done more smoothly with the rest of the team. Brick by brick - and the house is built.
Architecture
After you have learned the main task, devote yourself to parsing the execution of the code and its logic.
The architecture of some projects is quite complicated, especially if the basic technologies of these projects are not very familiar to you. At the very beginning, try to find technical documentation (or ask colleagues about it) in order to see the main logic.
Bearing in mind the structure of the project, you can quickly start work, and so as not to interfere with the functioning of all other parts, which are engaged in other team members.
The project may contain fragments that violate the common logic, but, knowing the idea and architecture, you will be able to fix the problem, rearrange or change the "bricks" so that they fit perfectly into the general building.
Patterns
There are a large number of patterns used by developers when writing code. These are structural patterns, "behavioral", technological and others. All of them help to typify ways to solve common problems when designing programs.
Understanding which templates are used in your current project will help, at the class level, to understand how functions should be built into the code. As a result, you will be able to create a coherent code that will correspond to common logic and patterns, which ultimately will lead to a much smaller number of comments on the code, a better understanding of it and prompt elimination of errors if necessary.
After working a little on the project, you can see at a glance which parts of the code fit into the overall structure, and which require refactoring.
Guidelines
Most teams have certain rules, or rather, a set of rules, according to which everyone acts. It is not only about the general principles of work, but also about the use of classes and application levels. If team members are guided by the same guidelines, then the code being developed is easier to understand and read.
Most likely, the team you join also has guidelines that you need to learn. First of all, they concern the programming language that is the main one in development.
You may ask where in general to get all the information about the project, its architecture, patterns and guidelines. There are several methods of obtaining the necessary, except those that have already been voiced above:
- Look for any information, even that which can be considered irrelevant; Build your own knowledge base of common terms, abbreviations and concepts that your team uses.
- As soon as this database is ready, you can discuss all your questions with the project manager, since you already speak the same language.
- In addition, it is worth talking to the application architects and timblids about the overall architecture of your project. Then try to learn more about this architecture and how to optimize the code associated with it. If you see something that you think violates the general logic of the application, be sure to discuss it with the team leader.
- Find out from teammates which templates and rules are used in the course of working on the code - both when writing and for further maintenance. After you learn the main points, compare what works best and act accordingly in the future.
- Try to clean the code from potential and real problems - this will help you get a deeper understanding of the project and its code. What does your team use when restoring order in code?
Generally speaking, refactoring is the best opportunity to engage your team in a discussion of which guidelines should be reviewed and which ones should be used in the future.
Share your own work with the team, actively participate in working meetings, discuss current problems, the architecture of the application and its elements, templates and other important points. Work meetings can be a reliable channel for more information; they should also talk about their observations / achievements, that may be useful for everyone.
As a result, you can not only quickly start work, but also join the team, becoming its indispensable member in a short time.
Of course, you will meet people with whom it is difficult to communicate; problems will be with the code. But this happens almost always - there are teams where everything is perfect, but they are few.
Skillbox recommends: