Get best of the week

Como não pular código inválido no repositório

Por que isso é necessário?


Quando mais de uma pessoa trabalha em sua equipe, de uma forma ou de outra, todos enfrentam o problema de diferentes estilos de codificação para cada membro da equipe. Alguém escreve colchetes para blocos if...else, alguém não. Quando um projeto se torna maior, é mais difícil ler esse código e ainda mais difícil realizar uma revisão de código.


Para que a revisão de código e outras reuniões da equipe não se transformem em uma discussão de espaços de tabulação com tons elevados, é melhor configurar o repositório para que o projeto em si não permita escrever código inválido e não padrão para a equipe.


Por um lado, o uso de diferentes estilos de codificação pode parecer agradável, indigno de atenção. Bem, June não quebra uma única linha de código após a condição if, mas alguém escreve, e daí? Se você deixar o código sob a caneta de junho "como está", ele poderá se tornar uma "bomba-relógio": essa linha de código ifpoderá ser excluída depois disso e a próxima linha ficará sob a condição. Obviamente, essa situação geralmente é detectada em uma revisão de código, mas acontece que esse bug em potencial passa no teste, e aqui estão duas razões principais:


  1. Somos todos pessoas, e as pessoas estão erradas.
  2. As pessoas são sociais, o que significa que não desejam entrar em um "conflito" com os estilos. E aqui duas opções são possíveis:
    • “Melhor consertar eu mesmo”, pensa o revisor e corrige o código.
    • O inspetor interrompe em junho e expressa suas dúvidas sobre sua adequação e a necessidade de existência.

Como podemos garantir que todos escrevam de acordo com o estilo da equipe? Apertar as mãos em uma revisão de código sempre que desmotiva o autor do código e o próprio inspetor. Felizmente, esse problema excita as mentes de mais de um programador por mais de um ano e agora temos muitas ferramentas à nossa disposição.


O objetivo deste artigo é falar a outras pessoas e a mim mesmo sobre o futuro de como configuro o repositório do projeto para que ele possa se proteger de códigos inválidos em termos de padrões de equipe.


O que nós temos


Como exemplo, considere um projeto de demonstração cujo código será publicado no GitHub. Desde que estou desenvolvendo no .NET Core, o projeto será escrito nele. O que vou usar:


  • .NET Core 3.1
  • Angular 8+
  • Conta do 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"
    }
  }

: , , "".



Após as etapas descritas no artigo, recebo um projeto que "se protege" de código inválido. É claro que você não pode salvar o produto de bugs com uma única sintaxe e guia de estilo, mas mesmo essas pequenas coisas ajudam a obter melhor qualidade de código e permitem discutir soluções de arquitetura para revisões de código em vez de problemas de formatação.

More articles:


All Articles