كيف تتعامل مؤسستك مع المكونات المشتركة؟

Question

المكون المشترك هو مكتبة أو جزء آخر من التعليمات البرمجية التي يتم إنشاؤها وصيانتها بواسطة مجموعة واحدة وتستخدمها العديد من المجموعات.

بعض المشاكل التي نواجهها هي:

• لا يقوم المستخدمون بالإبلاغ عن مشكلات تتعلق بالمكونات.
• يقوم المستخدمون بإنشاء حلول بديلة للمكونات لتناسب احتياجاتهم.
• إنهم يخرقون التوافق مع إصدار صندوق الأمتعة فقط للوفاء بالمواعيد النهائية الخاصة بهم.
• وينتهي الأمر بالمستخدمين بترميز حلولهم الخاصة (الأقل قوة) لأنهم يعتقدون أنها أفضل.

كيف تتعامل مؤسستك مع المكونات المشتركة؟

الأفكار التي لدي:

• تعامل مع المكون كمشروع مفتوح المصدر واطلب من الفرق إرسال التصحيحات.
• عدم السماح تمامًا بالتعديلات المخصصة على الكود.
• ...

Answer 1

ما لديك هنا قد يكون مشكلة عوامل بشرية وليس مشكلة فنية.في الواقع، قد تكون هذه مشكلة تعليمية في المقام الأول (مقترنة بالمتلازمة النموذجية التي لم يتم اختراعها هنا).

بعد أن عملت في شركات كبيرة، أدركت أنه من الصعب على الشخص الجديد أن يفهم جميع الموارد (أي الموارد).مكتبات الأكواد المشتركة) المتاحة له، ناهيك عن كيفية وتوقيت استخدامها بشكل صحيح.

عندما يكون لديك موظف جديد، هل يتم إعطاؤه تدريبًا رسميًا في مكتبة المكونات المشتركة الخاصة بك؟

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

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

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

Answer 2

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

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

Answer 3

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

هناك دائما المقايضة ل

• إقناع الناس باستخدام المكون الخاص بك
• الحفاظ على مستوى معقول من الجودة في نفس الوقت

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

Answer 4

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

Answer 5

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

Answer 6

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

من الأسهل الذهاب إلى مكتب شخص ما (أو إرساله بالبريد)، وشرح ما تحتاجه، والحصول على واحد مما يلي:

• الطريقة المتوقعة لفعل ما تريد،
• الموافقة على إضافة الميزة المطلوبة (أو توجيه العميل للقيام بذلك)،
• إذن لتنفيذ الميزة المطلوبة في المكون المشترك،

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

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