أفضل الممارسات لبناء فريق عمل قوي ومتماسك
التعاون أمر بالغ الأهمية لنجاح تطوير البرمجيات. فالفريق القوي الذي يعمل معًا بشكل جيد يمكنه تحقيق نتائج أفضل والتغلب على التحديات. ولتعزيز التعاون، يتطلب الأمر جهدًا وتواصلًا وتعاونًا مستمرًا...
تعد جودة التعليمات البرمجية جزءًا مهمًا من عملية التطوير، خاصةً عندما تريد العمل بكفاءة على المدى الطويل. هناك العديد من الأساليب وأفضل الممارسات، بما في ذلك المنهجيات الرشيقة بأكملها، ولكن معظمها يتعلق بمشروع كبير ومؤسسي يقوم به 6 أشخاص على الأقل.
ماذا علينا أن نفعل، عندما المشروع صغيرة أم أن العميل لا يزال لا يعرف ما إذا كان الأمر يستحق استثمار المزيد؟ من الواضح، في مرحلة MVP من المشروع, الكود التصميم أو اختبارات الوحدة ليست الأولوية القصوى. يرغب المستثمرون عادةً في الحصول على المنتج وهيا - إذا كان يعمل، فهو لا يحتاج إلى اختبار، أليس كذلك؟
في الواقع، لدي بعض الخبرة في إنشاء تطبيقات من الصفرحتى بدون استخدام أفضل الممارسات في المقام الأول. فقد أجبرتني بعض ظروف العمل على البحث عن حل وسط بين خطط ميزانية المستثمر وقائمة "ما يجب أن يكون" لدى المطور. لحسن الحظ، إذا كنت تستخدم GitHub، يمكن حل معظم المشكلات الشائعة المتعلقة بجودة التعليمات البرمجية في بضع دقائق.
بعض الافتراضات قبل أن نبدأ:
إذا سبق لك استخدام بعض أطر عمل JS مثل Vue أو React، يمكنك بسهولة تحديد بعض الأمور المشتركة بينهما، على سبيل المثال
حتى لو كنا نتحدث عن JavaScript المشروع، نحن نعمل في العقدة البيئة، لذلك من الواضح أنه يجب أن يكون هناك أيضًا بعض الأشياء الخاصة بالعقدة مثل الحزمة.json, حزمة-قفل الحزمة.json و / العقدة_الوحدات النمطية في دليلنا الجذر.
كل هذه الأشياء في مكانها - وهذا ما نطلق عليه اسم الاتفاقية. تم اختراع الأطر لتوفير بعض الاصطلاحات المعقولة، لذلك عادةً لا نحتاج حتى إلى الاهتمام بنمط التصميم الأولي. كما في هذا المثال، أريد أن أشرح بعض الأساليب، لن أطبق أي حلول جاهزة للاستخدام مثل Vue CLI.
حان الوقت لفهم ما الذي يكمن تحت كل هذه النصوص السحرية!
لتوفير حلول عالية الجودة، فإن البطانات هي أول ما يجب أن نبدأ به أثناء إعداد مشروع جديد. دعونا نركز على اثنين من البطانات - ستايل لينت للأنماط (*.scss) و ESLint للملفات المصدرية (*.js). كلتا هاتين البطانات متوفرة على NPM ومن السهل جدًا تهيئتها. يتطلب استخدام البطانات المرور بعملية التثبيت، وإضافة ملفات التهيئة وتحديد البرامج النصية للمشروع. لنفعل ذلك خطوة بخطوة.
إن تثبيت 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 مشكلة
هذه الخطوة هي تقريبًا نفس الخطوة السابقة. سنقوم بتثبيت ESLint، وتحديد بعض مجموعة القواعد الافتراضية وإعلان نصين برمجيين NPM قابلين للاستدعاء - أحدهما للتثبيت التلقائي والآخر للدفع المسبق. دعونا ننتقل إلى هذا!
إذا كنت تستخدم NPM في عملك اليومي، فربما ترغب في تثبيت ESLint عالميًا. إذا لم تكن تستخدمه، يُرجى مراجعة تعليمات التثبيت في المستندات الرسمية.
تثبيت npm -g eslint
عندما يتوفر أمر eslint على جهازك، ما عليك سوى تشغيله في مشروعك:
إسلينت -إنشاء
باتباع المزيد من التعليمات المعروضة في جهازك الطرفي، ما عليك سوى اتخاذ بعض القرارات الخاصة بالمشروع مثل:
في هذا المكان، يجدر بنا أن نكتب كلمة عن مُنسِّق الشيفرة البرمجية المسمى 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 تحذير)
لن يختفي هذا التحذير بعد استخدام -الإصلاح خيار؛ لأن لا تؤثر المبطّنات على الشيفرة ذات المعنى المحتمل. إنها فقط لتصميم الشيفرة، بما في ذلك المسافات البيضاء والأسطر الجديدة والفواصل المنقوطة وعلامات الاقتباس وما إلى ذلك.
سير عمل 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 قبل دمج طلب السحب الخاص بك: