As the business/staff grows, the Coding Review section needs to be revived within the team. Therefore, a selection sample analysis was conducted for both new and old projects (in terms of selection, plasticity and post-iteration were considered). There are some problems that have really come to light. This article aims to share these issues, and the language reference is not limited to JavaScript(if there is a common denominator).

Here are some general directions

  1. Engineering architecture/design ideas
  2. Coding specifications have their own characteristics
  3. The technology stack is a mess

Engineering design idea

After the product architecture design/detail review is completed, that is, before the coding of the project begins, most of the time there is an architecture design phase. Often, the design phase is devoted to this part of the work over a long period of time (the architect, or the team leader, has overall control).

In other words, inject a design soul into the project and let everyone develop towards a common goal. Follow-up personnel expansion, function expansion, product implementation expansion…

However, the reality is often unsatisfactory. There will always be some unexpected situations during the development of a project:

  1. Periodical interruptions, intermittent development (half-dead project)
  2. Too clear a task for each other (each module doesn’t know each other)
  3. Partial understanding/no consensus of design ideas within the team
  4. Non-coding work (e.g. CI/CD)
  5. Staff turnover (staffing structure adjustment problem)
  6. .

Some personal opinions, but also some of the current work:

  • Documentation output, not only necessary Documentation output involves the end of a phase and the design of a phase has to be traceable (some people would say no time to write, no need to write… Please trust me that the documentation will help you reduce a lot of follow-up work.)
  • The scale of the project, the size of the people leads to a modular division of labor to develop each other’s work at least to understand. Share it as regularly as possible (remember you are a team and don’t pull it every time. It was written by so-and-so. Please roll it up.)
  • The implementation of design ideas to the developers is more the responsibility of the team leader. Please share with everyone (I always agree that the strength of a leader is not determined by an individual, but by everyone in your teamHee hee I am also in the improvement here is the main warning me)
  • The non-coding part of the work is a little bit more difficult how to say if the technical team is relatively mature then it involves the division of work between departments. Put in place every deployment detail
  • Personnel turnover, if you can refer to the above points… Trust this to be less painful

If you have hope to add, please leave a message and I will improve it

2. Coding specification

Coding specification issues, the larger the team will have this environment that I personally feel is very necessary.

Remember that the code is for people to see. Please give the future a green shade!

Here are a few simple examples of JavaScript:

1. Avoid shorthand for variable/constant declarations. Use meaningful names. (It’s a headache.)

Let can be used more often. There is already a Babel out there. What are you afraid of (besides in the IE era)?

Don’t change the whole situation. Don’t change it! What’s the significance? You will also release it in the function (don’t raise the memory and what is not enough for that qualification…). Refer to the following diagram

3. What is the meaning of a function that does one thing to avoid effect? The function has to be pure, and it doesn’t say how elaborate you write it. But do not want a function to follow a logic rigidly set up type of this is not idle.. Please make sure it’s simple

Limit the number of arguments a function passes to a function. I wonder if that many arguments are really necessary. Readability is poor. What if there are fewer selections and missed passes? You can convert data types if you really need to. What about object and array

5. Use off-the-shelf APIs. Take JavaScript for example.

Please leave a message if you need to add.

3. The technology stack is a mess

The most direct and effective way to solve this problem is to implement the coding review regularly. It is not reasonable to say that everyone trusts the problem fully.

A few brief points:

  1. “Review” should be “shared”, not “shared”.
  2. At the simplest level, small libraries/frameworks/tool components also need to come up with reasons why they should be used in the proper process. How annoying would it be for everyone to introduce a bunch of stuff.
  3. Having a trusted leader who is recognized by the technical leader of the team to drive this issue forward (very important)

Please leave a message if you need to add.

The last

This article is written on a daily basis. If you like this type of article, please pay attention to my column Coding Daily

Best sincerely hope that we care for the small family (TEAM) public to create a myth!