ประเด็นสำคัญของการทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดกคืออะไร [ปิด]

ฉันเคยเห็นหนังสือทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดกแนะนำสองสามครั้ง ประเด็นสำคัญของหนังสือเล่มนี้คืออะไร?

มีการจัดการกับรหัสดั้งเดิมมากกว่าการเพิ่มการทดสอบหน่วย / การรวมและการเปลี่ยนโครงสร้างอีกครั้งหรือไม่

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

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

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

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

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

• การตรวจจับ - เพื่อตรวจสอบและตรวจสอบผลกระทบของการเรียกใช้โค้ดบางส่วนและ
• การแยก - เพื่อให้ได้รหัสชิ้นส่วนที่เฉพาะเจาะจงลงในสายรัดทดสอบก่อนอื่น

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

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

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

วิธีที่รวดเร็วในการรับประเด็นสำคัญของการทำงานอย่างมีประสิทธิภาพด้วยรหัสดั้งเดิม

• อ่านPDF 12 หน้าของ Michael Feathers เขียนขึ้นก่อนหนังสือสองปี
• ดูการนำเสนอของ Michael Feathers: 68 สไลด์
• ฟังบทสัมภาษณ์พอดคาสต์กับ Michael Feathers เช่นนี่30 นาทีตอน

ฉันทำงานบนฐานของโค้ดหลายล้านบรรทัดบางย้อนหลังไปถึงปี 1980 มันเป็นแค่ซอฟต์แวร์ดังนั้นมันเป็นเรื่องของการเขียนการทดสอบสองสามบทดังนั้นคุณสามารถไปและปรับโครงสร้างใหม่และทำให้ดีขึ้นมาก

คำสำคัญที่นี่เป็นเพียง - เป็นคำสี่ตัวอักษรที่ไม่ได้อยู่ในคำศัพท์ของโปรแกรมเมอร์ใด ๆ ให้คนเดียวที่ทำงานในระบบมรดก

คุณคิดว่าต้องใช้เวลานานเท่าใดในการเขียนการทดสอบหน่วยเพื่อทดสอบความพยายามในการพัฒนาหนึ่งชั่วโมง เพื่อการอภิปรายลองพูดอีกชั่วโมง

ใช้เวลาเท่าไหร่ในการลงทุนระบบล้านมรดก 20 ปี สมมติว่านักพัฒนา 20 คนสำหรับ 20 ปีคูณ 2,000 ชั่วโมง / ปี (พวกเขาทำงานหนักมาก) ลองเลือกตัวเลข - คุณมีคอมพิวเตอร์เครื่องใหม่และเครื่องมือใหม่และคุณฉลาดกว่าพวกที่เขียนแผ่นนี้ $% ^^ ในตอนแรก - สมมติว่าคุณมีค่าเท่ากับ 10 คุณมี 40 คนปีแล้วคุณมี ...

ดังนั้นคำตอบสำหรับคำถามของคุณคือมีมากขึ้น ตัวอย่างเช่นรูทีนที่มี 1,000 บรรทัด (ฉันมีน้อยกว่า 5000) มันซับซ้อนเกินไปและเป็นปาเก็ตตี้ชิ้นหนึ่ง มันจะ (เพียงอีกสี่ตัวอักษรคำ) ใช้เวลาสองสามวันในการพิจารณาปัจจัยอีกครั้งในกิจวัตร 100 บรรทัดและผู้ช่วยอีก 20 บรรทัดใช่ไหม? ไม่ถูกต้อง. ที่ซ่อนอยู่ใน 1,000 เส้นนั้นคือการแก้ไขข้อบกพร่อง 100 ข้อแต่ละข้อมีความต้องการของผู้ใช้ที่ไม่มีเอกสารหรือตัวพิมพ์ขอบที่ไม่ชัดเจน เป็น 1,000 บรรทัดเพราะรูทีน 100 บรรทัดดั้งเดิมไม่ทำงาน

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

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

มีสองประเด็นสำคัญที่จะนำออกไปจากหนังสือเล่มนี้

1. รหัสดั้งเดิมคือรหัสใด ๆ ที่ไม่มีการครอบคลุมการทดสอบ
2. เมื่อใดก็ตามที่คุณต้องเปลี่ยนรหัสดั้งเดิมคุณควรตรวจสอบให้แน่ใจว่ามีรหัสครอบคลุม

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

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

แต่หนังสือเล่มนี้ให้เทคนิคที่แตกต่างมากมายให้คุณทำเช่นนั้นด้วยโค้ดที่ยากต่อการทดสอบและการรีแฟคเตอร์อย่างปลอดภัย