عندما تمت مشاركة الكود الخاص بك: القصة من البداية إلى النهاية

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



في هذه الأثناء ، خلف الجدار حرفيًا ، يعيد فريق يُدعى "Cedar Beavers" توزيع الطلبات فيما بينهم بحيث ينخفض ​​العبء على مشاهدتها بشكل متساوٍ تقريبًا. نعم ، فهم لا يتعاملون مع مكتبة Doomsday ، لكنهم يقومون بمهام أخرى تتطلب تغييرات سريعة في التعليمات البرمجية وعمليات أسرع.



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



إذن أين ذهبنا في Wrike؟

ما هي الخيارات التي اخترناها لطريقتنا الخاصة لامتلاك الكود؟

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



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



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



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



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



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

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



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



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



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



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



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



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



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



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



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



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



نحن نستخدم GitLab ، لذلك سيكون من المنطقي أن ننظر إلى مالكي كود GitLab. لكن مبدأ تشغيل هذه الأداة لم يناسبنا: وظيفة GitLab هي مجموعة من المسارات في المستودع (الملفات والمجلدات) والأشخاص من خلال حساباتهم في GitLab. هذه الحزمة مكتوبة في ملف خاص - codeowners.md. كنا بحاجة إلى مجموعة من المسارات والميزات. علاوة على ذلك ، توجد ميزاتنا في قاموس خاص ، حيث يتم تخصيصها للأمر. يتيح لك هذا ترميز الميزات المعقدة التي قد توجد في أكثر من مستودع واحد ، والتي يتم تطويرها بواسطة عدة فرق ، ومرة ​​أخرى ، لا يتم ربطها بأسماء محددة. بالإضافة إلى ذلك ، كان لدينا خطط لاستخدام هذه المعلومات لإنشاء دليل مناسب للفرق والميزات ذات الصلة وجميع أعضاء الفريق.



نتيجة لذلك ، قررنا إنشاء نظام التحكم في ملكية الكود الخاص بنا. استند تنفيذ الإصدار الأول من نظامنا إلى قدرات Dart SDK ، لأنه تم إطلاقه في البداية لمستودعات قسم الواجهة الأمامية ولملفات Dart فقط. استخدمنا العلامات الوصفية الخاصة بنا (لحسن الحظ ، يتم دعم هذا على مستوى اللغة) ، ثم قمنا بتشغيل جميع الملفات المصدر باستخدام محلل ثابت وصنعنا شيئًا مثل الجدول: ملف / ميزة - أمر المالك. يمكنك ترميز كل من الملفات الفردية والمسارات بأكملها بعدة مجلدات.



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



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



من خلال النقر فوق الأمر ، يمكنك رؤية جميع الميزات ، وجميع أعضاء الفريق ، والميزات التقنية البحتة وأيها منتج



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



من بين العيوب الحاجة إلى مراقبة ترميز الميزات عن كثب عند إعادة بناء التعليمات البرمجية ونقلها من مكان إلى آخر ، والحاجة إلى طاقة إضافية لجمع كل المعلومات حول الترميز.



كيف تحل مشكلة امتلاك الكود الخاص بك؟ وهل هناك مشاكل ذات صلة ، والأهم من ذلك ، حلها؟