Get best of the week

Cómo no omitir código no válido en el repositorio

Por qué es necesario


Cuando más de una persona trabaja en su equipo, de una forma u otra, todos enfrentan el problema de los diferentes estilos de codificación para cada miembro del equipo. Alguien escribe corchetes para bloques if...else, alguien no. Cuando un proyecto se hace más grande, es más difícil leer dicho código y aún más difícil realizar una revisión del código.


Para que la revisión del código y otras reuniones del equipo no se conviertan en una discusión de tabulación vs espacios con tonos elevados, es mejor configurar el repositorio para que el proyecto en sí no permita escribir código que no sea válido y no sea estándar para el equipo.


Por un lado, el uso de diferentes estilos de codificación puede parecer de buen gusto, indigno de atención. Bueno, June no ajusta una sola línea de código después de la condición if, pero alguien escribe, ¿y qué? Si deja el código debajo del bolígrafo de junio "tal cual", puede convertirse en una "bomba de tiempo": esa línea de código ifse puede eliminar después de eso, y luego la siguiente línea caerá bajo la condición. Por supuesto, esta situación generalmente se detecta en una revisión de código, pero sucede que este error potencial pasa la prueba, y aquí hay dos razones principales:


  1. Todos somos personas, y las personas están equivocadas.
  2. Las personas son sociales, lo que significa que no querrán entrar en un "conflicto" con los estilos. Y aquí hay dos opciones posibles:
    • "Mejor arreglarlo yo mismo", piensa el revisor, y corrige el código.
    • El inspector se desmorona en junio y expresa sus dudas sobre su adecuación y la necesidad de la existencia.

¿Cómo podemos asegurarnos de que todos escriban de acuerdo con el estilo del equipo? Golpear las manos en una revisión de código cada vez desmotiva tanto al autor del código como al propio inspector. Afortunadamente, este problema excita las mentes de más de un programador durante más de un año, y ahora tenemos muchas herramientas a nuestra disposición.


El propósito de este artículo es contarles a otros y a mí mismo sobre el futuro de cómo configuro el repositorio del proyecto de tal manera que se proteja del código no válido en términos de los estándares del equipo.


Que tenemos


Como ejemplo, tome un proyecto de demostración cuyo código se publicará en GitHub. Como estoy desarrollando en .NET Core, el proyecto se escribirá en él. Lo que usaré:


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

: , , "".



Después de seguir los pasos descritos en el artículo, obtengo un proyecto que "se protege" del código no válido. Está claro que no puede salvar el producto de errores con una sola sintaxis y guía de estilo, pero incluso estas cosas menores ayudan a lograr una mejor calidad de código y le permiten discutir soluciones arquitectónicas para revisiones de código en lugar de problemas de formato.

More articles:


All Articles