การลดการกระแทกซ้ำและการทำความสะอาดโค้ดของเลอะเทอะขณะรอความต้องการ


17

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

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

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

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

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

คุณสามารถนึกถึงผลกระทบเชิงบวกหรือเชิงลบของฉันที่ทำสิ่งนี้ที่คุณต้องการเพิ่มหรือไม่?


1
กอบกู้สิ่งที่ควรค่าแก่การกอบกู้เขียนส่วนที่เหลือ ...
เอสเอฟ

"เป็นเรื่องยากมากที่ฉันประสบปัญหาความล้มเหลวทางเทคนิคของโครงการเมื่อเทียบกับความล้มเหลวในการจัดการโครงการ [... ]" สิ่งนี้เป็นความจริงอย่างไร +1
Gregory Higley

คำตอบ:


22

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

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

ฉันไม่เห็นผลกระทบเชิงลบใด ๆ คุณจะได้รับความเข้าใจอย่างลึกซึ้งเกี่ยวกับฐานของรหัสซึ่งจะช่วยในการปรับโครงสร้างให้ใหญ่ขึ้น มันมักจะดีกว่า refactor กว่าที่จะเขียนใหม่เนื่องจากในระหว่าง refactoring ของคุณยังคงมีผลิตภัณฑ์ที่ใช้งานได้ในขณะที่ในระหว่าง rewrite คุณไม่ได้ และในที่สุดการขายสินค้าจะต้องจ่ายเงินเดือนของคุณ

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


ฉันชอบคำตอบนี้จริงๆ ฉันต้องการความเข้าใจที่ลึกซึ้งยิ่งขึ้นเกี่ยวกับรหัสฐานและวัวเงินสดจ่ายเงินเดือนของฉันและยังช่วยให้เราสามารถทำงานในโครงการใหม่ที่ดีกว่าสำหรับลูกค้ารายอื่น ๆ ที่ฉันได้รับโอกาสเริ่มต้นจากศูนย์และทำตั้งแต่เริ่มต้น
maple_shaft

10

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


2
เริ่มจากคนง่าย ๆ แล้วเริ่มหาทาง?
tdammers

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

2
หากรหัสไม่ได้รับการออกแบบสำหรับการทดสอบนั่นคือเหตุผลทั้งหมดที่จะได้รับการทดสอบรอบตัว - แต่ปลอดภัย อ่านหนังสือของ Michael Feathers 'การทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดก'; มันมีสูตรการทำโค้ดที่ทดสอบไม่ได้
Joe White

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

1
มันต้องใช้ประสบการณ์และการตัดสินที่ดี ไม่ใช่ทุกสิ่งที่สามารถทำ (หรือควร) ทำหน่วยทดสอบได้
tdammers

1

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

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

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.