ลองนึกภาพสถานการณ์ต่อไปนี้:

คุณตรวจพบว่าโปรแกรมของคุณ (หรือของคนอื่น) มีข้อบกพร่อง - ฟังก์ชั่นจะสร้างผลลัพธ์ที่ผิดเมื่อได้รับข้อมูลเฉพาะ คุณตรวจสอบรหัสและไม่พบสิ่งผิดปกติมันดูเหมือนจะชะงักเมื่อได้รับข้อมูลนี้

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

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

ในขณะที่ฉันจะไม่พิจารณาทำสิ่งนี้ฉันรู้สึกประหลาดใจที่อาจารย์และหนังสือมักจะเตือนเราเกี่ยวกับการใช้การแก้ไข "ผ้าพันแผล" ไม่ใช่ความคิดที่ดี ดังนั้นสิ่งนี้ทำให้ฉันประหลาดใจ: "การแก้ไข" ประเภทนี้พบได้บ่อยแค่ไหน?

แรงกดดันด้านเวลา / กำหนดเวลาเป็นหนึ่งในเหตุผล

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

แน่นอนว่าจำนวนครั้งที่คุณย้อนกลับไปและแก้ไขอย่างถูกต้องนั้นมีอยู่น้อยมากเนื่องจากคุณมีปัญหาใหม่ที่ต้องแก้ไขเมื่อวานนี้

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

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

เวลา

เป็นเหตุผล # 1 ในความคิดของฉัน แม้ว่าหากปัญหาคือ codebase ฉลาดฉันอาจใช้เวลาในการตรวจสอบ บ่อยครั้งการแก้ไข "bandage" ของฉันเกี่ยวข้องกับการปรับแต่ง CSS หรือ UI ฉันได้เขียน CSS แบบอินไลน์ที่น่ารังเกียจและ JavaScript เพื่อจัดการกับพวกเขาอย่างรวดเร็ว การย้อนกลับและแก้ไขเป็นตัวเลือกเสมอหากคุณมีเวลา

เราทำพวกเขาเป็นพิเศษ

สำหรับการแก้ไขในระหว่างการพัฒนาเรากำลังทำให้แน่ใจว่าจะไม่มีการแก้ไขใด ๆ โดยไม่ทราบสาเหตุที่แท้จริง อย่างไรก็ตาม:

• การค้นหาสาเหตุที่ผิดปกติจะเริ่มต้นใช้เวลานานเกินไปหรือจนตรอกและมีกำหนดเวลาที่ยากลำบาก
• การเปลี่ยนแปลงรหัสพิเศษเพื่อแก้ไขสาเหตุที่แท้จริงนั้นไม่สามารถทำได้ในเชิงกลยุทธ์ (การเปลี่ยนแปลงจะใช้เวลานานเกินไปและใกล้จะถึงกำหนด)

ในกรณีเหล่านี้เราเลือกใช้การแก้ไข "ผ้าพันแผล" จากนั้นเราเปิดข้อบกพร่องภายในเพื่อระบุสาเหตุที่แท้จริง ใช่ข้อบกพร่องภายในเหล่านี้มักได้รับการปฏิบัติโดยมีลำดับความสำคัญต่ำมาก

สำหรับการแก้ไขในสตรีมการบำรุงรักษาเรากำลังทำให้แน่ใจว่าจะไม่มีการแก้ไขใด ๆ โดยไม่ทราบสาเหตุที่แท้จริง อย่างไรก็ตาม:

• โดยเฉพาะอย่างยิ่งการค้นหาสาเหตุที่แท้จริงจะหยุดชะงัก
• มันสามารถเกิดขึ้นได้อย่างยอดเยี่ยมว่าการแก้ไขสาเหตุที่แท้จริงนั้นไม่สามารถกระทำได้ (การเปลี่ยนแปลงนั้นไม่สำคัญและลูกค้าต้องการการแก้ไขเมื่อวานนี้)

ในกรณีดังกล่าวเราเลือกใช้ "ผ้าพันแผล" การแก้ไขชั่วคราวก่อนและเมื่อลูกค้ามีความสุขเราจะดำเนินการแก้ไขที่เหมาะสมและหลังจากนั้นข้อบกพร่องจะได้รับการแก้ไข

วิกิพีเดีย

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

ก่อนเกี่ยวกับความถี่ของการแก้ไข "ผ้าพันแผล":

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

ประการที่สองคำแนะนำของฉัน:

หากข้อผิดพลาดเกิดขึ้นในซอร์สโค้ดของทีมพัฒนา:

• แก้ไขอย่างมืออาชีพ (ถ้าคุณแก้ไขคุณเป็นเจ้าของมัน)
• เมื่ออยู่ภายใต้แรงกดดันในเวลาให้ทำสิ่งที่ดีที่สุดที่คุณสามารถทำได้ - ซึ่งต้องการให้คุณ:
  • ดูผลกระทบที่อาจเกิดขึ้นกับผู้ใช้ปลายทาง: ของบั๊กและการแก้ไขที่เสนอเพื่อตัดสินใจว่าจะยอมรับการแก้ไขหรือไม่
  • ศึกษาข้อมูลโค้ดที่เกี่ยวข้อง (ใช้ข้อมูลประวัติจากเครื่องมือการจัดการซอร์สโค้ดของคุณ) และพูดคุยกับเพื่อนร่วมงานของคุณ (แต่ไม่ใช้เวลานานเกินไป) จนกว่าคุณจะเข้าใจปัญหาและวิธีแก้ปัญหาได้ดี
• ติดตามข้อบกพร่องด้วยระบบติดตามข้อบกพร่องเสมอ

หากข้อผิดพลาดเกิดขึ้นในซอร์สโค้ดของทีมอื่น:

• ผลักดันทีมนั้นเพื่อแก้ไขข้อบกพร่อง
• ยื่นข้อผิดพลาดนั้นกับระบบติดตามข้อบกพร่องของทีมอื่นเสมอ

หากข้อผิดพลาดเกิดขึ้นในผลิตภัณฑ์ของ บริษัท อื่น (หรือไม่มี บริษัท ):

• ในกรณีนี้การแก้ไขเทปพันสายไฟ (หรือการแก้ไขปัญหาที่ขับเคลื่อนด้วยข้อมูล ) อาจเป็นวิธีเดียวในการแก้ไขข้อบกพร่อง
• หากเป็นโอเพนซอร์สให้ไฟล์ที่มีข้อบกพร่องกับระบบติดตามข้อบกพร่องบางอย่าง (อาจเป็นแบบสาธารณะ) เพื่อให้บางคนสามารถตรวจสอบได้

ขึ้นอยู่กับอายุของรหัสฐานฉันคิดว่ามาก ในรหัสเก่าฉันคิดว่ามันเป็นเรื่องธรรมดามากเขียนใหม่ว่ารูทีนภาษาโคบอลอายุ 20 ปีไม่สนุก แม้แต่รหัสใหม่ที่ใช้งานจริงมันก็ยังค่อนข้างธรรมดา

ฉันจะบอกว่ามันเป็นเรื่องธรรมดามาก

ลองดูโพสต์บล็อกของ Joel Spolsky: The Duct Tape Programmer

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

มีความแตกต่างระหว่างโลกแห่งการศึกษาและโลกแห่งความจริงที่ซอฟต์แวร์ต้องใช้งานจริงภายใต้เวลาและข้อ จำกัด ทางธุรกิจ

ในทางที่มันวางไว้ใต้พรมเพื่อเลื่อนการแก้ไขจนกระทั่งหวังว่าในภายหลัง น่าเศร้าที่บ่อยครั้งการแก้ไขที่รอการตัดบัญชีไม่เคยเกิดขึ้นและรหัสนี้ค้นหาวิธีการในการผลิต

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

ความถี่ที่ใช้ในการแก้ไขผ้าพันแผลนั้นขึ้นอยู่กับหลาย ๆ อย่างเช่นความซับซ้อนของรหัสไม่ว่าจะเป็นคนที่คุ้นเคยกับรหัสมากที่สุดหรือไม่ ) และ timescales ที่เกี่ยวข้อง

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

มีหลายกรณีที่การแก้ไขประเภทนี้นั้นใช้ได้จริง ๆ และอาจเป็นอุดมคติ (เท่าที่ระยะเวลาที่ใช้ในการตรวจแก้จุดบกพร่องนั้นเกี่ยวข้อง)

ลองนึกภาพสถานการณ์ที่คุณมี 20 DLLs ซึ่งควรจะทำหน้าที่เหมือนโมดูลสำหรับการปฏิบัติการหลักของคุณ แต่ยังต้องการข้อมูลบางอย่างจากการปฏิบัติการหลักเพื่อให้ทำงานได้

หากคุณต้องการใช้ DLL เหล่านั้นนอกหน่วยปฏิบัติการหลักคุณจะต้องลบล้างค่าส่งคืนบางส่วนจากโปรแกรมหลักเนื่องจาก A. ) มันไม่มีอยู่ในบริบทนี้และ B. ) คุณไม่ต้องการให้มันมีอยู่ในบริบทนี้

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

แทนที่จะใส่ifฟังก์ชั่นของคนอื่นในภายในฉันจะใส่{$ifdef}ฟังก์ชั่น - นั่นเป็นวิธีที่ไม่มีใครสับสนกับสิ่งที่ควรจะมี