background
With the increasing number of business/personnel, the coding review link needs to be picked up again in the team. Therefore, both new and old projects have made a selection of sampling analysis and review (the selection is considered from the plasticity, and the later iterations are considered). Indeed, some problems have been exposed. This article is to share these issues. The language reference is not limited to JavaScript (you can refer to it if there is a commonality).
Here are some general directions
- Engineering architecture/design ideas
- Each coding standard has its own characteristics
- Technology stack problem confusion
Engineering design ideas
After the product architecture design/detail review is completed, that is, before the project engineering starts coding, most of the architecture design phases exist. And often the design phase will invest a long period of time to do this part of the work (architect, or team leader for the overall control).
In other words, inject a design soul into this project and let everyone develop towards a goal together. In terms of follow-up personnel expansion, function expansion, product landing expansion...
However, the reality is often unsatisfactory, and there will always be some unexpected situations during the development of a project:
- Intermittent, intermittent development (half-dead project)
- The tasks of each other are too clear (the modules of each other do not know each other)
- One-sided recognition/no consensus of design ideas in the team
- Non-coding work (e.g. CI/CD)
- Personnel turnover (problems of adjustment of personnel organization structure)
- 。。。
Some personal opinions are also some of the work currently being done:
- Document output is not only necessary. Document output involves the phased end and phased design must be traceable (some people will say that there is no time to write, no need to write... Please believe that my documentation will help you reduce A lot of follow-up work )
- The scale of the project and the scale of the personnel lead to the modularization of division of labor to develop at least understanding of each other's work. Share as often as possible (please remember that you are a team, don’t talk about it every time it is written by someone so and so, I’m not sure... please "roll up")
- The implementation of design ideas to the developers, this part is more of the responsibility of the team leader. Please work hard and share it with each participant (I have always recognized that the leadership is not based on the individual, but on your team. Everyone hehe I am also improving, here is the main me 160f5694d8bdff)
- This part of non-coding work is a bit difficult. How do you say that if the technical team is relatively mature, it will involve the division of work between departments. Let's implement every deployment detail
- If you can refer to the above points for personnel replacement issues.. I believe this will not be so painful
If you have anything to add, please leave a message and I will improve it
2. Coding Standards
Regarding coding standards, relatively large teams will have this environment, which I personally feel is very necessary.
Remember that the code is for people to see. Please give the newcomers a shade of green!
Take JavaScript and briefly give a few examples to illustrate:
1. Avoid abbreviations in variable/constant declarations, please use meaningful names. (Too headache)
2. Scope issues, don't just pollute the global domain. Lets can be used for multiple purposes. Now that there is a ready-made babel, what are you afraid of (and in the IE era)?
Don't change the overall situation, don't change it! What's the point? You will also release it in your function (don't lift the memory or something that is not enough for that qualification..) Refer to the following illustration
3. What does it mean for a function to only do one thing to avoid an effect? The function needs to be pure, and it doesn't say how well you write it. But don’t let a function follow a piece of logic. It’s not easy.. Please keep it single
4. Limiting the number of arguments passed to a function I am curious if so many parameters are really necessary. The readability is very poor. What if you choose less and miss the transmission? If you really need it, you can convert the data type. Isn't it possible to object and array?
5. Use existing APIs to take JavaScript as an example.
Please leave a message if you need to add.
3. Confusion of technology stack issues
The most direct and effective way to solve this problem, coding review is carried out regularly, and it is not very reliable to say that everyone fully trusts the problem.
Simply say a few points:
- It can’t be called review, it should be shared (everyone takes the initiative to share coding, so it’s a loss)
- Take the simplest example, in small libraries/framework/tool components, you also need to come up with reasons why you need to use the necessary processes. Otherwise, it would be annoying for everyone to introduce a bunch of things in.
- There is a boss who is recognized as a convincing team technical leader to take the lead in advancing this issue (very important, very important)
Please leave a message if you need to add.
At last
This article is written by daily income. If you like this type of article, please pay attention to my column coding Daily
It is best to sincerely hope that everyone will take care of the small family (team) and create a myth!
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。