مرحباً بالجميع ، هذه ديما فدوفين مرة أخرى. في مقالتي السابقة حول دمج Juns في فريق ، تطرقت لفترة وجيزة إلى البرمجة الزوجية كممارسة تعليم وتعلم فعالة. الآن أود أن أتحدث بمزيد من التفصيل عن ممارسة البرمجة الزوجية في فرق. لقد جربت أشكالًا مختلفة منها في مشاريع مختلفة ، واليوم أود فقط مشاركة ما أراه في هذا على أنه مزايا هذا النهج.
برمجة الزوج
يبدو لي أنه فقط لشرح كيفية عمل البرمجة الزوجية ، يمكننا أن نأخذ مثال سباقات الرالي. يوجد سائق (سائق) وملاح (ملاح). يركز السائق بشكل مباشر على القيادة. يتحكم الملاح في المكان الذي نذهب إليه الآن ويخبر الطيار عن المنعطفات والقفزات القادمة.
إنه نفس الشيء في البرمجة الزوجية.
يركز السائق على كتابة الكود هنا والآن. في هذا الوقت ، يحمل الملاح الصورة كاملة أمامه ، ويتحقق من أن السائق لا يرتكب أخطاء ، ويخبرنا أين وكيف يتحرك.
الاختلاف الرئيسي الوحيد عن سباقات الرالي هو أنه في البرمجة الزوجية ، يجب على السائق ومساعده تغيير الأماكن بشكل دوري. يتزامن توزيع الوظائف بشكل كامل تقريبًا.
إن الدمج الكامل لكلا المشاركين في البرمجة الزوجية في العملية هو ما يميز هذه الطريقة عن طرق التعلم والتحكم الأخرى. من ناحية أخرى ، لا نسمح للسائق بكتابة الكود بشكل مستقل تمامًا ولا نعطي "المنتج" النهائي لمراجعته من قبل الملاح الشرطي. في الوقت نفسه ، لا يركز السائق فقط على سطور معينة من التعليمات البرمجية ، ولكن يجب أن يرى المنطقة التي ينشئها من منظور واسع. الأمر نفسه ينطبق على الملاح لدينا.
بالإضافة إلى نظام البرمجة الزوجية الكلاسيكي هذا ، تم إنشاء العديد من الأساليب الأكثر فاعلية على مدار سنوات وجود الصناعة. على سبيل المثال ، يعتبر أسلوب تنس الطاولة أو ملاح المقعد الخلفي شائعًا. يمارس بعض الناس بشكل عام مزج تقنيات مختلفة. هذا امر طبيعي. تعتمد فعالية هذه الطريقة أو تلك على الأهداف وتكوين المشاركين: من يشارك في الزوج ، وما الذي يريدون تحقيقه ، ومدى خبرة كلا المبرمجين. بالمناسبة ، البرمجة الزوجية قابلة للتطبيق تمامًا ليس فقط في الزوجين الناشئين والمرشدين ، والذي تحدثت عنه في المقالة الأخيرة ، ولكن أيضًا في زوج من المبرمجين ذوي الخبرة من نفس المستوى تقريبًا.
بعد ذلك ، دعنا نناقش خيارات إعداد برنامج التشغيل + الملاح على نطاق أوسع ، اعتمادًا على أهداف البرمجة الزوجية.
تدريب المبتدئين
تعتبر البرمجة الزوجية رائعة لتعليم المبتدئين وغالبًا ما تستخدم لهذا الغرض. ومع ذلك ، عند استخدام طريقة التدريب هذه ، يجب أن تفهم أنك تضحي بسرعة تطوير الميزة الفورية إذا تم التطوير في جزء حقيقي من التعليمات البرمجية. في الوقت نفسه ، يفوز الفريق بجدية على المدى الطويل: البرمجة الزوجية مع زميل ذي خبرة تزيد بشكل كبير من سرعة الانضمام وتعلم يونيو.
ولكن في سياق حالة "تدريب المبتدئين" ، لا يظهر شهر يونيو دائمًا. على سبيل المثال ، يمكن استخدام البرمجة الزوجية لتهيئة وسيط تم تعيينه حديثًا شرطيًا يحتاج إلى الالتحاق بسرعة بالمشروع. في هذه الحالة ، لا تنخفض السرعة كثيرًا ، ويمكن للموجه أن يكون زميلًا يمكن مقارنته بالوافد الجديد في المشروع من حيث مستوى المهارة. نحن هنا نتحدث بالفعل عن نقل الخبرة والمعرفة ليس في البرمجة ، ولكن على وجه التحديد المعرفة حول مشروع معين.
من ناحية أخرى ، يعد الترميز في زوج من اثنين في المنتصف أكثر خطورة قليلاً من زوج من يونيو + الأوسط أو يونيو + Signor. يجب على القائد في زوج من الوسطين التعامل مع العملية بمسؤولية كبيرة ، ولكن إذا تم استيفاء جميع الشروط ، فإن الفوائد التي تعود على الفريق بأكمله تكون ملموسة تمامًا.
تقاسم المعرفة وتصفية "البرج"
من المشاكل الشائعة للعديد من الفرق توافر متخصصين لا يمكن تعويضهم. ينطبق هذا غالبًا على الشركات الناشئة أو المجموعات الصغيرة المعزولة من المطورين الذين رأوا بأنفسهم بهدوء بعض الميزات أو مشروعًا منفصلًا. المتخصص الذي لا يمكن الاستغناء عنه هو الشخص الذي يفهم تمامًا وبشكل فردي إما قسمًا معينًا من الكود / المشروع ، أو لديه فقط فهم كامل لكيفية عمل كل شيء. يُطلق على حوض المعرفة حول مشروع هذا الاختصاصي أيضًا "برج المعرفة".
المتخصص الذي لا يمكن الاستغناء عنه أو "البرج" هو عنق زجاجة خطير يجب تجنبه بأي وسيلة. بسبب إجازة مرضية عادية أثناء دمج ميزات جديدة في الجزء القتالي من المشروع (أو أثناء التنقل ، أو في مرحلة أخرى خطيرة) - وعمل الفريق مشلول. ناهيك عن طرد هؤلاء المطورين.
للقضاء على مثل هذا الاختناق ، يجب على المتخصصين الذين لا غنى عنهم مشاركة معرفتهم مع المطورين الآخرين.
كما هو واضح بالفعل ، تعد البرمجة الزوجية رائعة مرة أخرى لمشاركة المعرفة. فقط في هذه الحالة ، لا نتلقى تدريبًا متقدمًا وإلحاقًا بالمبتدئين ، بل يتم نقل المعرفة حول جوانب المشروع داخل الفريق نفسه. إذا قمت بعمل ميزة في زوج ، فعندئذٍ سيعرف شخصان على الأقل عنها بالفعل ، بالإضافة إلى أنه أثناء عملية الكتابة ، سيتم تشديد خلفية أحد أعضاء الزوج.
إن تصفية "برج المعرفة" لها ميزة أخرى ليست واضحة للكثيرين. بالإضافة إلى لامركزية المعرفة حول ميزات ومناطق محددة للمشروع ، فإننا أيضًا نخفف العبء على المطور ، الذي تم بناء هذا "البرج" حوله في الأصل. في الواقع ، في كثير من الأحيان ، إذا كان لدى الفريق متخصص لا يمكن الاستغناء عنه ، فغالبًا ما يتعين عليه العمل في وضع البلى ، مع العمل الإضافي ، سبعة أيام في الأسبوع أثناء الإصدارات ، وبشكل عام ، يكون متاحًا على مدار الساعة طوال أيام الأسبوع. كل هذا الضغط المستمر يؤدي عاجلاً أم آجلاً إلى الإرهاق المهني أو ، في أحسن الأحوال ، الرغبة في العثور على وظيفة أكثر هدوءًا.
يعد استخدام البرمجة الزوجية بشكل استباقي أيضًا طريقة رائعة لتجنب إنشاء أبراج المعرفة من اللون الأزرق. إن التداول المستمر للمعرفة حول الميزات والأجزاء المختلفة من المشروع داخل الفريق هو عملية عادية ، والتي ، للأسف ، تبدأ في التنظيم فقط في لحظة إقالة موظف رئيسي. صحيح أن البرمجة الزوجية ليست الطريقة الوحيدة للتعامل مع "الأبراج" وزيادة مستوى فهم المشروع داخل الفريق ، ولكن هذه قصة مختلفة تمامًا.
حل المشكلات المعقدة
يمكن استخدام البرمجة الزوجية كأداة عصف ذهني محلية ، أي تطبيق القول الحرفي "رأس واحد جيد ، ورأسان أفضل". تعد البرمجة الزوجية رائعة عندما تحتاج إلى تنفيذ ميزة أو منطق معقد وفقًا لمتطلبات العمل الخاصة بالمشروع. لم نعد نتحدث هنا عن نقل المعرفة من القائد إلى التابع ، ولكننا نخلق نظامًا من مطورين ، متساويين في الخبرة وفهم المشروع ، يجمعان جهودهما.
قد يجادل بعض المطورين بأنهم أكثر راحة في العمل في مناطق معقدة فقط ، لكن الممارسة تُظهر أن اثنين من المبرمجين الأقوياء في زوج من المرجح أن ينتجا كودًا عالي الجودة أكثر من العمل بشكل منفصل.
نقاط القوة في البرمجة الزوجية في مثل هذه المواقف خارج عملية الترميز. بدلاً من ذلك ، يتم تحقيق المكسب من خلال القدرة على مناقشة الحلول الممكنة للمشكلة بنشاط على قدم المساواة - عملية كتابة التعليمات البرمجية في مثل هذه الحالة ثانوية وليست مشكلة. لكن كيف وماذا يجب أن يكتب بالضبط هو المشكلة. إن إمكانية الاتصال المباشر والمناقشة والنزاع المبرر بين اثنين من المتخصصين لها تأثير إيجابي على جودة القرارات المتخذة. يتم أيضًا تقليل الوقت اللازم لإيجاد حل ناجح لمشكلتنا.
مهام مختلطة
الحالة الأخيرة هي فريق من جميع الحالات المذكورة أعلاه. هنا لدينا مطوران من ذوي الخبرة في مجالات مختلفة من الخبرة ، الذين يتحدون للعمل في مهمة واحدة. ربما يكون أحدهما جيدًا في كتابة التعليمات البرمجية ، والآخر على دراية كاملة بمتطلبات المشروع. علاوة على ذلك ، ليس من الضروري أن يكون هذان المبرمجان. يمكن أن تكون هذه أزواج من المبرمج ومهندس ضمان الجودة أو المبرمج والمحلل.
هنا نحصل على موقف يربح فيه الجميع: في حالة المشكلات المختلطة ، يكمل كل عضو في الزوج الآخر. هذه هي الطريقة التي نستخدم بها أقصى استفادة من إمكانات كلا المتخصصين ، والقضاء على نقاط ضعفهم واستخدام نقاط قوتهم فقط.
في الوقت نفسه ، يغطي حل المشكلات المختلطة جميع الحالات الموصوفة سابقًا: الإعداد ، إذا كنا نتحدث عن عدم كفاية المعرفة بمتطلبات المشروع ، وتصفية "البرج" ، وحل حالة معقدة.
مجموع
من المهم أن نفهم أن البرمجة الزوجية ليست حل سحري وإجابة لأي مشكلة أو تحدٍ في التنمية. في جميع الحالات تقريبًا ، تؤدي هذه الطريقة إلى انخفاض في سرعة التطوير ، لذلك يجدر استخدام هذا الأسلوب بحذر.
أيضًا ، يجب ألا ننسى العامل البشري: إذا كنا نتحدث عن تعليم Jun ، فيجب أن يكون المرشد الثنائي قادرًا على التفاعل مع المبتدئ على المستوى المناسب حتى لا تتحول عملية التعلم إلى ضرب وسخرية. إذا كنا نحاول تصفية "البرج" ، فيجب أن يكون تكوين الزوج متطابقًا بشكل مناسب بحيث يتم نقل المعرفة في الاتجاه الصحيح. الأمر نفسه ينطبق على المشاكل المعقدة والمختلطة: لا يمكنك وضع مطورين عشوائيين على جهاز كمبيوتر واحد والانتظار ، سيعطونك حلاً جاهزًا في غضون N من الساعات.
ولكن حتى مع الصعوبات التي تم التعبير عنها ، تعد البرمجة الزوجية ممارسة رائعة لا تحل فقط مشكلة إعداد وتعليم الوافدين الجدد ، ولكنها تتيح لك أيضًا سد الفجوات المعرفية في مشروع أعضاء الفريق الآخرين أو حل مشكلة معقدة بشكل فعال.