การฝึกลิงถือเป็นการฝึกเขียนโปรแกรมที่ดีหรือไม่?

ฉันได้รับความประทับใจแล้วการจับลิงนั้นเป็นประเภทแฮ็คที่รวดเร็วและสกปรกมากกว่าการฝึกเขียนโปรแกรมมาตรฐานที่ดี ในขณะที่ฉันใช้เป็นครั้งคราวเพื่อแก้ไขปัญหาเล็กน้อยกับ libs ของบุคคลที่สามฉันคิดว่าเป็นการแก้ไขชั่วคราวและฉันจะส่งปะที่เหมาะสมให้กับโครงการของบุคคลที่สาม

แต่ผมเคยเห็นเทคนิคนี้มาใช้เป็น "วิธีปกติ" ในโครงการหลักเช่นใน Gevent ของโมดูลgevent.monkey

การฝึกลิงกลายเป็นกระแสหลักปกติการฝึกเขียนโปรแกรมที่ยอมรับได้หรือไม่?

ดูเพิ่มเติม: "Monkeypatching เพื่อมนุษย์"โดย Jeff Atwood

ไม่ แต่บางครั้ง monkeypatch เป็นความชั่วร้ายที่น้อยกว่า (มีรหัสที่เสีย :) กฎทั่วไปสำหรับ monkeypatches ในทับทิมคือ:

• มีเหตุผลที่ดีจริงๆสำหรับ monkey-patch (โปรแกรมแก้ไขด่วนที่สำคัญชั่วคราวเป็นเหตุผลที่ดีการจัดรูปแบบที่ดีของวิธี to_s ไม่ได้เว้นแต่คุณจะทำงานกับ ActiveSupport)

• ทำให้มันโปร่งใสที่สุดเท่าที่จะเป็นไปได้: ใส่มันไว้ในสถานที่เฉพาะใน codebase และแยกไฟล์เขียนเอกสารอธิบายเหตุผลของ monkeypatch (นี่คือตัวอย่าง )

• ง่ายต่อการลบ - เอกสารประกอบควรมีข้อมูลเกี่ยวกับการลบและสิ่งที่ต้องระวัง Monkeypatches จำนวนมากเป็นแบบชั่วคราวดังนั้นควรถอดออกง่าย

ใช่การจับลิงนั้นมีประโยชน์มาก!

อย่างใดชื่อดูเหมือนจะมีอิทธิพลอย่างมากต่อการรับรู้ของผู้คน เรียกว่า "monkeypatch" และฟังดูแย่เรียกว่า "hot fix" หรือ "on-the-fly fix" และฟังดูดี

ฉันคิดว่าความสามารถในการเปลี่ยนเมธอด / คุณลักษณะ / ฟังก์ชั่นที่รันไทม์เป็นสิ่งที่มีประโยชน์มาก แม้แต่คนที่ใช้จาวาสคริปต์ก็ใช้งานได้ตลอดวันโดยที่ไม่รู้ตัว

ตัวอย่างเช่น

button.onclick = function(e) { ...}

บรรทัดง่าย ๆ นี้แสดงให้เห็นถึงความจริงที่ว่าคุณเปลี่ยนพฤติกรรมของปุ่ม มันถูกออกแบบมาอย่างนั้น ในทำนองเดียวกันคุณสามารถปรับเปลี่ยนฟังก์ชั่นอื่น ๆ ทุกอย่าง แต่มันก็โง่ที่จะทำเช่นนั้น

ตอนนี้สำหรับคำถามของการส่งแพทช์ด้วยวิธีที่ ... ดี ... ทำไมไม่ คุณเพียงแค่ต้องดาวน์โหลดตัวปะแก้เล็ก ๆ แทนที่จะปล่อยให้เป็นเรื่องใหญ่ เฮ้คุณสามารถแก้ไขเซิร์ฟเวอร์โดยไม่หยุดได้เยี่ยมเลย! จากนั้นวันหนึ่งคุณสามารถดึงข้อมูลรีลีสล่าสุดสำหรับการอัปเดตที่ใหญ่กว่าได้ ยุติธรรมพอสมควร ใช่ฉันลงคะแนน "runtime patches" เป็นสิ่งที่ดี

น่าสนใจพอบางภาษาเช่น Erlang ยังสร้างต่อยอดจากแนวคิดนี้ ความสามารถในการอัปเดตเซิร์ฟเวอร์ได้ทันที

แน่นอนในที่สุดและชอบทุกอย่างอื่นมันเป็นเรื่องของวิธีการใช้งานของคุณ คุณสามารถทำสิ่ง OO ที่ยอดเยี่ยมและสิ่งที่น่าอับอายมันเหมือนกันทั้งหมด

แก้ไข:

ให้ฉันเพิ่มความแตกต่างของบางกรณีไม่ว่าคุณจะปรับปรุงห้องสมุดของคุณหรือบุคคลที่สามอย่างใดอย่างหนึ่ง

... โดยทั่วไปสิ่งที่คุณทำกับแพทช์ดังกล่าวกำลังแก้ไขข้อผิดพลาดของห้องสมุดของคุณเองหรือของบุคคลที่สาม ในทั้งสองกรณีมันมีประโยชน์ สำหรับตัวคุณเองมันช่วยให้คุณสามารถแก้ไขปัญหาได้ทันที สำหรับบุคคลที่สามคุณอาจรอ (หลายเดือน?) จนกว่าพวกเขาจะแก้ไขด้วยตัวเองหรือตอนนี้คุณทำเอง (คุณยังสามารถส่งแพทช์ให้พวกเขาเพื่อที่พวกเขาจะแก้ไขได้ที่ด้านข้างของพวกเขา) เมื่อพวกเขาปล่อยเวอร์ชัน lib ถัดไปของพวกเขาด้วยปัญหาได้รับการแก้ไขคุณสามารถยังถ้าคุณต้องการอัปเดตห้องสมุดและลบแพทช์ที่ด้านข้างของคุณ

ตอนนี้แน่นอนถ้าคุณใช้แพทช์เพื่อเปลี่ยนพฤติกรรมของ lib และทำให้วัตถุประสงค์ / วิธีการทำงานของมันชัดเจนขึ้นมานั่นเป็นสูตรสำหรับภัยพิบัติ แม้แต่ลิงก็จะเห็นว่า ... เอาละฉันหวังว่า ;)

ฉันเชื่อว่าแพทช์ทั้งหมดมีความเสี่ยงโดยเนื้อแท้เนื่องจากลักษณะของเวลาทำงานและไม่สามารถติดได้ในขณะออกแบบ

พวกเขายินดีต้อนรับข้อยกเว้นรันไทม์และต้องการ debuggers ที่ซับซ้อนและเฝ้าดูเพียงเพื่อติดตาม

พวกเขาจะใช้เมื่อคนเรียนซีลและดังนั้นจึงเป็นไปไม่ได้ อย่างไรก็ตามมีวิธีที่ดีกว่าในการขยายวัตถุโดยไม่ทำให้เสียหาย

สองเซ็นต์ของฉัน

โดยทั่วไปการปะควรเป็นทางเลือกสุดท้ายการปะของลิงมากยิ่งขึ้น ปัญหานี้เป็นปัญหาหลักในการบำรุงรักษา

นานมาแล้วเคอร์เนล linux ของฉันมีโปรแกรมแก้ไขแยก 3 ตัวซึ่งจำเป็นสำหรับไดรเวอร์การ์ดแสดงผลของฉันและสองแอปพลิเคชันที่เป็นกรรมสิทธิ์ที่ฉันมี สองคนมีการเปลี่ยนแปลงที่ขัดแย้งกันซึ่งหมายความว่าฉันต้องการแพตช์ที่ 4 เพื่อแก้ไขความแตกต่างระหว่างพวกเขา ตอนนี้เมื่อใดก็ตามที่ปัญหาความปลอดภัยได้รับการแก้ไขในเคอร์เนลอัปสตรีมฉันต้องรอให้ผู้ขาย 3 แพทช์เหล่านั้นปล่อยการอัปเดตเป็นเคอร์เนลเวอร์ชันใหม่ซึ่งใช้เวลาตั้งแต่หนึ่งถึงหกเดือนหรือฉันต้องดูแลอัปสตรีมด้วยตนเอง แพทช์รักษาความปลอดภัยจนกว่าผู้ขายแพตช์รายอื่นจะติดตาม

หลังจากไม่กี่ปีที่ผ่านมาผู้ขายพยายามที่จะรวมอยู่ในแหล่งเคอร์เนลต้นน้ำและฉันก็สามารถที่จะหยุดการกระทำที่สมดุล แต่คุณสามารถเห็นสิ่งที่เป็นระเบียบในเวลาเฉลี่ย อย่าทำสิ่งนั้นกับโปรแกรมเมอร์ของคุณเว้นแต่คุณจะต้องทำ

ไม่มันไม่ใช่เทคนิคมาตรฐานสำหรับการพัฒนาซอฟต์แวร์ มันยังคงเป็นวิธีแก้ปัญหาในการแก้ปัญหาเฉียบพลันและมีข้อเสียอย่างชัดเจน การละเมิดหลักการทดแทน Liskovมาถึงใจ การปะของ Monkey ทำให้การให้เหตุผลเกี่ยวกับโปรแกรมเป็นเรื่องยาก สำหรับโปรแกรมของคุณเองคุณควรวางรหัสที่เป็นของมัน สำหรับ libs บุคคลที่สามคุณจะต้องตกอยู่ในอันตรายเสมอว่าโปรแกรมแก้ไขของคุณจะไม่ทำงานกับ lib เวอร์ชันถัดไป

แน่นอนว่าการปะแก้ลิงนั้นมีประโยชน์ถ้าคุณรู้ว่าคุณกำลังทำอะไรอยู่และไม่มีเวลาที่จะนำสารละลายSOLIDไปใช้ แต่คุณไม่ควรพิจารณาเทคนิคนี้เป็นมาตรฐานและสร้างแผ่นปะลิงบนแผ่นปะของลิง

BTW คุณเคยเขียนแบบทดสอบหน่วยสำหรับแพทช์ลิงหรือไม่?