كيفية عدم تخطي التعليمات البرمجية غير الصالحة في المستودع

لماذا هو ضروري


عندما يعمل أكثر من شخص في فريقك ، بطريقة أو بأخرى ، يواجه الجميع مشكلة أنماط الترميز المختلفة لكل عضو في الفريق. شخص ما يكتب بين قوسين لبنات if...else، شخص لا يفعل ذلك. عندما يصبح المشروع أكبر ، يكون من الأصعب قراءة مثل هذا الكود ، بل ومن الأصعب إجراء مراجعة الكود.


حتى لا تتحول مراجعة الكود واجتماعات الفريق الأخرى إلى مناقشة حول علامات التبويب مقابل المسافات ذات النغمات المرتفعة ، فمن الأفضل تكوين المستودع بحيث لا يسمح المشروع نفسه بكتابة كود غير صالح وغير قياسي للفريق.


من ناحية ، قد يبدو أن استخدام أنماط الترميز المختلفة لذيذة وغير جديرة بالاهتمام. حسنًا ، لا يلتصق شهر يونيو بسطر واحد من التعليمات البرمجية بعد الشرط if، ولكن يكتب أحدهم ، فماذا؟ إذا تركت الرمز من تحت قلم يونيو "كما هو" ، فيمكن أن يصبح هذا "قنبلة موقوتة": ifيمكن حذف هذا السطر من التعليمات البرمجية بعد ذلك ، ثم يقع السطر التالي تحت الشرط. بالطبع ، يتم اكتشاف هذا الموقف عادةً في مراجعة الكود ، ولكن يحدث أن هذا الخطأ المحتمل يجتاز الاختبار ، وهنا سببين رئيسيين:


  1. كلنا بشر والناس مخطئون.
  2. الأشخاص اجتماعيون ، مما يعني أنهم لن يرغبوا في الدخول في "صراع" مع الأنماط. وهنا خياران ممكنان:
    • يعتقد المراجع: "أصلحها بنفسي بشكل أفضل" ، وصحح الشفرة.
    • المفتش ينهار في يونيو ويعرب عن شكوكه حول كفاية وضرورة الوجود.

كيف نضمن أن يكتب الجميع وفقًا لأسلوب الفريق؟ للتغلب على مراجعة الكود في كل مرة يحبط كلا من كاتب الكود والمفتش نفسه. لحسن الحظ ، تثير هذه المشكلة عقول أكثر من مبرمج لأكثر من عام ، والآن لدينا العديد من الأدوات تحت تصرفنا.


الغرض من هذه المقالة هو إخبار الآخرين وأنا عن المستقبل حول كيفية تكوين مستودع المشروع بطريقة تحمي نفسها من التعليمات البرمجية غير الصالحة من حيث معايير الفريق.


ما لدينا


كمثال ، خذ مشروعًا تجريبيًا سيتم نشر رمزه على GitHub. نظرًا لأنني أقوم بالتطوير على .NET Core ، سيتم كتابة المشروع عليه. ما سأستخدمه:


  • دوت نت 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"
    }
  }

: , , "".



بعد اتخاذ الخطوات الموضحة في المقالة ، أحصل على مشروع "يحمي نفسه" من التعليمات البرمجية غير الصالحة. من الواضح أنه لا يمكنك حفظ المنتج من الأخطاء باستخدام دليل بناء جملة وأسلوب واحد ، ولكن حتى هذه الأشياء الصغيرة تساعد في تحقيق جودة أفضل للرمز وتسمح لك بمناقشة الحلول المعمارية لمراجعات الشفرة بدلاً من مشاكل التنسيق.


All Articles