ما هي التقنيات التي تستخدمها لتعظيم إعادة استخدام التعليمات البرمجية؟

Question

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

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

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

Answer 1

سؤال معقد:

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

• بعض الأجزاء مخصصة للتطبيق.ولا يمكن تعميمها بسهولة.نقوم بتحويلها إلى HowTos ونقدم عروضًا تقديمية داخلية.يتم أيضًا إعادة تدوير التعليمات البرمجية باستخدام SCM سهل التصفح (في حالتنا SVN).

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

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

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

Answer 2

إعادة البناء بلا رحمة والأمل في الأفضل.

تحديث (بعد 4 سنوات ونأمل أن يكون أكثر حكمة)

• مثل تعليق S.Lott يقول:انتبه إلى التسمية.انشر الكلمة لجميع "الملتزمين" في الفريق.الأسماء الجيدة تجعل الأشياء قابلة للبحث وبالتالي تقلل من الازدواجية.
• امتلك طريقة واحدة لفعل شيء ما واجعلها سهلة الوصول إليها وقابلة للبحث فيها.
• أكتب كود لمبرمج (LCD) المتوسط..لا تكن ذكيًا حيث تكون البساطة كافية.(يشمل ذلك نمط التصميم القهري في استخدام الأحذية والاضطرابات ذات الصلة)
• اعتماد مجموعة مشتركة من الاتفاقيات والأنماط والمبادئ التوجيهية والمعايير، وما إلى ذلك في وقت مبكر.ضمان الاشتراك وبالتالي الامتثال داخل الفريق.(وهذا يعني أن الجميع يستخدم علامات التبويب (أو المسافات)!).لا يهم ما تختاره - فالهدف هو أن تبدو التعليمات البرمجية متسقة
• لديك حارس بوابة (يحترمه الفريق)، والذي يراقب جميع عمليات تسجيل الوصول بحثًا عن الأعلام الحمراء.
• اكتب اختبار الكود أولاً / من الخارج إلى الداخل.يضمن هذا عادةً أن الكود الخاص بك قابل للاستخدام من قبل العديد من العملاء.(انظر رصاصة GOOS حول استقلال السياق)

Answer 3

• لديك إطار عمل مدعوم بشكل نشط.

• تعرف على قاعدة التعليمات البرمجية الموجودة / اجعل المطورين الآخرين يعرفون قاعدة التعليمات البرمجية.إذا كانت مجموعتك/شركتك كبيرة بما يكفي، فاستعن بشخص يعرف قاعدة التعليمات البرمجية ويمكن أن يُطلب منه الإرشاد.

• وثيقة، وثيقة، وثيقة.التعليمات البرمجية غير الموثقة غير مجدية لإعادة الاستخدام لأنها تستغرق وقتًا طويلاً لفهم أعمالها الداخلية.

• لديك واجهات جيدة.أنواع سهلة، وهياكل أو فئات سهلة.كلما كان الأمر أكثر تعقيدًا، قل استخدامه في مشروع آخر.

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

Answer 4

جرب استخدام تد إذا لم تكن بالفعل هو رد فعلي الأولي.

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

فائدة أخرى، TDD لديها خطوة لإزالة التكرار (إعادة البناء) كجزء من الدورة.

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

Answer 5

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

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

Answer 6

قم بتعريف التطبيق بالكامل وابدأ في إعادة البناء من القسم الأثقل من التعليمات البرمجية.(80% من الوقت يقضيه في 20% من التعليمات البرمجية الأكثر استخدامًا)

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

وفقًا للقاعدة، يستخدم الكود الجديد دائمًا أفضل الممارسات.

Answer 7

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

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

1. إن إعادة استخدام التعليمات البرمجية التي تجرها الدواب والتي ستجعلك تقضي ساعات في تصحيح أخطاء التعليمات البرمجية الخاصة بأشخاص آخرين أمر غير مرغوب فيه.
2. إن إعادة استخدام التعليمات البرمجية التي توازن بين مجموعة واسعة من الاحتياجات المتباينة بحيث بالكاد تلبي احتياجاتك الخاصة وتتطلب منك القفز عبر الكثير من العقبات للحصول في النهاية على حل غريب وغير فعال هو أمر غير مرغوب فيه.
3. إن إعادة استخدام التعليمات البرمجية التي تتطلب تغييرات في التصميم باستمرار وتخضع لعمليات إهمال من النوع الذي يتطلب منك إعادة كتابة التعليمات البرمجية باستخدامه كل 6 أشهر أمر غير مرغوب فيه إذا كان بإمكانك تنفيذ الحل بنفسك خلال نصف ساعة بطرق لا تحتاج إلى تصميم التغييرات في المستقبل لأنها تخدم احتياجاتك المحددة فقط.
4. تعد قاعدة التعليمات البرمجية المملوءة بأكواد ذات مظهر غريب أمرًا غير مرغوب فيه مقارنة بقاعدة تستخدم المزيد من اللغة والمكتبة القياسية بطرق اصطلاحية ومألوفة، حتى لو كان ذلك يتطلب المزيد من التعليمات البرمجية قليلاً.
5. يتدخل المطورون في كل مكان لأن كلاهما يريد إجراء تغييرات غير متوافقة على نفس التصميم أثناء القتال والجدال وإجراء تغييرات تسبب أخطاء في تطبيقات بعضهم البعض أمر غير مرغوب فيه.
6. إن إلقاء مجموعة كبيرة من التبعيات على التصميمات غير الناضجة التي لم تثبت نفسها (لم يكن لديها تغطية اختبارية شاملة، ولم يكن لديها الوقت الكافي لعزل التصميم حقًا والتأكد من أنه يلبي احتياجات المستخدم بشكل فعال دون الحاجة إلى مزيد من التغييرات في التصميم) أمر غير مرغوب فيه.
7. يعد الاضطرار إلى تضمين/استيراد/ربط مجموعة كبيرة من المكتبات والفئات/الوظائف باستخدام نص البناء الأكثر تعقيدًا لكتابة شيء بسيط أمرًا غير مرغوب فيه.
8. والأهم من ذلك كله، أن إعادة استخدام التعليمات البرمجية بطريقة تكلف وقتًا أطول بكثير على المدى القصير والطويل من عدم إعادة استخدامها أمر غير مرغوب فيه.

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

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

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

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

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

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