منفصلة 'التصحيح' و 'الإصدار' يبني?

Question

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

ولسبب مشابه, لا تستخدم 'مزاعم' (انظر أيضا هي تأكيدات دائما سيئة ؟ ...).

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

شخص آخر قال "هذا هو فكرة سيئة";انها سياسة تطورت منذ عدة سنوات بعد أن تم حرقها من قبل:

• بعض المطورين اختبار التصحيح ولكن لا الإصدارات
• بعض المطورين كتابة الأخطاء التي تظهر فقط في الإصدار
• الشركة الإفراج عن الإصدار بعد عدم كفاية اختبار (هو من أي وقت مضى تماما كافية؟)
• يطلق على التصحيح الإصدار

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

ما هي السياسة ؟

Answer 1

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

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

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

Answer 2

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

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

إنها سياسة بسيطة تعطي أفضل ما في العالمين، IMO.

يحرر: ردًا على أحد التعليقات، أعتقد أنه من الواضح أن تصميمات التصحيح والإصدار (يمكنها) إنشاء تعليمات برمجية مختلفة.فكر في "-DDEBUG" مقابل "-DDEBUG"."-DNDEBUG"، و"#إذا تم تعريفه (DEBUG)"، وما إلى ذلك.

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

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

تعتمد كيفية تجريد الثنائيات وتحميل الرموز في مصحح الأخطاء من مصدر خارجي على النظام الأساسي.

Answer 3

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

إنها المرة الأولى هنا في هذا المتجر، وأنا هنا منذ 18 شهرًا أو نحو ذلك.

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

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

Answer 4

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

يممم...يبدو أنك تقوم بعمل debug لي...أليس كذلك ؟

الجزء أين ذهبت خاطئة هو هذا البيان:

أعتقد أنه من الأفضل أن الإفراج عن نسخة من البرنامج الذي المطورين في الواقع اختبار

المطورين لا اختبار التعليمات البرمجية.الاختبارات اختبار التعليمات البرمجية.

وحدة الاختبارات يجب اختبار كل بناء تكوينات.لا تجعل المطورين العمل بيد واحدة مقيدة خلف ظهورهم - السماح لهم استخدام جميع أدوات التصحيح لديهم في التخلص منها هناك.بناء تصحيح هو واحد من هؤلاء.

فيما يؤكد:استخدام التأكيدات يعتمد إلى حد كبير على ما إذا كان أو لم يكن لك البرنامج عن طريق العقد.إذا كنت تفعل, ثم التأكيدات مجرد تحقق العقد في بناء تصحيح.

Answer 5

وفقًا لإجابتي في سلسلة الرسائل المرتبطة، نستخدم أيضًا نفس البنية لتصحيح الأخطاء والإصدار لأسباب مشابهة جدًا.تميل مكاسب الأداء التي تتراوح من 10% إلى 20% من المُحسِّن إلى أن تكون طفيفة جدًا عند مقارنتها بالتحسينات اليدوية على مستوى الخوارزمية.بناء واحد يزيل العديد من الأخطاء المحتملة.خاصة؛

• قد تؤدي المتغيرات غير المهيأة وتجاوزات المخزن المؤقت الصغيرة إلى نتائج مختلفة جدًا في تصحيح الأخطاء وإصدارات الإصدار الأمثل.

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

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

Answer 6

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

على الجانب الإيجابي باستخدام إصدارات التصحيح:

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

Answer 7

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

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

Answer 8

أعتقد أن ذلك يعتمد على حجم المشروع ونوع نظام البناء والاختبار الذي تستخدمه.

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

Answer 9

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

Answer 10

في رأيي أن هذا النقاش يفتقد نقطة مهمة للغاية:

يعتمد الأمر حقًا على نوع المشروع!

إذا قمت بإنشاء مشروع أصلي (C/C++)، فسوف تضطر في الواقع إلى إنشاء تصميمات تصحيح الأخطاء، وذلك ببساطة لأن تحسينات المترجم يمكن أن تجعل تصحيح الأخطاء شبه مستحيل في بعض الحالات.

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

على الرغم من أنه من الواضح أن مشروع C++ الأصلي وتطبيق ويب PHP ليسا جميع أنواع المشاريع الموجودة، إلا أنني آمل أن تكون وجهة نظري قد وصلت.

ملاحظة.:عند التطوير لـ C#، فإنك تواجه حالة حدودية لأنه على الرغم من أن استخدام بناء تصحيح الأخطاء يعطل تحسينات برنامج التحويل البرمجي، فمن خلال تجربتي، لن تواجه اختلافات كبيرة تقريبًا كما هو الحال مع C++

Answer 11

هنا نقوم بالتطوير في وضع التصحيح ونجري جميع اختبارات الوحدات في وضع الإصدار.نحن متجر صغير يحتوي على عدد قليل فقط من التطبيقات (أقل من 12 عامًا) لدعم بدءًا من Classic ASP وASP.Net وVB.Net وC#.لدينا أيضًا شخص متخصص للتعامل مع جميع الاختبارات، ويتم إرجاع المشكلات التي تم تصحيحها إلى المطورين.

Answer 12

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

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

فيما يتعلق بالنقطة الأخيرة، لم تتم دعوتي مطلقًا لتصحيح أخطاء إصدار الإصدار، فقط لإصلاحه...

Answer 13

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

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

Answer 14

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

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

Answer 15

ترى هذا ما هو الأكثر إثارة للجدل البرمجة الرأي ؟

اقتباس:

الرأي:أبدا من أي وقت مضى مختلفة كود بين "التصحيح" و "الافراج" يبني

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

Answer 16

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

1) سيتم تعطيل التحسينات في "إصدارات الإصدار" (وإلا فلن يتمكن المطورون من استخدام مصحح الأخطاء)

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

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

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

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

Answer 17

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

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

Answer 18

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

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

Answer 19

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

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