Small companies - small front-end teams, how to mature step by step?

status quo

In the second half of last year, I joined a small company. The front-end team has just been established. Although I have already preset various problems in the team in advance, after entering, I still found a series of obvious problems. Here Here are some typical questions:

  • There is no separation of front-end and back-end codes, and there is no separation of publishing and launching
  • The front-end technology stack is single, and all projects directly use vue3-vben-admin
  • Code specifications, commit specifications, etc. are not unified, and the CI/CD process is not standardized.
  • There is no design, product, etc., resulting in an irregular overall development process.
  • ...other

The reason why the above problems are listed is not any dissatisfaction with our company, hahaha, more is to hope to give some solutions or directions to friends who encounter similar problems, and at the same time, it can also help everyone's front-end The team is gradually becoming standardized and mature.

What does a mature front-end team look like?

The front-end team has just been established, how to move towards standardization and maturity step by step? Obviously, we need to know what a mature front-end team looks like (of course, this kind of topic is generally discussed, and it is very likely to be sprayed), actually? There is no clear standard, and the company's business is different, the front-end technology stack, infrastructure, etc. will be different, here are some common directions for building front-end teams for your reference:

front-end specification

Here, some common specifications are summarized, directly above:

If these specifications are not unified in your team, you can refer to the above directions to promote them in the team.

Front-end project template

Everyone must know the official scaffolding tools of vue and react: vue-cli, create-react-app, through these basic scaffolding, we can help us create the most basic front-end project code, but with the iteration of business, each company has different business scenarios and different technology stacks, often Based on the created project template, it is necessary to gradually precipitate the custom project template code in line with the company. For details, please refer to the following vue-clifigure :create-react-app

Front-end scaffolding

Above, we talked about the front-end project template, so how to better manage the template? The answer is scaffolding. If there is no scaffolding, we may directly put the template code in a separate warehouse. Every time we open a new project, we clone it locally and then copy it out. Although this is also possible, but Scaffolding can help us manage project templates better and faster through commands, and perform project initialization and other operations.

Of course, the technology stack of scaffolding is different from the technology stack of traditional front-end projects. It is also mentioned in the above figure that the underlying dependencies, ,, Nodeetc. Lerna, Yargscan learn some if you are interested. Whether you want to maintain the company's own scaffolding, you need to evaluate the manpower Costs, benefits, etc. are considered in combination with the actual situation of the team.

Front-end automated build deployment (CI/CD)

This part is the CI/CD that everyone often says, that is, how to continuously integrate and deploy front-end projects, so I won’t expand on it here. For details, you can refer to an article written by myself: Building front-end CI based on Docker + Nginx + Gitlab- runner /CD

Let me explain a little bit: In the early days, front-end partners with little work experience may encounter this situation. Every time a project is released and launched, they may directly use the company's ready-made publishing system, and click directly on the page to succeed. But often when encountering a problem, I don’t know how to troubleshoot the problem, and I have to ask related students such as operation and maintenance. When I meet a colleague who communicates well, I may help you solve it. There will be 10,000...

Therefore, with the continuous development of the front-end, the requirements for the front-end will become higher and higher. It is also necessary for us to know how to perform CI/CD at the bottom of the front-end project, and how to release it online. This will involve , , Docker, K8sand Nginxother CI工具technologies Stack, interested students can also write some demos to understand.

Front-end full-link monitoring system

In fact, with the iteration of the project, the functions become more and more complex, especially for some C-end projects, we need to grasp the user's behavior, so that we can further iterate our project better according to the user's behavior, then, this is We need to monitor these behaviors, which is what everyone often calls buried points,

A complete monitoring system usually includes the following contents:

If some small partners in the team have such a need, then they have to consider how to do it. There are also some open source solutions on the market for reference, for example: , of course, it is also necessary to combine the actual situation of the team to see if you need to do it Sentryyourself To implement a complete monitoring system, because the implementation cost is not low, especially for small companies, we need to conduct research and research to see if some open source solutions can be used to implement it.

Front-end material library

What is front-end material? In fact, it is the reusable code such as the component library and tool library that everyone often says. For details, please refer to the following figure:

Generally, large factories will have similar material platforms, so what about our small company? It is necessary to consider the cost and benefits of its realization, and it is not necessary to establish a material platform, because small companies will not have so many materials that can be deposited. For example: generally there are some component libraries and tool libraries that are deposited, and we can also publish them to npm, so that the team can also use it internally.

How to do it?

How to do it? Mainly consider the following aspects:

  1. Clarify the problems to be solved: Combined with the current situation of the company team, clarify the existing problems according to the priority
  2. Clarify the specific implementation plan of the problem to be solved: clarify the pros and cons of each plan through research, team discussion, etc., and choose the optimal plan
  3. Clarify the specific implementation steps: starting from the actual situation of the team, it is best to start gradually, and do incremental infrastructure work without affecting the existing business

Therefore, based on our company's situation, I have clarified that the following points should be prioritized:

  • Determine the front-end technology stack
  • Clarify the front-end specification
  • Separation of front-end and back-end codes to create an independent front-end CI/CD

Determine the front-end technology stack

Since our company currently has mostly middle- and back-end projects, the technology stack confirmed here is also mainly based on this direction.

First of all, the front end of traditional middle and back-end projects generally includes the following contents:

How to achieve the above content? Can be developed in three directions:

  • Manually encapsulated by your own team to form a set of best practices for the team (in fact, it is to gradually precipitate a set of project templates for initializing projects in combination with the company's business scenarios)

  • With the help of community open source solutions: Recommended here: Ant open source UmiJS

    To put it simply, the framework integrates common content of traditional mid-background solutions in the form of plug-ins, such as common routing management, permission management, etc. We only need to introduce the corresponding plug-ins.

  • Using ready-made out-of-the-box front-end solution frameworks, the following frameworks are recommended here:

How did our company choose? Historical projects use part of Vue3 Vben Admin , and new projects use Ant Design Pro uniformly .

Here is a comparison Vue-vben-adminwith Ant design pro:

  • Vue3 In V Admin

    • Advantage

      • Currently using the technology stack, and using it for two to three years, I have accumulated a certain amount of experience and waded through some pitfalls.
      • The overall functions are relatively complete and do not need to be developed from scratch.
    • disadvantage

      • The iterative update mechanism of the local version is not very friendly. Developers need to manually clone the latest version of the template warehouse each time, and then copy the original business code, and if there is an update to the source code, it will be more troublesome, for example: a component , we may have made a second modification in the project, and then, when we update the vben version, the author may also update the code of the component. At this time, it is necessary to compare the old and new component codes, which is prone to problems.
        • Bottom-level reason 1: The overall project architecture is relatively simple, and the monorepo architecture is not adopted. The hooks and components encapsulated in the template project code are not separately distributed as npm packages, and there is no version management.
        • The second underlying reason: encapsulated components have limited ability to customize render, and we need to manually modify the component source code.
    • Part of the source code has deep nesting levels, and the cost for beginners is high. With the iteration of business, source code and business code are easy to confuse, making it difficult to upgrade later versions.

    • At present, the rendering of the first screen of our project is too slow (it may become a more obvious problem in the later stage)

  • Ant Design Pro

    • Advantage
      • The overall community ecology is more complete. Based on umi + ant-design pro component, the secondary packaged components and other content have version management. As an open source project, it is more convenient for developers to import on demand through npm packages. At the same time, it provides a few Custom entrance can help us in secondary development.
    • disadvantage
      • The new technology stack requires some learning costs in the initial stage, and some pitfalls are required.

After comprehensive consideration of several points, the team plans React + Umijs + And-design-proto the core technology stack of current complex projects. At the same time, for some simple projects, we can also directly creat-react-appuse scaffolding to initialize the project WordPress. More) This can save front-end development costs.

If you have experience with the above technology stacks, especially React + Umijs + And-design-pro, you are welcome to share them in the comment area to see if there are any problems or pitfalls that can be avoided.

Clarify the front-end specification

After confirming the technology stack, the next step is to clarify the front-end specifications, ensure the unity of team development, and post the previously summarized diagram again:

Here, some of the key points are explained again:

  • Coding specifications : In addition to confirming the specification standards, tools are also needed in the project: Eslint + Prettier + Stylelintit is necessary to ensure that these tools are introduced in the project and effective detection is carried out.
  • Git specification : Two common points are: Commit Message 规范and Branch命名规范, these can also husky + lingstagedbe constrained with the help of tools:.
  • UI specification : For some mid- and back-end projects, there may be no special design participation. At this time, the front-end needs to have a better understanding and grasp of the design interaction of the entire page. It is recommended that you refer to: Ant Design design specification, which lists common The interaction specification of the page scene can help us better improve the user experience of the project.

Separation of front-end and back-end codes to create an independent front-end CI/CD

The part of CI/CD usually requires an understanding and grasp of the front-end as a whole, which can help us understand the internal implementation process of the front-end project during the entire integration and deployment process, and can also help us locate and solve problems faster.

There is no extra expansion here. Students with similar needs can refer to my previous summary: # Build front-end CI/CD based on Docker + Nginx + Gitlab-runner

document construction

Documentation construction is actually an essential link, including the front-end specifications and projects we mentioned above, which can be gradually deposited into our team's documents. With the accumulation of content, the deposited documents will also become An indispensable asset to the team.

If you want to promote the team to build documents, you can start from the following aspects:

  • Newcomer registration (VPN configuration, project start)
  • Specification class
    • Process specification: git branch, commit specification
    • Coding standards: eslint, file name, code complexity
  • Item class
    • requirements document
    • R & D program
    • project summary
  • Technology category
    • Common Technology Sharing
    • Summary of typical technical points in the project

at last

Although the above content is relatively basic and simple, it is actually essential for the front-end team. I believe that after completing the above, our front-end team will become more standardized and professional. Of course, it is far from a mature front-end team. As far as the front-end team is concerned, our front-end team has just started. At the same time, different teams and different businesses will also have different infrastructure work. This document will also be gradually updated along with the growth of our front-end team. I believe It will get better and better, the front end is not easy, especially in the past two years, the front end is dead, layoffs, salary cuts and other negative news are constantly impacting every programmer. I believe everyone can get through it. I wish everyone better and better.

reference documents

Author: Silent Expresser
Link: https://juejin.cn/post/7221359467618517052
Source: Rare Earth Nuggets
The copyright belongs to the author. For commercial reprint, please contact the author for authorization, for non-commercial reprint, please indicate the source.

Guess you like

Origin blog.csdn.net/sinat_17775997/article/details/130130711