متى يجب على المرء استخدام مرجع مشروع مقابل مرجع ثنائي؟

Question

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

بعض الحجج لصالح مراجع المشروع:

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

بعض الحجج لصالح المراجع الثنائية:

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

ما هي سياستك/تفضيلاتك عندما يتعلق الأمر باستخدام مراجع المشروع أو الثنائية؟

Answer 1

يبدو لي كما لو كنت قد غطيت جميع النقاط الرئيسية.لقد أجرينا مناقشة مماثلة في العمل مؤخرًا ولم نقرر بعد.

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

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

في الأساس، أنا بالتأكيد أصوت لصالح تعليقاتك (من حيث SO) حول إبقاء كود المكتبة المثبت بعيدًا عن الأنظار بالنسبة للمطور العادي.

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

Answer 2

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

أعتقد أن سؤالك يدور في الواقع حول متى تسير المشاريع معًا في نفس الحل؛والسبب هو أن المشاريع في نفس الحل يجب أن يكون لها مراجع مشروع لبعضها البعض، ويجب أن يكون للمشاريع في حلول مختلفة مراجع ثنائية لبعضها البعض.

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

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

Answer 6

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

أفصلها بالمفهوم باختصار