Window.pipedriveLeadboosterConfig = { القاعدة: 'leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', الإصدار: 2, } ؛(الدالة () { var w = نافذة إذا كان (w.LeadBooster) { console.warn('LeadBooster موجود بالفعل') } وإلا { { w.LeadBooster = { q: [], على: دالة (ن، ح) { { هذا.q.push({ t: 'o'، n: n، n: n، h: h }) }, الزناد: الدالة (n) { هذا.q.push({ t: 't'، n: n: n }) }, } } })() الجودة أولاً! 5 خطوات سهلة لنسالة التعليمات البرمجية الخاصة بك مع سير عمل GitHub في مشروع JavaScript - The Codest
The Codest
  • نبذة عنا
  • الخدمات
    • تطوير البرمجيات
      • تطوير الواجهة الأمامية
      • تطوير الواجهة الخلفية
    • Staff Augmentation
      • مطورو الواجهة الأمامية
      • مطورو الواجهة الخلفية
      • مهندسو البيانات
      • مهندسو السحابة
      • مهندسو ضمان الجودة
      • أخرى
    • استشاري
      • التدقيق والاستشارات
  • الصناعات
    • التكنولوجيا المالية والمصرفية
    • E-commerce
    • أدتك
    • التكنولوجيا الصحية
    • التصنيع
    • الخدمات اللوجستية
    • السيارات
    • إنترنت الأشياء
  • القيمة مقابل
    • CEO
    • CTO
    • مدير التوصيل
  • فريقنا
  • دراسات الحالة
  • اعرف كيف
    • المدونة
    • اللقاءات
    • ندوات عبر الإنترنت
    • الموارد
الوظائف تواصل معنا
  • نبذة عنا
  • الخدمات
    • تطوير البرمجيات
      • تطوير الواجهة الأمامية
      • تطوير الواجهة الخلفية
    • Staff Augmentation
      • مطورو الواجهة الأمامية
      • مطورو الواجهة الخلفية
      • مهندسو البيانات
      • مهندسو السحابة
      • مهندسو ضمان الجودة
      • أخرى
    • استشاري
      • التدقيق والاستشارات
  • القيمة مقابل
    • CEO
    • CTO
    • مدير التوصيل
  • فريقنا
  • دراسات الحالة
  • اعرف كيف
    • المدونة
    • اللقاءات
    • ندوات عبر الإنترنت
    • الموارد
الوظائف تواصل معنا
السهم الخلفي العودة إلى الوراء
2020-03-10
تطوير البرمجيات

الجودة أولاً! 5 خطوات سهلة لنسالة التعليمات البرمجية الخاصة بك مع سير عمل GitHub في مشروع JavaScript

فويتشيتش باك

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

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

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

في هذه المقالة، سأوضح لك كيفية استخدام تدفقات عمل GitHub في بيئة Node.js لتوحيد قاعدة التعليمات البرمجية الخاصة بك.

بعض الافتراضات قبل أن نبدأ:

  • أنت معتاد على NPM ووحدة تحكم Linux.
  • لديك بعض الخبرة في معالجات الأنماط المسبقة، ومُحمِّلات الوحدات النمطية، والحزم، وما إلى ذلك.
  • أنت تعرف الغرض من البطانات وتريد حقًا استخدامها في مشاريعك.

1. هيكل مشروع نموذجي JavaScript

إذا سبق لك استخدام بعض أطر عمل JS مثل Vue أو React، يمكنك بسهولة تحديد بعض الأمور المشتركة بينهما، على سبيل المثال

  • /Src الدليل الذي يحتوي على كل منطق ومكونات JS الخاص بك,
  • /اختبار دليل اختبارات الوحدة واختبارات e2e,
  • /الأصول دليل للأنماط والصور وما إلى ذلك.

حتى لو كنا نتحدث عن JavaScript المشروع، نحن نعمل في العقدة البيئة، لذلك من الواضح أنه يجب أن يكون هناك أيضًا بعض الأشياء الخاصة بالعقدة مثل الحزمة.json, حزمة-قفل الحزمة.json و / العقدة_الوحدات النمطية في دليلنا الجذر.

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

حان الوقت لفهم ما الذي يكمن تحت كل هذه النصوص السحرية!

2. توسيع مشروع العقدة النموذجي

لتوفير حلول عالية الجودة، فإن البطانات هي أول ما يجب أن نبدأ به أثناء إعداد مشروع جديد. دعونا نركز على اثنين من البطانات - ستايل لينت للأنماط (*.scss) و ESLint للملفات المصدرية (*.js). كلتا هاتين البطانات متوفرة على NPM ومن السهل جدًا تهيئتها. يتطلب استخدام البطانات المرور بعملية التثبيت، وإضافة ملفات التهيئة وتحديد البرامج النصية للمشروع. لنفعل ذلك خطوة بخطوة.

3. إضافة ستايل لينت

إن تثبيت Stylelint في بيئة Node بسيط للغاية. وفقًا لـ المستندات الرسمية، ما عليك سوى الجري:

تثبيت npm -تثبيت -حفظ-تطوير-حفظ-طريقة-طريقة-تطوير-معيار-تكوين-معيار-أسلوب-لنت

وانتظر حتى ينتهي الأمر

ستايلينت-كونفيج-معيار-ستايلينت يوفر مجموعة افتراضية من قواعد التلوين ويمكن استبداله بأي حزمة تناسب احتياجاتك بشكل أفضل (على سبيل المثال أسلوب Airbnb). ثم قم بإنشاء ملف مخفي جديد .stylelintrc.jsonوهو ملف تهيئة Stylelint، المسؤول عن تحميل قواعدنا المحددة مسبقًا:

{
    "extends": "stylelint-config-standard"
}

في الوقت الحالي، الشيء الوحيد المفقود هو بعض النصوص البرمجية (أو النصوص البرمجية) NPM المعلنة في ملف package.json لبدء تظليل ملفات SCSS الخاصة بنا. هذا هو اقتراحي:

"نصوص": {
    "lint:scss": "stylelint '**/*.scss' -Syntlint:scss -Syntax scss -f verbose --color",
    "lint:scss:fix": "stylelint '**/*.scss' ---نحو scss -f verbose -color": "stylelint '**/*.scss' -scss -f verbose -color"
}

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

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

لنختبر المُبطِّن من خلال إنشاء ملف /الأصول/ssssss/styles.scss مع بعض المحتويات، مثل

الجسم {
                    لون الخلفية: #fff;
}
تشغيل npm lint:scss

يجب أن ترى في وحدة التحكم الخاصة بك شيئًا كهذا:

> stylelint '**/*.scss' - الصيغة scss -f verbose - اللون

الأصول/ssssss/styles.scss

2:21 ✖ المسافة البادئة المتوقعة 2 مسافة بادئة

1 تم التحقق من المصدر

~/Codest/Projects/github-workflow-demo/assets/ssss/styles.scss

تم العثور على 1 مشكلة

مستوى الخطورة "خطأ": 1

المسافة البادئة 1

npm ERR! الرمز ELIFECYCLE

npm ERR! خطأ 2

npm ERR! [email protected] lint:scss: ''stylelint '**/*.scss' - الصيغة scss -f verbose - اللون''

npm ERR! حالة الخروج 2

هذا يعني في الواقع أن المُبطِّن يعمل!

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

npm تشغيل lint:scss:fix

الآن يجب أن ترى مخرجات خضراء مع عدم وجود أخطاء:

stylelint '**/*.scss' - الصيغة scss - الصيغة scss - f-fix -f verbose - color


1 تم التحقق من المصدر

/Users/wojciechbak/Codest/Projects/github-workflow-demo/assets/ssssss/styles.scss

0 تم العثور على 0 مشكلة

4. إضافة ESLint

هذه الخطوة هي تقريبًا نفس الخطوة السابقة. سنقوم بتثبيت ESLint، وتحديد بعض مجموعة القواعد الافتراضية وإعلان نصين برمجيين NPM قابلين للاستدعاء - أحدهما للتثبيت التلقائي والآخر للدفع المسبق. دعونا ننتقل إلى هذا!

إذا كنت تستخدم NPM في عملك اليومي، فربما ترغب في تثبيت ESLint عالميًا. إذا لم تكن تستخدمه، يُرجى مراجعة تعليمات التثبيت في المستندات الرسمية.

تثبيت npm -g eslint

عندما يتوفر أمر eslint على جهازك، ما عليك سوى تشغيله في مشروعك:

إسلينت -إنشاء

باتباع المزيد من التعليمات المعروضة في جهازك الطرفي، ما عليك سوى اتخاذ بعض القرارات الخاصة بالمشروع مثل:

  • جافا سكريبت أو TypeScript
  • أسلوب Airbnb أو أسلوب جوجل
  • نوع التكوين (ملف JSON أو ملف JS أو مضمن في الحزمة.json)
  • وحدات ES (الاستيراد/التصدير) أو تتطلب بناء الجملة

في هذا المكان، يجدر بنا أن نكتب كلمة عن مُنسِّق الشيفرة البرمجية المسمى Prettier. إنه موحد تمامًا ومتوافق مع معظم برامج تحرير الأكواد (مثل VS Code). يوفر Prettier العديد من مجموعات قواعد تصميم الشيفرة المحددة مسبقًا، ويعمل بشكل مشترك مع المُبرمجين ويمكن أن يكون دعمًا كبيرًا في السعي وراء أعلى جودة للشيفرة. لفهم ما هو بريتييه بالضبط، قم بزيارة هذا المقارنة من المستندات الرسمية

إذا تم ذلك، فإن ملف تكوين ESlint (على سبيل المثال .eslintrc.json، اعتمادًا على ما اخترته من قبل) يجب أن يظهر في الدليل الجذر الخاص بك، في مكان ما بجوار .stylelintrc.json تم إنشاؤها من قبل.

الآن علينا تعريف البرامج النصية في الحزمة.json كما هو الحال بالنسبة لملفات SCSS:

"نصوص": {
    "lint:js": "eslint '**/*.js' --ignore-pattern node_modules/",
    "lint:js:fix": "eslint '**/*.js' --ignore-pattern node_modules/ --fix"
}

تهانينا! ESLint جاهز للاستخدام الآن. دعنا نتحقق مما إذا كان يعمل بشكل صحيح. إنشاء /src/index.js ملف مع بعض المحتويات:

وحدة التحكم.log("شيء ما");

تشغيل التبطين:

تشغيل npm lint:js


يجب أن يبدو الناتج هكذا:

> eslint '**/*.js' --تجاهل نمط node_modules/

~/Codest/Projects/github-workflow-demo/src/index.js

1:1 تحذير عبارة غير متوقعة لوحدة التحكم no-console

✖ 1 مشكلة (0 خطأ، 1 تحذير)

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

5. تحديد سير عمل GitHub

سير عمل GitHub هي شيء موثق جيدًا. لا تتردد في التعمق أكثر في هذا الأمر، ولكن في الوقت الحالي، سأقوم بتنفيذ سير عمل بسيط لنسالة الشيفرة بعد الدفع إلى المستودع البعيد (من الواضح أنه مستضاف على GitHub).

إنشاء /.github/workflows الدليل والجديد كود-جودة-سير العمل.yml هناك حيث يجب تعريف مهام سير عمل GitHub بملفات YAML.

لتشغيل سير عمل مناسب، علينا الإجابة عن بعض الأسئلة:

  • متى نريد تشغيل سير عملنا (عند الدفع، عند طلب السحب، عند الدمج، إلخ)؟
  • هل نريد استبعاد بعض الحالات (مثل الدفع إلى الفرع الرئيسي)؟
  • ما هي البيئة التي نحتاج إلى إعدادها لتشغيل أوامرنا بشكل صحيح (في هذا المثال - العقدة)؟
  • هل نحتاج إلى تثبيت التبعيات؟ إذا كان الأمر كذلك، كيف يجب علينا تخزينها مؤقتًا؟
  • ما الخطوات التي نحتاج إلى اتخاذها لإكمال الفحص؟

بعد بعض الاعتبارات وبضع ساعات من العمل مع مثال المستندات .yml يمكن أن يبدو الملف هكذا

الاسم: جودة الكود

على: 'دفع'

الوظائف
  جودة الكود
    الاسم: كود مصدر الوبر
    التشغيل: ubuntu-latest
    الخطوات:
    - الاستخدامات: الإجراءات/التحقق@v1

    - الاسم: إعداد العقدة
      يستخدم: الإجراءات/إعداد العقدة@v1
      مع:
        إصدار العقدة: '12.1'

    - الاسم: تبعيات ذاكرة التخزين المؤقت
      الاستخدامات: الإجراءات/ذاكرة التخزين المؤقت@v1
      مع:
        المسار: ./node_modules
        المفتاح: $(( runner.OS ))-dependencies-$(( hashFiles(**/package-lockage-lock.json")) ))
        مفاتيح الاستعادة |
          $(( runner.OS ))-التبعية-$(( env.cache-name ))-
          $(( runner.OS ))-التبعيات-
          $(( runner.OS ))-

    - الاسم: تثبيت التبعيات
      تشغيل |
        تثبيت npm

    - الاسم: ملفات الوبر
      تشغيل: |
        تشغيل npm lint

يوفر GitHub جميع الأشياء البيئية التي نحتاجها. في السطر الأخير نقوم بتشغيل الأمر تشغيل npm lint والتي لم تكن محددة من قبل:

"نصوص": {
    "lint": "npm run lint: js & npm run lint: scss"
}

لاحظ أنه في سير العمل لدينا، لا أستخدم :: الإصلاح الأوامر.

عند الانتهاء من كل هذه الخطوات، يمكنك الاستمتاع بهذا الإخراج الجميل من GitHub قبل دمج طلب السحب الخاص بك:

مقالات ذات صلة

الحلول المؤسسية وحلول التوسعة

أفضل الممارسات لبناء فريق عمل قوي ومتماسك

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

The Codest
كريستيان بارشانسكي قائد وحدة الواجهة الأمامية
تطوير البرمجيات

كيفية تنفيذ Agile Methodology؟

أتقن المنهجية الرشيقة مع أفضل الممارسات للتنفيذ الناجح والإدارة المعززة للمشروع في تطوير البرمجيات.

ذا كوديست

اشترك في قاعدة معارفنا وابقَ على اطلاع على آخر المستجدات في قطاع تكنولوجيا المعلومات.

    نبذة عنا

    The Codest - شركة دولية لتطوير البرمجيات لها مراكز تقنية في بولندا.

    المملكة المتحدة - المقر الرئيسي

    • المكتب 303 ب، 182-184 شارع هاي ستريت نورث E6 2JA
      لندن، إنجلترا

    بولندا - مراكز التكنولوجيا المحلية

    • مجمع مكاتب فابريتشنا المكتبي، أليجا
      بوكوجو 18، 31-564 كراكوف
    • سفارة الأدمغة، كونستروكتورسكا
      11, 02-673 02-673 وارسو، بولندا

      The Codest

    • الصفحة الرئيسية
    • نبذة عنا
    • الخدمات
    • دراسات الحالة
    • اعرف كيف
    • الوظائف
    • القاموس

      الخدمات

    • استشاري
    • تطوير البرمجيات
    • تطوير الواجهة الخلفية
    • تطوير الواجهة الأمامية
    • Staff Augmentation
    • مطورو الواجهة الخلفية
    • مهندسو السحابة
    • مهندسو البيانات
    • أخرى
    • مهندسو ضمان الجودة

      الموارد

    • حقائق وأساطير حول التعاون مع شريك خارجي لتطوير البرمجيات
    • من الولايات المتحدة الأمريكية إلى أوروبا: لماذا تقرر الشركات الأمريكية الناشئة الانتقال إلى أوروبا؟
    • مقارنة مراكز تطوير التكنولوجيا في الخارج: تك أوفشور أوروبا (بولندا)، آسيان (الفلبين)، أوراسيا (تركيا)
    • ما هي أهم التحديات التي تواجه CTOs ومديري تكنولوجيا المعلومات؟
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • شروط استخدام الموقع الإلكتروني

    جميع الحقوق محفوظة © 2025 بواسطة The Codest. جميع الحقوق محفوظة.

    arArabic
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish it_ITItalian jaJapanese ko_KRKorean es_ESSpanish nl_NLDutch etEstonian elGreek arArabic