The story of one project: when there is no senior developer in the team
From the translator: we publish for you the article of the developer Jack Finlay. Jack talks about his own case - an attempt to organize the work of a team of juniors, where everyone is equal and there is no technical manager. The article will be useful for novice programmers.
Some projects may come to a standstill, to end in nothing for a number of reasons. Technical guidance is something that is often lacking. This problem can lead to a fiasco. Once it happened with a project I was involved in developing.
Skillbox recommends: A two-year hands-on course “I am a PRO web developer . ”
We remind: for all readers of "Habr" - a discount of 10,000 rubles when writing to any Skillbox course on the promotional code "Habr".
Time can teach you a lot. Unfortunately, we gain experience as a result of working not only with successful projects, but also with unsuccessful ones.
Personal experience and leadership
More precisely, the lack thereof. Our project did not have a lead or someone with a senior developer post. In principle, it was already clear what would happen with our work, but at that time we did not understand it.
The team had no experience. Almost all of us were students, and there was no one who could lead us. Then it did not seem necessary to us.
Over the course of one summer, the number of team members increased fivefold. Problem? All were about the same professional level. Everyone lacked experience. We split into several groups, each of which was responsible for something.
And almost all the project participants were good people, responsible. But it was our first commercial project. My team was very good, we worked perfectly, but the result was a failure.
A key component of any professional's work is tools. Without the right tools, a normal process is impossible. A good team usually has a leader who knows who needs what tools and where to get them.
In this project, we had access to a common database hosted on a virtual machine, one of the slowest ones that could be obtained. Naturally, we experienced all the “pleasures” of such work: data loss, falling tables, simultaneous actions on the same elements. All this great braked our work.
We did not have the ability to play the database either locally or in the cloud without performing a backup and restore operation. There was no way to get a “clean” database in the same state in which we would like to deploy it in different environments. The database could only be created as a clone from the database of our server.
But the project worked only with the database, which was located on the working server. This meant that we could not test the base and the project dependent on it locally. Several times there was a situation when we had to roll back the base to a certain point, because at night someone had destroyed it with careless actions. This greatly hampered the development process.
The migration and update of the database was done manually. That meant ... yes, we were losing time again.
Now it seems obvious that developers should have local databases on their machines. In addition, you must use automatic migration tools. This gives developers the freedom and opportunity to maneuver in certain situations.
Developers need high performance of both local machines and the server where the project is being tested. But since we had slow tools, there was no reason to dream about it.
Many had extremely slow devices that had been used for many years. Keyboards, trackpads - all this bore the stamp of time.
Servers were also slow, as I mentioned above. As a result, the whole development process was slow. Tests also progressed slowly.
The conclusion is simple, in the style of KO, - to give the developer the equipment and resources that they need for a normal development process.
It was all chaos. We used the corporate source control system, but the problem was not software. There was just no strategy. Separate development teams worked each “in their own swamp,” and we had no agreement on when we would merge the individual brunches together. The result was what turned out to be: conflicts, conflicts at merging everywhere. We had to spend a lot of time solving problems and correct synchronization.
Integration and Deployment
We didn’t have any CI / CD solutions at all. The deployment was simple: we copied resources from the built-in folder and pasted them into the server via Remote Desktop. If you did something similar, you can understand my pain.
For those who have not encountered a problem: if you have something in the buffer, besides the necessary files, this will kill the upload of files to the server. If someone else from the team joins the server to upload files, you will have problems. In addition, some files may be transferred damaged.
My advice is to choose a CI / CD solution for yourself.
Another important element of the development process is quality control.
This work was with us in that the team members got together and reviewed the work done. And in the code, we sometimes did not even look, so that a huge number of moments passed by the attention. Another problem lay in the fact that we had no experience, and therefore, an understanding of what is good code. We could not immediately isolate the errors in the code that an experienced developer sees immediately.
If the team had a senior developer, he would immediately be able to let us know where the problems are and how to deal with them. But he was not there, we worked independently.
We didn't have them either. We conducted tests on our own. Again without experience. As a result, precious time was wasted, which we spent on catching bugs and eliminating them.
If you want a good code - you need testers, and professional ones. Developers do not always cope with the problem of software testing.
Quality of the code
Many of us at the beginning of the journey are representatives of the “copy-past” culture. This means that the developer is looking for the necessary project solutions on Stackoverflow and inserts the found piece without a twinge of conscience. The result is not very good code, which is practically unreadable and which developers find it difficult to explain completely. Even the person who copied a certain area often cannot understand his work.
I can only advise one thing: if you copy the code, you must fully understand it. Without this, it is impossible to implement a normal project.
Spaghetti Code A
poor understanding of the architecture of the project led to total chaos. Spaghetti code - a soft description of what happened in the end.
Some sites passed through different hands, different developers, each of which added something different. The final code of the project was a set of ideas and crutches.
We did not have a dependency injection system, and we didn’t use any common design patterns. This led to a lot of bad code that just started to "rot."
What can I say? Code readability is just as important as proper operation, and these two things go hand in hand. Clear, consistent style and holistic code provide the most effective result.
Many problems arose due to our lack of experience. We just did not know how to work on the project. We could not properly implement the environment. We did not have the right tools and technology.
A good team leader would solve all these problems. He would have foreseen much in advance.
By the way, the project itself was not the worst of what could have happened. I met many future colleagues with whom I still communicate. Got the necessary experience to work as a pro. And I realized that without a normal leadership, even the most capable team does not fully realize its potential. Never.