คุณจะลบรหัสที่ดูเหมือนไม่เคยใส่ออกมาได้อย่างไร

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

ความคิดสองประการเกิดขึ้นในใจ

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

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

มีความคิดที่ดีขึ้นหรืออะไรบางอย่างที่เป็นแนวทางแบบบัญญัติหรือไม่?

ในโลกแฟนตาซีที่สมบูรณ์แบบที่ฉันมีการทดสอบหน่วย 100% ฉันจะลบมันรันการทดสอบหน่วยของฉันและเมื่อไม่มีการทดสอบเปลี่ยนเป็นสีแดงฉันยอมรับมัน

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

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

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

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

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

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

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

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

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

นอกเหนือจากคำตอบที่มีอยู่แล้วที่กล่าวถึงคุณยังสามารถลบรหัสซ้ำ ๆ หลาย ๆ รุ่นได้อีกด้วย

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

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

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

แต่รหัสไม่ใช่สินทรัพย์มันเป็นความรับผิดชอบ

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

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

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

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

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

อ่านเพิ่มเติมเกี่ยวกับการสลับที่นี่: https://martinfowler.com/articles/feature-toggles.html

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

เพียงเปลี่ยนชื่อของเมธอด (เช่นเปลี่ยนDoSomethingเป็นDoSomethingX) จากนั้นเรียกใช้บิลด์

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

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

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

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

การลบรหัสที่ไม่สามารถเข้าถึงได้

ในภาษาที่มีการพิมพ์แบบคงที่คุณควรทราบว่ารหัสนั้นสามารถเข้าถึงได้จริงหรือไม่: ลบ, รวบรวม, หากไม่มีข้อผิดพลาดมันไม่สามารถเข้าถึงได้

น่าเสียดายที่ไม่ใช่ทุกภาษาที่จะพิมพ์แบบคงที่และไม่ใช่ภาษาที่พิมพ์แบบคงที่ทั้งหมดจะมีหลักการ สิ่งที่อาจผิดพลาดได้ ได้แก่ (1) การไตร่ตรองและ (2) การบรรทุกเกินพิกัดที่ไม่มีหลักการ

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

หากคุณใช้ภาษาที่มีการโอเวอร์โหลดที่ไม่ได้คาดการณ์ไว้ดังนั้นเพียงแค่ลบการโอเวอร์โหลดก็สามารถเปลี่ยนความละเอียดของการโอเวอร์โหลดไปเป็นโอเวอร์โหลดอื่นได้อย่างเงียบ ๆ ภาษาดังกล่าวบางภาษาอนุญาตให้คุณตั้งโปรแกรมการเตือน / ข้อผิดพลาดเวลาคอมไพล์ที่เกี่ยวข้องกับการใช้งานรหัสมิฉะนั้นคุณไม่สามารถพึ่งพาคอมไพเลอร์ได้ ภาษาดังกล่าวรวมถึง Java (ใช้@Deprecated) หรือ C ++ (ใช้[[deprecated]]หรือ= delete)

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

คิวหัวข้อถัดไป ...

การลบรหัสที่อาจไม่ได้ใช้

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

ในกรณีนี้ไม่ว่าจะเป็นภาษาใดรหัสสามารถเข้าถึงได้และสามารถใช้เครื่องมือวัดระยะเวลาทำงานเท่านั้น

ในอดีตที่ผ่านมาฉันใช้วิธีการ 3 เฟสในการลบรหัสดังกล่าวสำเร็จ:

1. ในแต่ละสาขาที่สงสัยว่าจะไม่ได้รับการบันทึกคำเตือน
2. หลังจากหนึ่งรอบโยนข้อยกเว้น / คืนข้อผิดพลาดเมื่อป้อนชิ้นส่วนของรหัสที่เฉพาะเจาะจง
3. หลังจากรอบอื่นลบรหัส

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

หวังว่าแอปพลิเคชันส่วนใหญ่จะมีรอบการทำงานที่สั้นลง

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

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

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

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

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

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

IMHO ความคิดเห็นนั้นไม่จำเป็นและเป็นตัวเลือกสำหรับการลบ

บางทีคอมไพเลอร์ก็สังเกตเห็นว่ามันไม่ได้ทำให้ยุ่งยาก

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

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

หากไบนารีต่างกัน ... ก็ไม่สามารถสรุปได้ อาจเป็นการเปลี่ยนแปลงอื่น ๆ คอมไพเลอร์บางคนรวมถึงวันที่และเวลาในการรวบรวมในไบนารี่ (และอาจจะสามารถกำหนดค่าออกไป!)

ที่จริงฉันเพิ่งเจอสถานการณ์ที่แน่นอนด้วยวิธีการที่เรียกว่า "deleteFoo" ไม่มีที่ไหนใน codebase ทั้งหมดคือสตริงที่พบนอกเหนือจากการประกาศวิธีการ แต่ฉันอย่างชาญฉลาดเขียนบันทึกสายที่ด้านบนของวิธีการ

PHP:

public function deleteFoo()
{
    error_log("In deleteFoo()", 3, "/path/to/log");
}

ปรากฎว่าใช้รหัส! บางวิธี AJAX เรียกว่า "วิธีการ: ลบ elem = ฟู" ซึ่งมีการตัดแบ่งแล้วและเรียกว่ามีcall_user_func_array ()

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

ใช้grepหรือเครื่องมือใด ๆ ที่คุณมีอยู่ก่อนคุณอาจพบการอ้างอิงถึงรหัส (ไม่ใช่เดิมคำแนะนำ / คำแนะนำของฉัน)

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

คุณสามารถแก้ไขฟังก์ชั่น / บล็อกของรหัสเพื่อเขียนว่ามันถูกใช้ในล็อกไฟล์ หากไม่มีข้อความดังกล่าว "บันทึกไว้" ในไฟล์บันทึกคุณอาจลบรหัสบันทึกได้

ปัญหาสองประการ:

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

2. ติดตามผู้โทร ในภาษาระดับสูงบางภาษา (เช่น Python) คุณสามารถย้อนกลับได้อย่างง่ายดาย แต่ในภาษาที่รวบรวมคุณจะต้องบันทึกที่อยู่ผู้ส่งคืนลงในบันทึกและบังคับให้มีการถ่ายโอนข้อมูลหลักเมื่อออก (จุดที่ 1)
   ใน C นี้ควรจะค่อนข้างง่าย: ใช้บล็อกเงื่อนไข (เช่น. #ifdef ... #endif) เพื่อใช้เมื่อคุณรู้ว่ามันจะทำงาน (และได้ทดสอบว่ามัน) และเพียงแค่อ่านที่อยู่ผู้ส่ง จากสแต็ก (อาจหรืออาจต้องใช้ภาษาแอสเซมบลีแบบอินไลน์)

การบันทึกข้อโต้แย้งในไฟล์บันทึกอาจจะมีประโยชน์หรือไม่ก็ได้

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

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

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

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

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

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

แนวทางของฉันซึ่งฉันมักจะคิดว่าเป็นมาตรฐานอุตสาหกรรมในกรณีนี้แปลก ๆ ที่ยังไม่ได้กล่าวถึง:

รับดวงตาคู่ที่สอง

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

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

คำตอบง่ายๆสำหรับคำถามของคุณคือคุณไม่สามารถลบรหัสที่คุณไม่เข้าใจได้อย่างปลอดภัยซึ่งรวมถึงการไม่เข้าใจว่าจะถูกเรียกใช้อย่างไร จะมีความเสี่ยง

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

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

ในที่สุดคุณก็เข้าใจมันทิ้งไว้คนเดียวหรือใช้โอกาส

ในกรณีที่นักพัฒนาของรหัสในคำถามที่ยังคงมีอยู่, ตรวจสอบการกำจัดรหัสกับเขา นอกจากนี้อ่านความคิดเห็นในรหัส

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

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

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

การสนทนากับผู้เขียนอาจเปิดเผยว่ารหัสเป็นเศษประวัติของสิ่งที่ถูกลบออกหรือไม่เสร็จดังนั้นจึงปลอดภัยที่จะลบ

ฉันเห็นด้วยอย่างยิ่งกับจุดแรกของ Markus Lausberg: ควรวิเคราะห์รหัสด้วยความช่วยเหลือของเครื่องมือ สมองของลิงไม่น่าเชื่อถือกับงานประเภทนี้ !!

ภาษาโปรแกรมมาตรฐานส่วนใหญ่สามารถใช้ใน IDE และ IDE ทุกตัวที่ควรค่าแก่การเรียกว่ามีคุณสมบัติ "find for usages all usages" ซึ่งเป็นเครื่องมือที่เหมาะสมสำหรับสถานการณ์เช่นนี้ (Ctrl + Shift + G ใน Eclipse เป็นต้น)

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

ความเป็นไปได้สองอย่าง:

1. คุณมีการทดสอบครอบคลุม 99% + : ลบรหัสและใช้งานเสร็จ
2. คุณไม่มีการครอบคลุมการทดสอบที่น่าเชื่อถือ: จากนั้นคำตอบคือการเพิ่มคำเตือนการคัดค้าน นั่นคือคุณเพิ่มรหัสบางส่วนไปยังสถานที่ที่ทำสิ่งที่มีสติ (บันทึกคำเตือนไปยังสถานที่ที่มองเห็นได้ง่ายซึ่งไม่ขัดแย้งกับการใช้งานแอปพลิเคชันของคุณแบบวันต่อวัน) จากนั้นปล่อยให้มันหลนสองสามเดือน / ปี หากคุณไม่เคยพบเหตุการณ์ใด ๆ เกิดขึ้นให้แทนที่การคัดค้านด้วยสิ่งที่ทำให้เกิดข้อยกเว้น ปล่อยให้มันยืนอยู่พักหนึ่ง ในที่สุดลบทุกอย่างอย่างสมบูรณ์