A little idea about team development

Recently, I finally learned a little bit about team development. However, I think our team is not doing well in development, so I want to talk about the feelings of these days here so that I can remember clearly, in future work, we can also make up for the current shortcomings.
It is really not easy to develop a team. A large project must be completed by a team. In this process, there will be many and many problems, because developers are all people, it is impossible to execute like a machine Program Same, as long as there is a fixed Code , There will be no issues other than code, not to mention a group of people rather than a person. So if you want a group of people to perform their own activities according to the established rules, you need to have a set of reasonable rules and methods. These methods are software engineering, but I will not talk about the big boxes, I don't have much experience now. I just want to talk about my current experience in software engineering.
First of all, I want to emphasize the importance of documents. In terms of the development process, there should be three documents: Requirement documents, design documents, and database design instructions documents, then, the content and meaning of the design document are communicated to every developer. All developers should review the document. The review process is also a process of close thinking. The transfer of design ideas is here. After the overall framework design is complete, we need to design it in detail in different parts. At this time, there is another key point that the Framework Design personnel should clearly define the functions and interfaces to be completed for each module, in this way, the modules can be well combined. During the detailed design, the functions to be completed by each module should be detailed to each method, especially the public method. Each parameter and return value should be described in detail, in this way, there will be evidence for later calls.
After all the designs and reviews are completed, we can start the overall encoding. I think the encoding effect is the best at this time. Because the code is coded before the detailed design, many times it will be changed later due to inadequate design. I believe that programmers are the most disgusted with program change, especially those of others, what is even more intolerable is to change the procedures that do not have a good structure or design documents. Therefore, it is recommended that you do not start writing a large number of programs before completing the design. if you write a program, you should also have relevant documents.
In addition, documents of some intermediate products should be written as detailed as possible, because intermediate products are mutually called by modules, therefore, if you do not write a detailed document, the call between two modules may fail.
There is also the issue of coding standards, which is actually a good solution, but what is not easy to solve is that everyone may have their own coding standards, however, it is not easy to implement a unified coding standard for a team.
I want to talk about new people. If a new person joins a team, you don't have to rush to make money for the company. The first thing you should do is to integrate him into the company environment, more importantly, let him be a person in the team that complies with the unified standards. When he is fully integrated, he can play a greater role in the team.
This is just a little bit of a small idea. It's easy to talk about teamwork, but it can also be done well.