Headhunter هي شركة منتجات ، وجودة الكود مهمة للغاية بالنسبة لنا. كلما كان ذلك أفضل ، كلما تمكنا من إصدار ميزات أعمال جديدة بشكل أسرع ، وأسرنا المستخدمين في أغلب الأحيان.
لكل طلب سحب ، يجب اجتياز مراجعة ، حتى لو تم تغيير سطر واحد فقط. يحتاج شخص واحد على الأقل إلى تقييم ، والمراجعة مفتوحة ، ويمكن لأي شخص المشاركة ، وهذا مرحب به. المراجعة ضرورية لتحسين جودة الكود ونشر المعرفة بين الفرق المختلفة.
في السابق ، كان للمناقشة نقاش مستمر حول كيفية وما يجب أن يكتب بشكل صحيح. استغرق الأمر الكثير من الوقت والجهد. لحل هذه المشكلات ، تمت كتابة دليل الأنماط. لقد ساعد كثيرًا ، كما ظهر مصدر للحقيقة ، يمكن الإشارة إليه دائمًا. يساعد Style Style أيضًا المبتدئين على الدخول في المشروع ، ويشرح على الفور ما وكيفية الكتابة ، وما يمكن توقعه في المراجعة.
ومع ذلك ، كانت هناك مشكلة كبيرة مع Style Style - فقد كان الناس ينسون عنه كثيرًا ، وكان عليه إعادة القراءة والربط بشكل مستمر مع طلب السحب لإثبات أنه كان على صواب. نتيجةً لذلك ، تراجعت المراجعة في بعض الأحيان إلى نزاعات متحيزة ، فقد تحول شيء مثل هذا إلى:
أنت نفسك تفهم كم يثبط هذا الأمر المطور ، ومقدار الوقت الذي يقضيه في النزاعات غير المجدية في المراجعة. نتيجةً لذلك ، لم يرغب الأشخاص في مراجعة مطورين آخرين ومراجعتهم.
لجعل رئيس مؤلف الشفرة والمراجع أقل انشغالًا مع أسئلة حول كيفية وضع الفواصل وبأية طريقة لكتابة قواعد border قررنا تطبيق الأتمتة ، في ذلك الوقت كان jshint ، أصبح أفضل بكثير. بعد التبديل إلى eslint بسبب عدد من المزايا:
- هو أكثر مرونة
- هناك جميع أنواع الإضافات لذلك.
- الشركات المختلفة لديها التكوينات الجاهزة جيدة
لفترة طويلة ، ورثناها من airbnb ، ولكن ليس كل ما airbnb فيه ، كان علينا إعادة تعريف بعض القواعد. لم تكن مريحة للغاية ، ونتيجة لذلك كتبنا التكوين لدينا على أساس airbnb. أضفنا أيضا السنانير precommit ، في ذلك الوقت استخدمنا أجش . إذا كتب المطور شيئًا خاطئًا ، فقد اكتشف على الفور متى حاول تنفيذ تغييراته على جيثب.
لكن لسوء الحظ ، لم يغطي eslint جميع جوانب تنسيق التعليمات البرمجية ، تمت إضافة أجمل لحل هذه المشكلة.
لحسن الحظ ، يعمل كل من eslint و أجمل بشكل جيد معًا ، كل ما تحتاجه هو وضع eslint-plugin- prettier و eslint-config- .eslintrc ثم إصلاح .eslintrc مثل هذا:
... "plugins": ["prettier"], "extends": ["@hh.ru/eslint-config", "prettier"], "rules": { "prettier/prettier": ["error"], ...
قبل إطلاق كل هذا على المنتج ، كان من الضروري yarn eslint --fix <path_to_js> قاعدة الشفرة بأكملها وتصحيحها للامتثال للقواعد الجديدة ، واتضح أنها ليست صعبة على الإطلاق: yarn eslint --fix <path_to_js>
بعد ذلك ، اختفى معظم النقاش حول كيفية كتابة التعليمات البرمجية وتنسيقها ، لأن كل شيء يتم تغطيته بواسطة الأتمتة. المجموع الآن لدينا:
- يتم فحص جميع js و jsx وتثبيتها تلقائيًا باستخدام eslint و أجمل.
- لأقل من ذلك ، يتم استخدام stylelint .
- لثعبان flake8.
يتم فحص الملفات المعدلة على جهاز المطور عند ارتكابها ، باستخدام lint-staged ، إليك .lintstagedrc لدينا:
{ "*.{js,jsx}": ["eslint --fix", "git add"], "*.less": "stylelint", "*.py": "flake8", "package.json": "bash -c 'yarn check-versions && yarn install --frozen-lockfile'", }
يتم إدخال رمز تم اجتيازه بالفعل في الاختبارات مع github ؛ لا يحتاج المراجع إلى التفكير في هذا الأمر بعد الآن والاهتمام بالأشياء الصغيرة. يمكنك التركيز تمامًا على مدى جودة كتابة الكود ، وإذا كانت هناك أية مشكلات في الأداء ، والتفكير في البنية.
بعد المراجعة ، يتم تجميع حاوية الإرساء ، أثناء التجميع ، يتم تشغيل جميع الاختبارات التلقائية والبطانات. الآن تستغرق عملية التجميع بأكملها حوالي 7.5 دقيقة ، بينما لدينا الآن حوالي 1000 ملف و 650 ملف أقل. كل هذا ضروري ، لأنه محليًا على الجهاز ، يمكنك تخطي استخدام --no-verify ، والتعليقات في github لا تمنع المهمة. خداع التجمع لا يعمل.
بعد اجتياز الاختبارات الذاتية ، يبدأ الاختبار اليدوي. إذا لم يعثر الفاحص على خطأ واحد ، فستنتقل المهمة إلى همز.
في حالة حدوث خطأ في أي مرحلة ، تُرجع المهمة للمراجعة.
وكانت النتيجة:
- من الأسهل والأسرع في كتابة الكود.
- أسهل للقيام مراجعة
- يحتوي المعالج دائمًا على كود الجودة
- أقل جدل ، مزيد من السعادة
نراقب جودة الكود أثناء تنفيذ مهام العمل ، لكن المنتج يتطور باستمرار ، تظهر شروط إضافية في الكود ، ويزيد التعقيد. تظهر تقنيات جديدة أيضًا ، التقنيات القديمة تموت بسبب كل هذا ، تظهر ضريبة فنية. كجزء من الضريبة ، نشارك في:
- تحسين صفحة مخصصة
- تغيير البنية التحتية
- تحسين Codebase
ينبغي أن تقضي جميع فرق المنتجات 70٪ من وقتهم في تطوير مهام العمل ، و 30٪ على الضرائب - وهذا يمنح كل مطور الفرصة للانخراط في مهام البنية التحتية ، والحفاظ على قاعدة الكود في حالة ممتازة ، ونشر المعرفة حول البنية التحتية للمشروع عبر جميع الفرق. كضريبة ، ليس من الضروري القيام بمهام فريقك ؛ يمكنك كتابة التعليمات البرمجية في أي جزء من المشروع. يمكن لأي شخص اقتراح ضريبة ، إذا كانت مفيدة ، فسيتم إضافتها إلى الأعمال المتراكمة. بالإضافة إلى ذلك ، هناك فرق معمارية تتعامل مع الميزات التكنولوجية طوال الوقت. كل هذا يسمح لك للحفاظ على قاعدة رمز محدثة.