For large or super large companies, the introduction and implementation of specifications are usually completed by the corresponding self-developed Cli tools.

Specification introduction

eslint rule check prompt

Usually, the project will introduce eslint to check the code, hoping to unify the code style.

Rules are used to define all rules by themselves, but they usually use the industry's popular specifications, which can be introduced using the extensions configuration.

"extends": [ // The default configuration is recommended
  "eslint:recommended",
  "plugin:react/recommended",
  'plugin:@typescript-eslint/recommended',
  "plugin:import/typescript",
  "plugin:prettier/recommended"
],

The check requirements in a specific scenario can be checked using the plugin

"plugins": [
  "@typescript-eslint",
  "react",
  "prettier"
],

prettier code formatting

We have introduced the prettier plug-in in eslint configuration, and we need to configure it prettierrc

module.exports = {
  "printWidth": 100, // The specified code length exceeds the newline
  "tabWidth": 2, // Width of tab key
  "useTabs": false, // Do not use tab
  "semi": false, // Add a semicolon at the end
  "singleQuote": true, // single quotes 
...
}

Therefore, according to the eslint rule and prettier rule we configured

typescript introduction

As a necessary js enhancement language for multi person collaboration, the role of ts is basically irreplaceable, and the advantages of ts will not be repeated.

To use tsx of TS or react, first configure tsconfig JSON tells the compiler the rules for converting ts to js.

{
  "compilerOptions": {
    "target": "es5",
    "module": "esnext",
    "moduleResolution": "node",
    "allowJs": true,
    "lib": ["DOM", "ES5", "ES6", "ES7", "ESNext"],
    "jsx": "react",
    "sourceMap": false,
    "strict": true,
    "noImplicitAny": true,
    "baseUrl": "./",
    "paths": {
      "@/*": ["src/*"]
    },
    "allowSyntheticDefaultImports": true,
    "esModuleInterop": true,
    "experimentalDecorators": true,
    "forceConsistentCasingInFileNames": true,
    "skipLibCheck": true
  },
  "exclude": [
    "node_modules",
  ],
  "include": [
    "src",
    "typings/**/*"
  ]
}

Next, configure babel and use the preset babel plug-in to be responsible for the transformation

 "presets": [
    "@babel/preset-typescript", //It's actually @ Babel / plugin transform typescript
    ...
  ],

Finally, the webpack configuration uses the loader to process jsx|tsx files.

rules: [
  {
    test: /\.(jsx?|tsx?)$/,
    exclude: /(node_modules)/,
    use: [
      {
        loader: "babel-loader",
        options: {
          cacheDirectory: true
        }
      }
    ]
  },
]

development process

IDE plug-ins and configuration

During the development process, the code is usually formatted habitually. You can install the vscode plug-in of prettier. After the plug-in is installed, it needs to be configured uniformly Vscode settings JSON to use the prettier specification specified by the project instead of other formatting tools.

settings.json to configure

Automatic generation of ts definition file

The company level should standardize the back-end services and introduce swagger. The mainstream back-end application frameworks and languages have swagger interfaces or meet the openAPI standard. On this basis, dtsgenerator can automatically generate the d.ts definition file of full API interface according to the back-end interface standard.

With the full API interface d.ts definition file, business development only needs to write a small number of interfaces, which can meet the full TS type coverage. The corresponding noAny requirements can be applied.

Compile build

The configuration file of the eslint rule has been configured previously. In the construction phase, you only need to run the eslint command for code specification check and automatic formatting.

//webpack instruction configuration
{
  test: /\.(jsx?|tsx?)$/,
  use: [
    loader: "eslint-loader",
    options: {
      fix: true
    }
  ]
}

With the help of the eslint loader of webpack, automatic formatting is enabled during build, usually local debugging.

Submit for inspection

Add hook to check and repair the code when git is submitted

"pre-commit": [	"eslint src --fix --quiet --ext .ts,.tsx",],

Or use husky

"husky": {  "hooks": {  	"pre-commit": "eslint src --fix --quiet --ext .ts,.tsx"  }}

Of course, generally speaking, when submitting code, you do not need to check and repair all the code, but only need to process the files in the staging area, so lint staged is generally used for processing.

"husky": {  "hooks": {  	"pre-commit": "lint-staged"  }},"lint-staged": {  "src/**": [    "prettier --config .prettierrc --write",    "eslint --fix",    "git add"  ]}

Code scanning

As a static code checking tool, sonar can scan code from seven aspects to manage code quality.

Starting from the development side, the main concerns are: annotation rate and repeated code

Complexity analysis and code structure and design scanning are different

Code rule checking has been standardized in the previous stages, so don't pay much attention at this stage

Potential bug s and unit test coverage belong to quality control and are not within the scope of code specification and development.

Code review

What does code review mainly review?

This problem is encountered by many teams. Most teams do not have a clear standard for how to do code review. It is usually a mere formality or used to antagonize people. Over time, there will be no code review.

To clarify what to review, you need to know the purpose of code review first. Personally, I think the primary purpose of code review is maintainability. Therefore, we can start from two aspects:

• Code style

  This is solidified by the previous specification, so that the code style of the whole team tends to be unified.

• code readability

  Combined with sonar's scanning results, review the annotation rate and duplicate code during code Review. At the same time, the code structure and design can be reviewed in the core module or reuse module, usually by technical leader s or experienced senior engineers.

Another point is code efficiency, but execution efficiency is usually not a big problem in the ToB business scenario. It can only be analyzed and reviewed by the team in case of serious problems.