क्यों जरूरी है?

जब आपकी टीम में एक से अधिक व्यक्ति एक या दूसरे तरीके से काम करते हैं, तो हर किसी को टीम के प्रत्येक सदस्य के लिए अलग-अलग कोडिंग स्टाइल की समस्या का सामना करना पड़ता है। कोई ब्लॉकों के लिए कोष्ठक लिखता है if...else, तो कोई नहीं। जब कोई परियोजना बड़ी हो जाती है, तो इस तरह के कोड को पढ़ना और कोड समीक्षा करने के लिए और भी कठिन हो जाता है।

ताकि कोड की समीक्षा और अन्य टीम की बैठक ऊंचे स्वरों के साथ टैब बनाम रिक्त स्थान की चर्चा में न बदल जाए, इसलिए रिपॉजिटरी को कॉन्फ़िगर करना बेहतर है, ताकि प्रोजेक्ट खुद ही कोड लिखने की अनुमति न दे जो कि टीम के लिए अमान्य और गैर-मानक हो।

एक तरफ, अलग-अलग कोडिंग शैलियों का उपयोग स्वादिष्ट लग सकता है, ध्यान देने योग्य नहीं। ठीक है, जून शर्त के बाद कोड की एक भी पंक्ति नहीं लपेटता है if, लेकिन कोई लिखता है, तो क्या? यदि आप जून पेन "जैसा है" के तहत कोड छोड़ते हैं, तो यह "टाइम बम" बन सकता है: कोड की उस लाइन को ifउसके बाद हटा दिया जा सकता है, और फिर अगली लाइन शर्त के तहत आ जाएगी। बेशक, यह स्थिति आमतौर पर एक कोड समीक्षा में पकड़ी जाती है, लेकिन ऐसा होता है कि यह संभावित बग परीक्षण से गुजरता है, और यहां दो मुख्य कारण हैं:

1. हम सभी लोग हैं, और लोग गलत हैं।
2. लोग सामाजिक हैं, जिसका अर्थ है कि वे शैलियों के साथ "संघर्ष" में प्रवेश नहीं करना चाहते हैं। और यहां दो विकल्प संभव हैं:
   
   • "बेहतर इसे स्वयं ठीक करें," समीक्षक सोचता है, और कोड को ठीक करता है।
   • निरीक्षक जून को टूट जाता है और इसकी पर्याप्तता और अस्तित्व की आवश्यकता के बारे में अपने संदेह व्यक्त करता है।

हम यह कैसे सुनिश्चित कर सकते हैं कि हर कोई टीम की शैली के अनुसार लिखता है? हर बार कोड की समीक्षा में हाथों को हराने के लिए कोड के लेखक और इंस्पेक्टर दोनों को खुद को डिमोट करता है। सौभाग्य से, यह समस्या एक वर्ष से अधिक समय तक एक से अधिक प्रोग्रामर के दिमाग को उत्तेजित करती है, और अब हमारे पास हमारे निपटान में कई उपकरण हैं।

इस लेख का उद्देश्य दूसरों और खुद के भविष्य के बारे में बताना है कि कैसे मैं प्रोजेक्ट रिपॉजिटरी को इस तरह से कॉन्फ़िगर करता हूं कि यह टीम मानकों के संदर्भ में अमान्य कोड से खुद को बचाता है।

हमारे पास क्या है

एक उदाहरण के रूप में, एक डेमो प्रोजेक्ट लें जिसका कोड GitHub पर पोस्ट किया जाएगा। चूंकि मैं .NET कोर पर विकसित कर रहा हूं, इस पर प्रोजेक्ट लिखा जाएगा। मैं क्या उपयोग करूंगा:

• .NET कोर 3.1
• कोणीय 8+
• जीथब खाता
• ट्रैविस सी.आई.

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

: , , "".

लेख में वर्णित कदम उठाए जाने के बाद, मुझे एक प्रोजेक्ट मिलता है जो अमान्य कोड से "खुद को बचाता है"। यह स्पष्ट है कि सिर्फ सिंटैक्स और स्टाइल गाइड की जाँच करने से उत्पाद को कीड़े से बचाया नहीं जा सकता है, लेकिन यहां तक ​​कि ये छोटी चीजें बेहतर कोड गुणवत्ता प्राप्त करने में मदद करती हैं और आपको कोड समीक्षाओं के लिए वास्तु समाधानों पर चर्चा करने की अनुमति देती हैं, मुद्दों को प्रारूपित करने में नहीं।