الإنسان هو القيمة الرئيسية لأي مؤسسة. يعتمد نجاح الأمر برمته على كيفية تواصل الناس مع بعضهم البعض ، وكيف يحققون أهدافهم معًا ، وعلى العمل الجماعي. يسمح لك شحذ المهارات والعمليات والأدوات باستمرار بالعمل بكفاءة أكبر.
نحن في السوق نعمل على تقديم ميزات جديدة لمستخدمينا في أسرع وقت ممكن. للقيام بذلك ، ندرس باستمرار عملياتنا وتحسين جميع مراحل المهمة. اليوم سنخبر قراء هابر عن تحسين أحدهم ، ألا وهو عملية مراجعة الكود.
تحتاج أولاً إلى تخيل نوع التدفق في التنمية الذي اعتمدناه:
نفس الشيء ، فقط نقطة بنقطة وبكلمات:
- يأخذ المطور المهمة.
- يجعلها.
- يملأ Github ويفتح العلاقات العامة.
- يمر بمراجعة التعليمات البرمجية.
- يجمع حامل عرض توضيحي ويعطيه لأحد المختبرين.
- يتحقق المختبر من منصة العرض.
- يتم جمع المهمة التي تم التحقق منها في الإصدار.
- الاختبار في الإصدار.
- تخطيط على همز.
- الاختبار النهائي في المعركة.
حسب مجالات المسؤولية ، تنقسم المهمة إلى الخطوات التالية:
1-5 - مسؤولية المطور ؛
6-7 - مسؤولية المختبر ؛
8-10 - المسئولية عن سيد التحرير.
لذا ، بدأوا في تحليل ما يستغرق منا معظم الوقت. لحسن الحظ ، هناك أدوات تحليل داخلية. اعتمد الجميع على ما سيستغرق أطول ، بطبيعة الحال ، عملية التطوير نفسها (الحالة "في العمل") ... واتضح ذلك. لكن لحظة واحدة فاجأتنا أكثر. متوسط مدة المراجعة أسبوعان!
الخطوة 1. تحليل العلاقات العامة
في بداية دراسة طلبات السحب ، واجهوا على الفور حقيقة واحدة مثيرة للاهتمام. اتضح أن لدينا مقبرة ضخمة من طلبات السحب غير المغلقة. لم يعد معظم مؤلفي PRs يعملون في الشركة ، لكن إرثهم كان لا يزال معنا. الذين لم يروا الديناصورات من قبل ، ها هم:
أضافت طلبات السحب هذه ضوضاء وتداخلت مع تحليل وقت مراجعة الكود الصحيح. بعقل هادئ ، أغلقناهم. بقي فقط لسرد الوقت. لكنها كانت لا تزال في منطقة 2-3 أيام. ليس جيدًا.
الخطوة 2: تفكيكها باللون البني
المراجع هو نظام تم تطويره في Yandex يستدعي في العلاقات العامة شخصين عشوائيين من ذوي الخبرة في رمز قابل للتغيير ويأخذ في الاعتبار العطلات والغياب. كشف تحليل PRs الأسبوعية عن مجموعة من الأشخاص الذين يسحبون باستمرار مراجعة الشفرة. بعد إجراء مقابلات مع الزملاء ، وجدنا مشكلة أخرى في عمليتنا. اشتكى الزملاء من أنهم تلقوا الكثير من طلبات السحب يوميًا من الغيرة ، وببساطة لم يكن لديهم الوقت الكافي لعملهم الرئيسي.
لم يتزامن هذا مع مؤشراتنا: واحدة أو اثنتين من العلاقات العامة في اليوم للشخص الواحد. أدت الدراسة إلى Github ، حيث لدينا فريق منفصل من المراجعين. لم يتم تحديث هذا الفريق لعدة سنوات. منذ ذلك الحين ، تضاعف عدد الموظفين ، ولكن لم يتم تضمين أي من الوافدين الجدد في فريق المراجعين. بمعنى آخر ، لم يشارك نصف الفريق في مراجعة الكود على الإطلاق! تصحيح هذا سوء الفهم المزعج.
الخطوة 3. توسيع الأدوات
في هذه المرحلة ، حاولنا تبسيط حياة المراجعين البسيطة بالفعل ، كما اعتقدنا. كانت الأدوات التالية في ترسانة الواجهة الأمامية:
- الداما نمط الكود ؛
- تشغيل تجريبي
- مختلف الشيكات نردي في العلاقات العامة نفسها ؛
- تعديلي
- تنبيهات على تعقب البريد والمهمة.
يبدو أن كل شيء موجود. خذ وراجع!
أول شيء اتضح أنه خطأ: عملية مراجعة شفرة مختلفة في مستودعات مختلفة. لقد توحدنا وأثبتنا في الوقت نفسه لصق الملصقات للبحث المريح عن PRs من خلال واجهة Github.
الشيء الثاني الذي لاحظوه: البريد ليس أفضل أداة للإبلاغ بسرعة عن حالة مراجعات الشفرة. كثير ، حتى لا يصرف انتباهه عن العمل ، يحلل بريده عدة مرات في اليوم. الرسل مسألة مختلفة تمامًا. رد الفعل على الرسائل في الرسل أعلى بكثير. وتقرر ربط البوت برسولنا. يرسل البوت تنبيهات حول حالة مراجعة الكود لكل من مؤلف طلب السحب ويشجع الأشخاص على المراجعة. مريح للغاية.
الخطوة 4. أولا اتفاقية مستوى الخدمة
بالتوازي مع الإجراءين 2 و 3 ، بدأنا العمل عن كثب مع الموظفين وشرح أن مراجعة الشفرة لا يمكن فصلها عن المهمة نفسها. وأوضحوا أن جلب "التحقق" هو مسؤولية المطور. علاوة على ذلك ، لا تقتصر المسؤولية على الزملاء فحسب ، ولكن أيضًا على المستخدمين! تسليم الميزات بسرعة إلى المبيعات - هذا ما أردت تحقيقه. وكان الفريق متعاطفًا مع عملية التحسين.
في هذه المرحلة ، ولدت الفكرة الأولى لمراجعة الكود المثالي. بالطبع ، يريد الجميع أن يتم ذلك في غضون 5 دقائق ، ولكن هذا ليس ممكنًا دائمًا. مع الأخذ في الاعتبار أن لدينا فريق متعدد المناطق (بفارق زمني أربع ساعات) ، اتفقنا على أن اتفاقية مستوى الخدمة لدينا ستكون يومًا واحدًا ، أي 24 ساعة تم الإعلان عن اتفاقية مستوى الخدمة هذه لجميع الموظفين ، وبدأوا في انتظار النتائج ، بفرك أيديهم.
لكن الوضع لم يتغير. في أفضل الأسابيع ، يتناسب نصف طلبات السحب مع يوم واحد. حصل الباقي عليه.
كان لدينا نص برمجي صغير قام بتقييم مراجعة رمز الوقت على العلاقات العامة. بدأنا نلومهم على أساس يومي على جميع المستفيدين الرئيسيين بحثًا عن "التخلف". كل يوم تقريبا كان هناك علبة من هذا القبيل.
لقد استغرق تحليلها وقتًا طويلاً. في معظم الأحيان ، يحسب النص نفسه وقت المراجعة بشكل غير أمين. لم يأخذ في الاعتبار أن بعض المستفيدين الرئيسيين تم إنشاؤهم خارج ساعات العمل (نعم ، بعض الأشخاص المهرة الشجعان يحبون العمل لمدة ساعة أو ساعتين في الليل ، يأتون إلينا للعمل!). كل هذا أخبرنا أن أدوات مراقبة طلبات السحب لدينا ليست الأكثر فعالية ، لأنها غير نزيهة. يجب أن أجد أدوات جديدة.
الخطوة 5. SLA Tracker
جاءت المساعدة من حيث لم ينتظروا. أعلن زملاؤنا من Tracker عن شيء مدهش: الآن يمكنك تثبيت SLA في Tracker نفسه. علاوة على ذلك ، يمكنك تكوينه بشكل مختلف تمامًا. يتم تشغيل مؤقت معين بواسطة حدث ما في المهمة. لبعض الأحداث ، يمكن أن يتوقف. وتوقف عند حدث ما. نعم ، هذا ما نحتاجه!
لقد دخلوا على الفور في دراسة تفصيلية للتوثيق (بالمناسبة ، ها هو ) وأقاموا قوائم الانتظار لدينا (هناك العديد منها ، نظرًا لوجود العديد من المستودعات). قمنا بتعيين المؤقت ليتم تشغيله عند التبديل إلى حالة "الحاجة إلى مراجعة الرمز" وينتهي عندما يتحول إلى أي حالة أخرى باستثناء "هناك تعليقات" - عندما يذهب ، يتوقف المؤقت مؤقتًا ، أي لم يفقد وقته.
كان من الرائع أيضًا أن المؤقت أخذ في الاعتبار ساعات العمل والتقويم! لقد وضعنا أن 9h يتم تعيينه لمراجعة الكود ، أي يوم عمل واحد. في هذه الحالة ، يتم تشغيل تنبيه لمدة ساعتين بعد البداية ، أو إذا تم تعطيل مهلة تسع ساعات. وكانت النتيجة نوعًا من المراقبة الصادقة. في البداية ، قمنا بتشغيل المؤقت من أجل التجربة ، وجمعنا مجموعة من الأخطاء وقمنا بتصديرها إلى Tracker.
من الجدير بالذكر أنه تم تمكين المؤقت فقط للمهام التي تم إنشاؤها بعد تنفيذ المؤقت نفسه. لذلك ، لا يمكن رؤية التأثير الفوري. ولكن في هذه المرحلة ، بدأت ديناميكيات إيجابية. حصلنا على التأثير بعد شهر ، عندما بدأ تدفق التذاكر الجديدة مع جهاز توقيت في مزاحمة التذاكر القديمة. كان من الملاحظ أن الوقت التقريبي لمراجعة الرمز تم تركيزه في منطقة رسائل التذكير ، أي يشير إلى ساعتين و 9 ساعات.
في وقت كتابة هذه السطور ، كان لدينا 415 مهمة بدأ فيها المؤقت. ومن بين هؤلاء ، تجاوزت الحدود 29 ساعة. على الرغم من ذلك ، إذا ألقيت نظرة فاحصة ، فستواجه أيضًا مثل هذه المهام ، التي تم الانتهاء من مراجعة التعليمات البرمجية الخاصة بها في غضون الساعة التالية. إذا تجاهلناها أيضًا ، فستبقى 17 مهمة. وهذا حوالي 4.1٪!
النتيجة. الساموراي يشحذ سيفه باستمرار
إذا نظرنا إلى الوراء ونذكر جميع أفعالنا ، يمكن استخلاص نتيجة واحدة - جميع الوسائل جيدة. أدت جميع خطواتنا إلى النتيجة المرجوة: أكثر من 92٪ من طلبات السحب بدأت في تلبية اتفاقية مستوى الخدمة لدينا ! مهام أقل وأقل ممزقة ، مراجعة الكود أسرع. ببطء ، شيئًا فشيئًا ، بدأت 75٪ من مراجعة الرمز تتناسب مع 5 ساعات ! ولا تزال ديناميكيات التحسين إيجابية. بالإضافة إلى المؤشرات الرقمية ، بدأنا في تلقي المزيد من التعليقات الإيجابية من المقاولين من الباطن. أكثر سرورا بحقيقة أن الفريق رد على هذه العملية برمتها. حتى عملية مثل تسريع مراجعة التعليمات البرمجية حشد الفريق أكثر. بدأ كل مشارك في فهم المسؤولية التي يتحملها قبل الآخرين ، حيث تسمح لنا شفرة المراجعة السريعة بإفادة المستخدمين بشكل أسرع.
بالطبع 9h ليس الحلم النهائي ، لكنه لا يزال النجاح. ولكننا لا ننوي التوقف عن ذلك. نواصل مراقبة عملية مراجعة التعليمات البرمجية وحل جميع المشاكل الفنية وحتى النفسية التي يواجهها الموظفون بحيث تكون عمليتنا منتجة قدر الإمكان وفي نفس الوقت مريحة للفريق.
سؤال وجواب. ماذا لو ...؟
س : ماذا لو اعتقدت أنهم يراقبونني؟ ما هذا الموقت؟
ج : نحن نراقب ليس على وجه التحديد لشخص ما ، ولكن من أجل العملية. هناك جانبان لطلب السحب: المؤلف والمراجعون. إذا سحب المراجعون الشيك ، فسيعاني المؤلف. من ناحية أخرى ، من غير الإنساني أيضًا تمزيق المفتشين من العمل على الفور. من الضروري إيجاد توازن حتى يكون كلا الجانبين مرتاحين. المؤقت ليس مطلوبًا لمعاقبة شخص ما ، ولكن لتسجيل جميع الانحرافات. لا تحدث معظم هذه الانحرافات من خلال خطأ المراجعين ، ولكن من خلال خطأ المشاكل التقنية. التحدي هو إصلاح هذه المشاكل. حتى لا يصادفهم الآخرون. التحسين الذاتي المستمر
س : وماذا إذا كان هناك علاقات عامة معقدة ، وأكثر من 100500 سطر من التعليمات البرمجية ، وهناك "تغيير الحرف". أين العدل؟
ج : نعم ، هذا صحيح. عندما كنا نعمل على مراجعة الكود القياسي ، أخذناها على طول الحد العلوي ، أي يجب أن تتناسب مراجعة التعليمات البرمجية للعلاقات العامة المعقدة مع اتفاقية مستوى الخدمة. لكن في الوقت نفسه ، ليس لدينا هدف لدفع الجميع إلى هذه الحدود. نحن متعاطفون دائمًا مع سحب الطلبات ، حيث توجد مناقشة حية ومفيدة ، على الرغم من العائق المكسور في يوم واحد.
لدينا خطط لدرجات جيش تحرير السودان في نقاط القصة. 1SP - 1h ، 3SP - 5h ، 5SP - 2d ، على سبيل المثال. لحسن الحظ ، فإن Tracker قادر بالفعل على ذلك. نحن لسنا مستعدين لهذا بعد - لا يزال أمامنا طريق طويل لنقطعه.