كيف يمكنني إنشاء مكتبة إعادة استخدام التعليمات البرمجية والحفاظ عليها؟

Question

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

على سبيل المثال:
مستوى؛متطلبات؛وصف
المستوى 0؛الكود قانوني للاستخدام؛هل الكود قانوني للاستخدام في الصناعة التجارية/عبر عقود متعددة/وما إلى ذلك؟
المستوى 1؛الرمز الأساسي ويلبي متطلبات المستوى 0؛التعليمات البرمجية النموذجية، وأدوات الطرف الثالث، وما إلى ذلك
المستوي 2؛لديه واجهة وظيفية وتعليقات ويلبي متطلبات المستوى 1؛وثائق كافية لكل فئة ووظيفة؛القدرة على تحديد الوظيفة من التعليقات
مستوى 3؛يلتزم بمعايير الترميز ويلبي متطلبات المستوى 2؛يتبع معايير الترميز المحددة ويجتاز اختبار الأداة المساعدة لفحص التعليمات البرمجية
مستوى 4؛يتضمن حالات اختبار ويلبي متطلبات المستوى 3؛لديه حالات اختبار كافية لاختبار كافة وظائف التعليمات البرمجية
مستوى 5؛تمت الموافقة عليها من قبل لجنة إعادة الاستخدام وتلبي متطلبات المستوى 4؛تمت مراجعته من قبل خبراء إعادة الاستخدام والأقران والتحقق من أنه يلبي جميع مستويات النضج

أتساءل عما إذا كان ينبغي أن يكون مستوى النضج هذا عبارة عن هيكل هرمي، حيث تحتاج من أجل الانتقال إلى المستوى التالي إلى تلبية متطلبات جميع المستويات السابقة (كما أوضحت أعلاه)؟

أو إذا كان يجب أن تكون مجموعة فرعية من المتطلبات للوفاء بالمستوى التالي؟

على سبيل المثال، لقد استوفينا متطلبات x من y، ويمكننا الانتقال إلى المستوى التالي (ستكون المتطلبات هي نفسها المذكورة أعلاه).

المستوى 0، يلبي 0 من أصل 6 متطلبات
المستوى 1، يلبي 1 من أصل 6 متطلبات
…

المشكلة التي أراها في نهج المجموعة الفرعية هي أن بعض المتطلبات يجب أن يكون لها ترجيح أقوى، وفي هذا النهج لن يتم أخذ ذلك في الاعتبار (ما لم أبدأ في الحصول على مثل محدد، يلبي خارج b وx من y، وما إلى ذلك).ولكن بعد ذلك يمكن أن يبدأ الأمر بالتعقيد.

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

Answer 1

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

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

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

على غرار الاتصالات، لا تؤذي الحضور من وقت لآخر ما هو هناك. تكرارا! الاتصالات.

لذلك، في الحد الأدنى من بناء كل مكتبة يجب أن:

• نشر المكتبة (ربما يخطر المشتركين)
• نشر الوثائق
• تشغيل وحدة الاختبارات
• نشر مستوى النضج

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

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

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

Answer 2

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

نهج واحد رأيته يعمل بشكل جيد في شركة كبيرة هو:

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

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

Answer 3

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

الآن، أصبحت هيكلة أداة CM أمرًا مهمًا.لقد تم تصميمه لنقل جودة الكود، حتى تعرف ما الذي ستدخل فيه عند استخدامه.على سبيل المثال، إذا كتبت فصلًا دراسيًا بسيطًا بالكاد يحتوي على أي تعليقات ولا يلتزم بمعايير البرمجة (ربما نموذجًا أوليًا)، فسيتم إدخاله في \sw_repository\level0\ExamplePrototype.

ربما يأخذ شخص ما هذا الجزء من التعليمات البرمجية ويضيف تعليقات ويرفعه إلى مستوى المعايير.ثم يقوم هذا الشخص بوضعه في \sw_repository\level1\ExamplePrototype.

وبعد ذلك، يقوم نفس الشخص، بعد فترة، بإنشاء اختبارات وحدة لـ examplePrototype.سينتقل هذا بعد ذلك إلى المستوى 2 وما إلى ذلك.

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

Answer 4

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

هنا مكتبة بلدي في C ++
http://code.google.com/p/kgui/

Answer 5

لسنوات كان مايكروسوفت داعية كبيرة لما يعرف باسم مصانع البرمجيات, ، جزء كبير من الذي تكرس لحل مشاكل إعادة الاستخدام.

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

حظ سعيد!

Answer 6

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

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

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

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

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

فقط 2 سنتات ...)

Answer 7

إلقاء نظرة على الإرادة "اعترافات بائع برنامج مستعملة"، والأشياء من قبل حاخام HP Reuse، مارتن جريس.

Answer 8

أعتقد أنك تفكر كثيرا في مشكلة غير المشكلة.

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

Answer 9

لقد اعتبر نهج جيد أن يكون لديك مكتبة واحدة، ولكن خطوط الآلاف من الخراب!