من السهل الحفاظ على ثقافة الشركات في الكلمات. ومع ذلك ، هناك عدد قليل فقط من الشركات التي تستكشف بنشاط ميزات قليلة من ثقافة الشركات التي لها تأثير كبير على الإنتاجية - لأن هذا هو الأكثر صعوبة.
بالنسبة لفرق البرمجيات ، تعد ملكية الكود بمثابة مؤشر رئيسي لرفاهية الهندسة. في هذا الدليل العملي ، سوف نحلل بالضبط كيفية دمج هذا المبدأ في العمل اليومي لفريق التطوير الخاص بك ، بحيث يتم الحفاظ على رفاهية قاعدة الكود الخاصة بك بنفسها.
كنت محظوظًا بما يكفي للقاء بعض من أفضل المطورين في العالم - في Stepsize أعمل معهم كل يوم. وأثناء المناقشات حول كيفية إنشاء الديون الفنية ، مع كبار المطورين لشركات مثل Skyscanner و Spotify و Palantir وغيرها ، يتم طرح سؤال واحد دائمًا: الملكية.
من خلال التفاعل الوثيق بين الفرق السريعة (جيدًا ، في الفرق الحديثة) ، حيث يمكن للمطورين الالتزام بأي جزء من قاعدة الشفرة ، يتم تشويش الكود بسهولة ويصبح وحشًا مشابهًا لفرانكشتاين. وعندما تسوء الأمور بما فيه الكفاية ، يجب أن يتدخل شخص ما ، مثل الكابتن مارفيل ، ويصلح كل شيء مع إعادة هيكلة كبيرة واحدة.
لتجنب هذا الموقف ، تحاول فرق التطوير الالتزام بأحد النصائح العديدة التي قدمها روبرت س. مارتن ("العم بوب") ، وهي " قواعد الكشفية للأولاد ": الحفاظ على الشفرة في حالة أفضل مما كانت عليه من قبل . فيما يلي امتداد مجاني لـ VSCode لمساعدتك في جعل ذلك أسهل كثيرًا .
ومع ذلك ، على الرغم من مستوى المهارة وأفضل الحوافز للمطورين ، يبدو أن القانون الثابت لتطوير البرمجيات هو أن الدين التقني يتراكم - حتى يصبح أكثر من اللازم ، ومن ثم يتعين علينا تخصيص وقت للكثير من إعادة البناء. . لقد كنا مترددين في قبول هذا كجزء من دورة حياة تطوير البرمجيات.
ربما يأتي كل ذلك بسبب عدم الانضباط؟
لذلك فكرت من قبل. ثم قابلت غاريث فيزاجي ، كبير المهندسين في Snyk.io ، وضربني بالعبارة التالية:
الملكية هي المؤشر الرئيسي للرفاهية الهندسية.
ماذا كان يقصد؟ وكيف يمكن أن يجعل مثل هذا البيان؟
هناك قدر كبير من الأبحاث التي تظهر أنه عندما يمتلك أعضاء الفريق ثمار عملهم ، ويكونون مسؤولين عنهم للمديرين ويتحملون المسؤولية عن النجاحات والإخفاقات ، تبدأ كل أنواع الأشياء الجيدة في الحدوث.
لسوء الحظ ، تحقيق ذلك في الممارسة العملية ليس بالأمر السهل. جزئيًا لأنه ، على ما يبدو ، لا يمكن قياس الإنتاجية الهندسية ، ويمكن النظر إلى ممارسات التطوير الحديثة على أنها تشجع على ملكية الأكواد الرديئة في أي ظرف من الظروف. الحقيقة هي أنه حتى الآن كان من الصعب للغاية قياس الملكية في فرق التطوير بشكل صحيح ... لذلك لم نكن نعرف حتى كيف "جيدة" بحثت عن هذا المؤشر.
لحسن الحظ ، أظهرت الأبحاث العلمية الحديثة أن ملكية الشفرة - وهي أفضل مقياس غير مباشر لفكرة "الملكية" الغامضة في فرق التطوير - يمكن قياسها من خلال نشاط Git الالتزام. وهذا مؤشر رئيسي رائع لرفاهية قاعدة الكود.
هذه الأجزاء من قاعدة الكود التي يقوم العديد من المطورين بإجراء تغييرات عليها يتم تشويشها بمرور الوقت ، وتلك الأجزاء التي يعمل بها عدد أقل من الأشخاص تكون في حالة أفضل. لا تأخذ كلامي على ذلك - لقد قام أشخاص جيدون من Microsoft بدراسة هذا من خلال مثالهم الخاص.
المصدر: دراسة مايكروسوفت
كاد أسمع بعضًا منكم يصرخون بأنك لا تريد موقفًا يكون فيه مطور واحد فقط هو الشخص الوحيد المسموح له بلمس أي جزء من التعليمات البرمجية - لهذا النهج آثار جانبية فظيعة. أنا أفهمك ، وهذا ليس ما نقدمه.
اسمع لي حتى النهاية.
هناك أشكال مختلفة من ملكية الرمز مناسبة لظروف مختلفة.
الملكية الجماعية ونقص الملكية
الملكية الجماعية هي [...] ملكية تكون فيها الشفرة مملوكة بشكل مشترك ، لكن المسؤوليات والجداول الزمنية محددة بوضوح. يمكن لكل عضو في الفريق العمل على أي نظام فرعي أو خدمة ، إذا لزم الأمر.
عدم الملكية - [...] هو الموقف الذي يقوم فيه العديد من المطورين بإجراء تغييرات على نفس النظام الفرعي ، ولكن تنسيق الإجراءات أو مسؤولية الجودة أو التواصل داخل الفريق هو الحد الأدنى. في مثل هذه الأنظمة ، لا ينبغي للمرء أن يتوقع عملًا عالي الجودة.
المصدر: دراسة مايكروسوفت
يمكنك متابعة هذا القسم بشكل أكبر عن طريق إضافة الكود غير المالك والملكية الوحيدة أيضًا إلى الكومة ، لكنني لا أريد تفويت الشيء الرئيسي ، لذلك يوجد رسم بياني يوضح مجموعة أشكال ملكية الكود:
يجب أن تكون الملكية الجماعية هي خيارك الافتراضي وشكل الملكية الذي يجب أن تسعى إليه. لاحظ أن هذا لا يعني أن مطورًا واحدًا فقط في فريقك لديه إذن لتغيير الرمز ، أو أن أي تعديل للرمز يتطلب موافقته. هذا يعني فقط أنه من الواضح تمامًا لكل فرد في الفريق الذي يجب أن يناقش معه أي أسئلة لديه ، وأن مالك الكود على الأرجح سيتعامل مع مراجعة الكود (مراجعة الكود). سيسمح هذا لكل فرد في الفريق بتحسين معايير كتابة التعليمات البرمجية والتعرف على كيفية تعديل التعليمات البرمجية الخاصة بهم.
المالك مسؤول عن حالة الكود الخاص به ، ويجب على المديرين أن يطلبوا منه ذلك. هذا لا يعني أنه يحتاج إلى الضرب على رأسه لكل خلل تسرب إلى كوده ؛ هذا يعني أنه يحق للمالكين اتخاذ القرارات المتعلقة بجودة الكود والدين الفني ؛ سيتم مساءلتهم عن هذه القرارات من خلال مقاييس داعمة إضافية ، مثل التماسك ونشاط التكرار (التغيير) (لمزيد من التفاصيل ، راجع مقالتنا حول مقاييس الديون الفنية ).
إن قلة الملكية ، أو الملكية الضعيفة ، هي عكس الملكية الجماعية ، وفي معظم الحالات يجب تجنب هذا الشكل من الملكية. كما ذكرنا بالفعل (وقد يبدو هذا واضحًا) لملفات مثل package.json عدم وجود مالك محدد بوضوح هو موقف طبيعي. الذهاب إلى أقصى الحدود ليست ضرورية.
رمز اليتيم
أكثر أنواع عدم الملكية سوءًا ، أحد أطراف طيف أشكال الملكية للرمز. أنت بالتأكيد لا تحتاج إلى هذا الشكل من الملكية. تجنب ذلك بأي ثمن ... ما لم يكن ، بالطبع ، رمزًا لن تلمسه أبدًا. لكن هذا الرمز نادر جدا.
يعتبر الرمز بدون مالك إذا توقف المطور الرئيسي عن إجراء أي تغييرات على قاعدة التعليمات البرمجية. ربما غادر المنظمة ، أو ربما انتقل من المطورين إلى المديرين. في أي حال ، لديك مشاكل خطيرة - وقاعدة التعليمات البرمجية الخاصة بك أيضا.
ومع ذلك ، هناك حل. تحتاج إلى ترجمة التعليمات البرمجية المصدر إلى أي شكل آخر من أشكال الملكية الأكثر ملاءمة لذلك. لتجنب ظهور أي كود بدون مالك في قاعدة الشفرة الخاصة بك ، تأكد من أن خططك الخاصة بحالة الفصل أو الإحالة من الحالات تتضمن إدخال مالكيها الجدد في سياق شؤون مالكها القديم. يمكنك تسهيل الأمر عن طريق تعيينهم تلقائيًا لعرض طلبات السحب الخاصة بتغييرات التعليمات البرمجية. في حالة عدم وجود مثل هذا ، يمكنك ببساطة تعيين مالكي الرمز كما تراه مناسبًا.
بغض النظر عن الطريقة التي تختارها ، لا تترك الكود بدون مالك معلقًا في قاعدة الكود. أنت لا تعرف أبدا ما الذي سيحدث له إذا تركته تحت رحمة القدر.
الملكية الوحيدة (الملكية المطلقة)
هذا هو الطرف الآخر من طيف ملكية الشفرة. معه ، يمكن أن يكون كل شيء رائعًا وصعبًا للغاية.
يعتبر الرمز في ملكية فردية عندما يكون المالك هو المطور الوحيد الذي يمكنه إجراء تغييرات على الكود أو الموافقة عليها ، أو عندما يكون المالك ، في جوهره ، هو الشخص الوحيد الذي قام بإجراء تغييرات على الكود في الماضي.
الشركات الناشئة الصغيرة غالبا ما تأتي عبر ممارسات مماثلة في عملها. كل مطور ، كقاعدة عامة ، مسؤول عن السجل الكامل لملف واحد ، ومن المتوقع أن يتم الاحتفاظ بملكية هذا الملف. هذه ليست نهاية العالم ؛ الشركات الناشئة ، بعد كل شيء ، لديها موارد محدودة ، وتحتاج إلى تقديم تضحيات معينة. ولكن إذا قام المطور يومًا بنقل الحافلة ، فسيكون هذا الجزء من الشفرة بدون مالك. لمثل هذه الحالات ، يجب أن يكون لديك خطة احتياطية.
في المؤسسات الهندسية الأكبر ، يمكن أن يكون " عامل النقل " المنخفض مشكلة حقيقية ، خاصة عندما يتعلق الأمر بالأجزاء المهمة من قاعدة الشفرة ، ويكون معدل دوران الموظفين مرتفعًا ، والديون الفنية التي تجندها الشركة كبيرة جدًا. على سبيل المثال ، إذا تركت مطورًا قام بفشل نظام الدفع الذي تمت تهيئته يدويًا بالكامل ، فستتلقى صداعًا كبيرًا - في حال كنت تريد تغيير نموذج التسعير الخاص بك ، أو إذا وجدت خللًا في قاعدة الكود الخاصة به يؤدي بك إلى لعدة أشهر ، تلقوا أموالًا أقل من أكبر عملائهم. ثم سيحتاج أي شخص للالتقاء ومحاولة فهم الرمز لإجراء تغييرات عليه ، أو سيتعين عليك إعلان إفلاسها الفني على نظام الدفع الخاص بك وإعادة كتابته من نقطة الصفر (ولكن قبل القيام بذلك ، يرجى قراءة هذا ).
لا تدع هذا يحدث لك.
ومع ذلك ، هناك أوقات تكون فيها الملكية الوحيدة للرمز مقبولة أو حتى موصى بها. قد ترغب في إثبات هذا الشكل من الملكية لأجزاء قاعدة الشفرة التي يمكن من خلالها البيان "إذا تعطل هذا الجزء ، فيمكننا طي ذلك ، لأن العمل لن يكون قادرًا على دفع رواتبنا أو سنذهب إلى السجن".
في مثل هذه الحالات ، حتى إذا كنت ترغب في نشر المعرفة حول الجزء الحرج من الشفرة بين العديد من المطورين من أجل الحفاظ على عامل ناقل مرتفع بما فيه الكفاية ، فقد تحتاج أيضًا إلى وضع قواعد تحظر حقن طلبات السحب دون موافقة المالك الوحيد للرمز المقابل.
النتائج
ابحث عن الملكية الجماعية للغالبية العظمى من الملفات الموجودة في قاعدة الشفرة (50٪ إلى 90٪ من ملكية الشفرة لأي ملف محدد) ، وكن أكثر انضباطًا لزيادة ملكية الشفرة وتقليل الديون التقنية عند الضرورة.
الفوائد هي كما يلي:
- أعلى والحفاظ على معايير كتابة التعليمات البرمجية بشكل صحيح. في مجموعة صغيرة مطلعة ، يكون الالتزام بالمعايير العالية أسهل. لا ينطبق هذا فقط على المطورين الذين يقومون بتعديل الكود الخاص بهم ، ولكن أيضًا على مراجعات الكود التي كتبها أقرانهم والتأثير على الأجزاء التي يمتلكونها.
- تسهيل التواصل. الملكية الواضحة والواضحة تعني أن كل مطور في الفريق يعرف من سيجيب على سؤاله.
- إعادة تركيز أكثر فعالية وفعالية. إذا قررت سداد جزء من الدين الفني ، فإن المطورين الأقوياء الذين يمتلكون الكود المناسب هم الأنسب لهذا العمل. استخدم مقاييس الملكية ، والاتصال ، والنشاط المتكرر لتحديد مجالات الاهتمام في قاعدة بياناتك. سيستخدم مطورو البرامج ميزانيتهم للدين الفني بحكمة ولن يمضوا وقتًا طويلًا في سداد الديون الفنية التي لا تستحق ذلك.
- عامل الحافلة لن يخرج عن السيطرة. يمكنك استخدام ملكية التعليمات البرمجية لتنظيم مشاركة المعرفة في مؤسستك. إذا كانت درجة الملكية مرتفعة للغاية ، فقم بتعيين مطورين آخرين لمراجعة الرمز والمهام المرتبطة بتغييره. ستعمل تدريجياً على تحسين مؤشرات الملكية الخاصة بك ، مما سيؤدي إلى تحسين جودة الشفرة وتقليل الديون التقنية.
مثل كل شيء يستحق العناء حقًا ، فإن إنشاء ثقافة هندسية تتعلق بملكية الشفرة (ومتابعتها!) يستغرق بعض الوقت والجهد ، ولكنه سيؤتي ثماره باهتمام. يؤثر هذا العامل بشكل مباشر تقريبًا على أي من هندسة KPI التي يمكنك تخيلها. قم بتضمينها في ثقافة شركتك ، وستصبح على المدى الطويل ميزتك التنافسية الضخمة.