Pourquoi est-ce nécessaire

Lorsque plusieurs personnes travaillent dans votre équipe, d'une manière ou d'une autre, tout le monde est confronté au problème des styles de codage différents pour chaque membre de l'équipe. Quelqu'un écrit des parenthèses pour les blocs if...else, quelqu'un non. Lorsqu'un projet devient plus grand, il est plus difficile de lire un tel code et encore plus difficile de procéder à une révision du code.

Afin que la révision du code et les autres réunions d'équipe ne se transforment pas en une discussion entre tabulation et espaces avec des tons élevés, il est préférable de configurer le référentiel de sorte que le projet lui-même ne permette pas d'écrire du code non valide et non standard pour l'équipe.

D'une part, l'utilisation de différents styles de codage peut sembler de bon goût, indigne d'attention. Eh bien, June n'encapsule pas une seule ligne de code après la condition if, mais quelqu'un écrit, alors quoi? Si vous laissez le code sous le stylo de juin «tel quel», cela peut devenir une «bombe à retardement»: cette ligne de code ifpeut être supprimée après cela, puis la ligne suivante tombera sous la condition. Bien sûr, cette situation est généralement détectée dans une révision de code, mais il arrive que ce bogue potentiel réussisse le test, et voici deux raisons principales:

1. Nous sommes tous des gens et les gens ont tort.
2. Les gens sont sociaux, ce qui signifie qu’ils ne voudront pas entrer en «conflit» avec les styles. Et ici, deux options sont possibles:
   
   • «Mieux vaut le réparer moi-même», pense le critique et corrige le code.
   • L'inspecteur tombe en panne le juin et exprime ses doutes quant à son adéquation et à la nécessité de l'existence.

Comment pouvons-nous nous assurer que tout le monde écrit conformément au style d'équipe? Frapper les mains sur une révision du code à chaque fois démotive à la fois l'auteur du code et l'inspecteur lui-même. Heureusement, ce problème excite l'esprit de plus d'un programmeur depuis plus d'un an, et maintenant nous avons de nombreux outils à notre disposition.

Le but de cet article est de parler aux autres et à moi-même de l'avenir de la façon dont je configure le référentiel de projet de manière à ce qu'il se protège contre le code non valide en termes de normes d'équipe.

Ce que nous avons

Par exemple, prenez un projet de démonstration dont le code sera publié sur GitHub. Puisque je développe sur .NET Core, le projet y sera écrit. Ce que j'utiliserai:

• .NET Core 3.1
• Angulaire 8+
• Compte Github
• Travis ci

Travis-CI. , .

— , master branch.

" " Gitlab Azure DevOps, Github — Travis CI.

. . , , :

• . develop master , (maintainer).
• . CICD , .
• Repository is a king. gitflow, .
• Fail fast. , .
• Git pre-commits hoocks. CI , - .

? -, master develop . , , , "" . " ". , .

solution- (*.sln) , - .NET . , , nuget- .

stylecop .NET Core. , solution- ( gist.github.com):

1. Directory.build.props — .
2. standard.ruleset — .
3. stylecop.json — .

, .

- . : - , . . :

#  
ng lint

#    ,    html-
ng build --prod

#  
ng test

. , (Chrome / Chromium), CI-. , npm- puppeteer , .

, , :

1. "test-headless-ci-only": "ng test --browsers ChromiumNoSandbox" scripts packages.json:

"scripts": {
    "ng": "ng",
    "start": "ng serve -o",
    "build": "ng build",
    "build-stage": "ng build --configuration=staging",
    "build-prod": "ng build --prod",
    "test": "ng test",
    "test-headless-ci-only": "ng test --browsers ChromiumNoSandbox",
    "lint": "ng lint",
    "e2e": "ng e2e"
  },

1. npm install puppeteer karma.conf.js :

const process = require("process");
process.env.CHROME_BIN = require("puppeteer").executablePath();

module.exports = function(config) {
  ...
};

1. karma.conf.js customLaunchers:

config.set({
....,
customLaunchers: {
      ChromiumNoSandbox: {
        base: "ChromeHeadless",
        flags: [
          "--no-sandbox",
          "--headless",
          "--disable-gpu",
          "--disable-translate",
          "--disable-extensions"
        ]
      }
    },
    singleRun: true
});

npm run est-headless-ci-only.

- , . prettierrc, . . prettierrc , :

1. prettier pretty-quick :

npm install -g prettier
npm install -g pretty-quick

1. .prettierrc -:

{
    "useTabs": false,
    "printWidth": 120,
    "tabWidth": 2,
    "singleQuote": true,
    "trailingComma": "none",
    "semi": true
}

1. prettier- .prettierignore -:

package.json
package-lock.json
tslint.json
tsconfig.json
browserslist
.gitkeep
favicon.ico
tsconfig.lib.json
tsconfig.app.json
tsconfig.spec.json
karma.conf.js
protractor.conf.js
ng-package.json
*.html

" " pretty-quick --staged.

-

CI/CD — , . , . . , -, .

husky. , :

1. husky

npm install -g husky

1. husk package.json :

"devDependencies": {
  ...
},
"husky": {
    "hooks": {
      "pre-commit": "pretty-quick --staged",
      "pre-push": "ng lint && ng test --browsers ChromiumNoSandbox"
    }
  }

: , , "".

Une fois les étapes décrites dans l'article effectuées, j'obtiens un projet qui «se protège» contre le code non valide. Il est clair que vous ne pouvez pas sauver le produit des bogues avec un seul guide de syntaxe et de style, mais même ces petites choses aident à obtenir une meilleure qualité de code et vous permettent de discuter des solutions architecturales pour les révisions de code plutôt que des problèmes de formatage.