أنا مطور جافا رائد في Yandex.Money.

كل صباح عام 2018 ، قوبلت بحوالي 30 طلب سحب في انتظار المراجعة ، ولم يكن لدي ما يكفي من الوقت لفرزها كلها في يوم واحد. في نهاية الصيف ، ذهبت في إجازة ، وعندما عدت ، وجدت طابورًا قدره 50 عامًا تم تعيينه لي. لم تكن هناك رغبة في إيقادهم ، لكن في الحقيقة كانت قمة جبل الجليد ، التي رأيتها بأم عيني. في ذلك اليوم قررت أن الوقت قد حان لتغيير شيء ما.

هذه هي قصة كيفية تسريع عملية مراجعة الكود وإلغاء تحميل المطورين الرئيسيين وتحسين الأدوات التي نستخدمها كل يوم.

مراجعة الكود 1.0. كيف كان ذلك من قبل؟

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

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

ونتيجة لذلك ، كان العبء بأكمله يقع على عاتق المراجعين من بين كبار المطورين ، الذين توقفوا تدريجياً عن أن يكونوا كافيًا ، مع مراعاة نمو القسم إلى 60 شخصًا ، وزيادة في عدد المستودعات (60+ مكونًا ، و 100 مكتبة +) وتسريع CI / CD لدينا.

بالإضافة إلى عبء العمل الثقيل ونقص الموارد لدى المراجعين ، كانت هناك مشاكل أخرى:

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

قبل حل هذه المشكلات ، تحتاج إلى تحديد ما نتوقعه عمومًا من مراجعة الكود.

مراجعة الرمز الصحيح هو كيف؟

لقد حددنا أربع نقاط يجب أن تكون في مراجعة التعليمات البرمجية المحدثة:

1. التحقق من صحة بنية الحل . شيء واضح جدا. نتوقع هذا من كبار المطورين ذوي الخبرة في هذا المكون.
2. التحقق من التنفيذ الفني ، والذي نتوقعه أيضًا من كبار المتخصصين والمتوسطين ذوي الخبرة في هذا المكون.
3. نقل المعرفة ، والذي يتكون من دراسة منطق الأعمال وقاعدة الكود بواسطة المبتدئين ويونيو من خلال مراجعات الكود.
4. القدرة على تقييم المهارات الصعبة للمطورين . أريد أن يعين لكل مطور معلمًا يقوم بتقييم النمو وتحديد متجه التطوير وإشعار بعض أوجه القصور وإبداء التعليقات وما إلى ذلك. لذلك ، يجب أن يرى المرشد أيضًا رمز عنابره.

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

مراجعة الكود 2.0. كيف يتم ذلك؟

ماذا توصلنا؟ بدأنا في التفكير خطوة بخطوة.

في Yandex.Money ، يعمل مطورو البرامج في فرق في مجالات الأعمال ، وعادة ما يكونوا مطورين خلفيين في الفريق.

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

يحتوي كل مكون في Yandex.Money على فريق مسؤول عن الإنتاج ويرافقه.

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

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

في عام 2018 ، قدمنا ​​معهد التوجيه في الشركة ، لذلك الآن هناك معلم واحد من بين كبار المطورين يراقب كل فريق. أيضا ، كل قادم جديد للشركة في البداية لديه معلمه شخصي.

اسمحوا لي معلمه مشاهدة رمز بلدي! سيكون قادرًا على المساعدة في حالة حدوث مشكلات في مراجعة التعليمات البرمجية ، كما سيكون لديه فكرة عن نقاط قوتي وضعف في المهارات الفنية.

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

مراجعة الكود 2.0. ما تحت غطاء محرك السيارة؟

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

كيف يعمل البرنامج المساعد

عادة ، عند إنشاء PR ، يقوم Bitbucket بملء المشاهدين المحددين في إعدادات المشروع أو مستودع التخزين. من وجهة نظر المستخدم ، لم يتغير شيء هنا - يتم ملء جميع المراجعين أيضًا مسبقًا عند فتح هذه الصفحة ، باستثناء أنه تمت إضافة حقل مع وصف المراجع في الدور الذي تمت إضافته. وظهرت أدوار المراجعين فيما يلي:

• teammate هو عضو في فريق مؤلف العلاقات العامة ، ويمكن إضافته بسهولة بفضل واجهة برمجة تطبيقات REST مع تكوين الفرق ،
• مالك المستودع - عضو عشوائي في الفريق المسؤول عن المكون ؛ في إعدادات المستودع ، كان من الضروري إعطاء الفرصة لاختيار الفريق المسؤول ،
• خبير مستودع - خبير مستودع عشوائي. سوف أخبركم المزيد حول هذا الأمر لاحقًا
• mentor - موجه خاص لفريق أو مبتدئ ، يتوفر أيضًا عبر واجهة برمجة تطبيقات REST من خلال خدمة تشتمل على تكوينات فريق.

مستودع المستودع

سوف أخبركم قليلاً عن كيفية تفكيرنا في الخبراء. في كل يوم ، يمر المكوّن الإضافي عبر جميع المستودعات ، وينظر في جميع طلبات السحب للعام الماضي ويفكر في مقياسين بسيطين:

• عدد طلبات السحب التي أنشأها المطور ،
• عدد PRS الذي استعرضه ووافق عليه ، يحتاج إلى عمل أو انخفاض.

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

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

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

حظر دمج طلب السحب حتى يتم فحص المهمة في جيرا

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

طلب سحب دمج تلقائي

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

يتم تغطية جميع الشروط اللازمة لدمج الشيكات. نتحقق من نجاح التجميع ، ومستوى التغطية التجريبية ، وغياب التبعيات السريعة للمكتبات ، وحالة المهمة في جيرا ، ووجود جميع التحديثات اللازمة. أي ، لدينا كل شيء لاستخدام هذه الوظيفة وننسى العلاقات العامة من لحظة تمرير مراجعة الكود وتقديم المهمة للاختبار (ما لم تجد QA مشكلات في ذلك بالطبع).

وقمنا بتنفيذ ذلك بطريقة مريحة إلى حد ما: لقد قدمنا ​​روبوت AutoMergeBot خاصًا ، نحتاج فقط إلى إضافته إلى المراجعين ، بحيث يمكنه البدء في مراقبة طلب السحب هذا وتجميده عندما يحين الوقت.

المحاسبة عن غياب المراجعين

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

المحاسبة لتوظيف المراجعين

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

بمناسبة أحجام العلاقات العامة عند إنشاء

في صفحة إنشاء طلب السحب ، يمكن للمؤلف اختيار الحجم التقريبي: S أو M أو L. وهذا يساعد المراجعين على تقدير الوقت التقريبي الذي سيقضونه في مراجعة الكود. على سبيل المثال ، لديّ 5 دقائق مجانًا ، وأنا أفهم أنه يمكنني التحكم في رؤية طلب السحب الخاص بالحجم. S. ليس من المنطقي فتح M أو L ، لأنه ليس لدي وقت لمشاهدتهما وفي المرة القادمة سوف أبدأ من البداية.

في المستقبل ، نريد أن نأخذ هذه السمات في الاعتبار عند حساب إحصائيات العلاقات العامة.

وصفها عاجل العلاقات العامة

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

تتبع بداية ونهاية مراجعة الرمز

إذا كان من المستحيل فهم العملية أثناء تحسين العملية ، فلا فائدة من البدء.

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

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

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

تتبع تنزيلات المراجعين

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

عرض المقاييس في غرافانا

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

في وقت كتابة هذا التقرير ، تبدو لوحة المعلومات لدينا كما يلي:

ماذا حصلت في النهاية؟

لسوء الحظ ، نحن جميعًا أقوياء في وقت متأخر ، لذلك لم نقدم مقاييس مراجعة الكود المذكورة أعلاه قبل أن تبدأ العملية نفسها في التغيير (من سبتمبر إلى أكتوبر 2018) ، ولكن بالفعل على الطريق ، لذلك يمكننا فقط تتبع التحسينات أو التدهور بشكل موثوق من بداية ديسمبر 2018 ماذا تمكنا من ملاحظة؟

أول ما يلفت انتباهك هو انخفاض العبء على المراجعين الكبار ، وشعرت بهذا بمثالي الخاص. كما ذكرت من قبل ، كان من الطبيعي بالنسبة لي أن أرى حوالي 30 PRS في خط في الصباح ، ولكن الآن يتقلب هذا الرقم بين 10 و 15. وتؤكد إحصاءات القسم هذا: منذ ديسمبر 2018 ، لم يتم رفع الحد الأقصى لعدد PRS في انتظار المراجعة من قبل أي شخص فوق 15. في المتوسط ​​، نلاحظ صورة تشير إلى أن كل مطور يتوقع في المتوسط ​​4-5 مستفيدين PR غير مرئي في الصباح ، وهو ما يبدو أنه رقم مناسب.

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

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