إدارة التكوين - التاريخ في تعليقات التعليمات البرمجية

Question

اسمحوا لي أن أطرح بعض المعلومات الأساسية قبل طرح سؤالي:

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

///<history>
   [mt] 3/15/2009  Made abc changes to fix xyz
///</history>

الرسمية لغرض التعليق المعيار هو أن "تعليقات توفر السلسلة من شرط تعديل الرمز".

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

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

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

Answer 1

عن نفسي لقد وجدت دائما مثل هذه التعليقات أن تكون أكثر صعوبة مما تستحق:فإنها يمكن أن يسبب دمج الصراعات يمكن أن تظهر 'ايجابيات كاذبة' عندما كنت في محاولة لعزل بيانات الاختلاف بين النسختين, و قد رمز مرجع التغييرات التي تم obsoleted لاحقا التغييرات.

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

Answer 2

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

وعملت على مشروع كبير مع الممارسات المماثلة التي قد تغير من نظام التحكم المصدر مرتين. لم يكن هناك يوم واحد عندما لم أكن سعيدة لهذه التعليقات.

هل زائدة عن الحاجة؟ نعم. هو لا لزوم لها؟ لا.

Answer 3

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

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

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

Answer 4

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

Answer 5

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

Answer 6

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

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

وعلى صعيد آخر، بنود مثل هذا واحد - حقيقية. تنظيف الأسبوع الماضي - تجعلني حصى أسناني

    if (ctab->tarray && ctab->tarray[i])
#ifndef NT
      prt_theargs(*(ctab->tarray[i]));
#else
      /* Correct the parameter type mismatch in the line above */
      prt_theargs(ctab->tarray[i]);
#endif /* NT */

وحصل فريق NT الدعوة صحيحة؛ لماذا نظن أنه كان الإصلاح الخاصة بالنظام الأساسي هو خارج عن ارادتي. وبطبيعة الحال، إذا كان رمز استخدمت النماذج بدلا من الإعلانات فقط parameterless قبل الآن، ثم فريق يونكس كان يتعين لإصلاح رمز للغاية. وكان تعليق مساعدة - مؤكدا لي أن الخلل كان حقيقيا - ولكن مستفزة