หากบั๊กมีอายุมากกว่า 5 ปีแสดงว่าเป็นคุณสมบัติหรือไม่ [ปิด]

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

เราสามารถขายซอฟต์แวร์เส็งเคร็ง (แม้ว่าฟังก์ชั่นสวย) มานานกว่าทศวรรษ มันมีคุณสมบัติมากมายและผลิตภัณฑ์มีการแข่งขัน แต่มีข้อผิดพลาดบางอย่างร้ายแรงเช่นเดียวกับ "การตัดกระดาษ" หลายพันครั้ง - สร้างความรำคาญเล็กน้อยที่ลูกค้าจำเป็นต้องคุ้นเคย

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

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

ผู้เขียนโค้ดหนุ่มในฉันคิดว่า: เขียนสิ่งที่เลวร้ายนี้ใหม่! ในฐานะที่เป็นคนที่มีโอกาสใกล้เคียงกับยอดขายลูกค้าฉันต้องการให้ข้อสงสัยเกี่ยวกับวิธีการนี้

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

ฉันรู้สึกถึงความเจ็บปวดของคุณ.

แต่การแก้ไขบางสิ่งบางอย่างเพียงเพราะมันเป็นข้อบกพร่องไม่ใช่เหตุผลที่ดีพอ

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

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

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

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

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

กำหนดข้อผิดพลาด "ข้อมูลจำเพาะดังกล่าวเรียงตามวันที่ แต่เรียงตามจำนวนธุรกรรม" ไม่จำเป็นต้องเป็นข้อบกพร่องในรหัส อาจเป็นการเปลี่ยนแปลงที่ไม่มีเอกสาร - บางครั้งมีคนขอให้เปลี่ยนลำดับการจัดเรียง แต่ข้อมูลจำเพาะข้อกำหนดคู่มือ (ปุ่มและป้ายกำกับบน UI) ไม่มีการเปลี่ยนแปลงเพื่อจับคู่และไม่มีใครคิด สำหรับคุณที่จะแสดงและเปลี่ยนกลับไปเป็น "ตามวันที่" จะทำให้เกิดความสับสนวุ่นวายและสำหรับคุณที่จะอัปเดต UI, ข้อมูลจำเพาะ, คู่มืออื่น ๆ โดยทั่วไปจะเสียเวลาของคุณด้วยข้อยกเว้นที่เป็นไปได้ของทฤษฎีหน้าต่างแตก ."

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

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

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

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

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