为什么有必要

当团队中有多个人以一种方式或另一种方式工作时，每个人都会面临每个团队成员编码风格不同的问题。有人为块写括号if...else，有人没有。当项目变大时，阅读这样的代码变得更加困难，甚至进行代码审查也变得更加困难。

为了使代码审查和其他团队会议不会变成讨论色调高的制表符和空格的讨论，最好设置存储库，以使项目本身不允许编写对团队无效和非标准的代码。

一方面，使用不同的编码样式似乎很有品味，不值得关注。好吧，June不会在条件之后换行if，而是有人写，所以呢？如果您按原样在6月笔下保留代码，则它可能会变成“定时炸弹”：此后if可以删除该行代码，然后下一行将处于这种情况。当然，这种情况通常会在代码审查中遇到，但是碰巧这个潜在的错误通过了测试，这有两个主要原因：

我们都是人，人是错的。
人们是社交的，这意味着他们不想与风格发生“冲突”。这里有两个选项：
- 审阅者认为，“最好自己修复它”，并更正代码。
- 检查员在六月休息，并对六月的适当性和存在的必要性表示怀疑。

我们如何确保每个人都按照团队作风写作？每次动手编写代码，都会使代码的作者和检查员本人都感到沮丧。幸运的是，这个问题使一位以上的程序员兴奋了一年多，现在我们可以使用许多工具。

本文的目的是向其他人和我自己介绍我如何配置项目存储库的未来，这种方式可以根据团队标准保护自己免受无效代码的侵害。

我们有什么

以一个示例项目为例，其代码将发布在GitHub上。由于我在.NET Core上进行开发，因此将在上面编写该项目。我将使用：

.NET Core 3.1
角度8+
Github帐号
特拉维斯

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):

Directory.build.props — .
standard.ruleset — .
stylecop.json — .

, .

- . : - , . . :

#  
ng lint

#    ,    html-
ng build --prod

#  
ng test

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

, , :

"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"
  },

npm install puppeteer karma.conf.js :

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

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

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 , :

prettier pretty-quick :

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

.prettierrc -:

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

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. , :

husky

npm install -g husky

husk package.json :

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

: , , "".

在执行了本文中描述的步骤之后，我得到了一个“保护自己”免受无效代码的项目。显然，您无法通过单一的语法和样式指南来保存产品的错误信息，但是即使这些次要的事情也有助于实现更好的代码质量，并允许您讨论用于代码审查的体系结构解决方案，而不是格式化问题。

如何不跳过存储库中的无效代码

为什么有必要

我们有什么

-

More articles: