Warum ist es notwendig?

Wenn mehr als eine Person in Ihrem Team auf die eine oder andere Weise arbeitet, ist jeder mit dem Problem unterschiedlicher Codierungsstile für jedes Teammitglied konfrontiert. Jemand schreibt Klammern für Blöcke if...else, jemand nicht. Wenn ein Projekt größer wird, ist es schwieriger, einen solchen Code zu lesen, und noch schwieriger, eine Codeüberprüfung durchzuführen.

Damit die Codeüberprüfung und andere Teambesprechungen nicht zu einer Diskussion zwischen Tabulatoren und Leerzeichen mit erhöhten Tönen führen, ist es besser, das Repository so zu konfigurieren, dass das Projekt selbst das Schreiben von Code nicht zulässt, der für das Team ungültig und nicht standardisiert ist.

Einerseits scheint die Verwendung verschiedener Codierungsstile geschmackvoll und unwürdig zu sein. Nun, June schließt keine einzige Codezeile nach der Bedingung ein if, aber jemand schreibt, na und? Wenn Sie den Code unter dem Juni-Stift "wie er ist" belassen, kann dies zu einer "Zeitbombe" werden: Diese Codezeile ifkann danach gelöscht werden, und die nächste Zeile fällt unter die Bedingung. Natürlich wird diese Situation normalerweise in einer Codeüberprüfung erfasst, aber es kommt vor, dass dieser potenzielle Fehler den Test besteht, und hier sind zwei Hauptgründe:

1. Wir sind alle Menschen und die Menschen liegen falsch.
2. Menschen sind sozial, was bedeutet, dass sie nicht in einen „Konflikt“ mit den Stilen geraten wollen. Und hier sind zwei Möglichkeiten möglich:
   
   • "Repariere es besser selbst", denkt der Rezensent und korrigiert den Code.
   • Der Inspektor bricht am Juni zusammen und äußert seine Zweifel an seiner Angemessenheit und der Notwendigkeit der Existenz.

Wie können wir sicherstellen, dass jeder im Einklang mit dem Teamstil schreibt? Jedes Mal, wenn eine Codeüberprüfung durchgeführt wird, werden sowohl der Autor des Codes als auch der Inspektor selbst demotiviert. Glücklicherweise erregt dieses Problem die Köpfe von mehr als einem Programmierer seit mehr als einem Jahr, und jetzt verfügen wir über viele Tools.

Der Zweck dieses Artikels ist es, anderen und mir von der Zukunft zu erzählen, wie ich das Projekt-Repository so konfiguriere, dass es sich in Bezug auf Teamstandards vor ungültigem Code schützt.

Was wir haben

Nehmen Sie als Beispiel ein Demo-Projekt, dessen Code auf GitHub veröffentlicht wird. Da ich auf .NET Core entwickle, wird das Projekt darauf geschrieben. Was ich verwenden werde:

• .NET Core 3.1
• Winkel 8+
• Github-Konto
• 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"
    }
  }

: , , "".

Nachdem die im Artikel beschriebenen Schritte ausgeführt wurden, erhalte ich ein Projekt, das sich vor ungültigem Code "selbst schützt". Es ist klar, dass Sie das Produkt nicht mit einer einzigen Syntax und einem einzigen Styleguide vor Fehlern schützen können, aber selbst diese kleinen Dinge tragen zu einer besseren Codequalität bei und ermöglichen es Ihnen, Architekturlösungen für Codeüberprüfungen zu diskutieren, anstatt Probleme mit der Formatierung zu lösen.