لماذا تتجنب القفل المتشائم في نظام التحكم في الإصدار؟

Question

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

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

Answer 1

يعتمد ذلك على مشروعك وفريقك بشكل عام.يعد القفل المتشائم أمرًا جيدًا لأنه سهل الفهم - مطور واحد في كل مرة، ولا يلزم الدمج!

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

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

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

Answer 2

1. اذهب للعب مع Source Safe واحصل على إجازة للمطور لقضاء إجازة لمدة أسبوعين.أضف إلى ذلك عدم تواجد مسؤولي VSS.الآن لديك إصلاح ليتم نشره ولكن لا يمكنك ذلك بسبب المطور
2. إذا كان لديك العديد من الميزات و/أو إصلاحات الأخطاء التي يجري العمل عليها.بغض النظر عن مدى صغر حجم التعليمات البرمجية الخاصة بك، ستظل لديك منافسة على ملف مركزي.

Answer 3

1. يحتاج بوب إلى تحرير FooBar.java
2. لقد قام جون بفحصها للتحرير
3. يقوم بوب بتحرير نسخته المحلية على أية حال ويحفظها باسم FooBar.java.bak
4. عندما يقوم جون بتسجيل وصوله، يقوم بوب بفحصه
5. يقوم بوب بنسخ FooBar.java.bak فوقه ويقوم بإيداعه
6. يحصل جون على إعادة تنفيذ ميزته

لقد رأيت ذلك يحدث مرارا وتكرارا.يقوم المطورون بذلك لأن هذه العملية مزعجة:

1. يحتاج بوب إلى تحرير FooBar.java
2. لقد قام جون بفحصها للتحرير
3. يتعين على بوب أن ينتظر العبث بإبهامه حتى ينتهي جون

القفل المتشائم يبدو وكأنه ساعة هواة، آسف.

Answer 4

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

Answer 5

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

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

Answer 6

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

المشكلة الحقيقية هي تحديد التوازن بين ما لديك

احتمال دمج الأخطاء مقابل.الإزعاج الناجم عن الأشخاص الذين يقومون بقفل الملفات

إن فكرة أن نظام القفل أو عدم القفل هو "متفوق" هي فكرة محض هراء.

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

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

Answer 7

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

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

لقد عملت أيضًا مرة واحدة مع قفل ملف المصدر المرئي الآمن مشروع مستضاف.لقد كانت IMHO ذات نتائج عكسية.

Answer 8

مطورو البرمجيات متفائلون دائمًا - ما عليك سوى إلقاء نظرة على مهاراتهم في التقدير!

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

Answer 9

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

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

بمعنى آخر، ستعرف أن "Bob" يجري مجموعة كبيرة من التغييرات في المكونات X/Y/Z، إذا كان لديك إصلاح خطأ في المكون X، فستعرف أنك تتحدث إلى Bob قبل محاولة إرسال تغييراتك.

وكما قلت هذا مثالي ;)

Answer 10

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

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

خلاف ذلك...