لرقعة القرد أم لا؟

Question

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

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

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

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

---

يحرر:ل @guerda:

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

مثال صغير في بايثون:

import os
def ld(name):
    print("The directory won't be listed here, it's a feature!")

os.listdir = ld

# now what happens if we call os.listdir("/home/")?
os.listdir("/home/")

Answer 1

لا!

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

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

إذا لم تتمكن حقًا من الحصول على التصحيح في المنبع لأي سبب من الأسباب، فقم على الأقل بإنشاء ريبو محلي (git) لتتبع المنبع والحصول على تغييراتك في فرع منفصل.

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

Answer 2

وأود أن أقول لا.

وينبغي أن يكون كل التصحيح قرد استثناء وتميز (على سبيل المثال مع تعليق // HACK) على هذا النحو بحيث تكون سهلة لتعقب الظهر.

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

Answer 3

وأنا أتفق مع ديفيد في أن إنتاج قرد الترقيع متاحة عادة ليست فكرة جيدة.

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

Answer 4

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

في بيثون، يحتاج المرء إلى النظر فيما إذا كانت فئة يمكن أن يكون في كل (انظر هذا <وأ href-مصححة القرد = "https://stackoverflow.com/questions/192649/can-you-monkey-patch-methods- على النواة-أنواع-في بيثون "> السؤال SO للحصول على مناقشة)، والتي تتعلق بتنفيذ قليلا أقل OO بايثون. لذا سأكون حذرا وميلا للإنفاق بعض الجهد تبحث عن بدائل قبل القرد الترقيع.

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

Answer 5

وكلمة واحدة: بورصة مصر

إذا كنت قد لعبت أبدا مع أنه قبل بالسقوط في مستنقع

// BOF: Fixed/added/removed bla bla bla
...
// EOF

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