كيف ولماذا نعلم غير المهندسين استخدام جيثب في الموضوع

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

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

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

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

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

حل أفضل

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

في مؤشر الترابط ، نقوم الآن بتعليم الأشخاص خارج الفريق الهندسي بانتظام كيفية المساهمة في قاعدة بياناتنا من خلال واجهة ويب GitHub ، بحيث يتحكمون في تحديث البيانات التي يحتاجون إليها للعمل بفعالية.

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

هل عملت؟

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

لا يقتصر أيضًا على ملفات البيانات ؛ العديد من الصفحات على thread.com هي لغة HTML ثابتة بشكل أساسي أو صفحات مثل الأسئلة الشائعة الخاصة بالتسليم أو سياسة الإرجاع أو الشروط والأحكام. من خلال تعلم كيفية استخدام GitHub ، يمكن لفريق العمليات لدينا الحفاظ على تحديثها دون طلب المساعدة. يمكن لفريق المواهب لدينا أيضًا تعديل موقع وظائفنا ، والرد بشكل يومي على الأسئلة الشائعة التي تطرح عند التحدث إلى المرشحين.

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

كيف لنا أن نفعل ذلك؟

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

بعد ذلك ، سنتعرف على كيفية تحرير ملف على واجهة ويب GitHub ، وكيفية كتابة رسالة التزام ، ما هو طلب السحب ، وماذا تعني حالة البناء من Jenkins.

أخيرًا ، نطلب من المساهمين غير التقنيين اختيار مهندس متاح في Slack لضرب زر الدمج بمجرد أن تصبح البنية خضراء.

المشكلات التي واجهناها

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

أولاً ، لقد استخدمنا أدوار GitHub والفروع المقفلة لمنع ارتكاب عمليات عرضية لإتقانها. بالنسبة إلى شخص ليس على دراية بالتحكم في الإصدار والفروع على وجه الخصوص ، فإن واجهة الويب لـ GitHub ليست واضحة بشكل خاص فيما يتعلق بموعد الالتزام بالفرع الرئيسي أو الفرع الجديد. في Thread ، يتم نشر فرعنا الرئيسي بشكل مستمر دون تدخل يدوي ، مما أدى إلى خروج العديد من الالتزامات التي كسرت الموقع وتسببت في التوقف.

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

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

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

تحرك للأمام

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

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

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