ฉันเปลี่ยนลายเซ็นวิธีหนึ่งและตอนนี้มีข้อผิดพลาดมากกว่า 25,000 ข้อ เกิดอะไรขึ้น


166

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

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

ฉันไม่เคยประสบปัญหาเช่นนี้ในงานสุดท้ายของฉัน ฉันจะทำอย่างไร


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

137
"ข้อผิดพลาดมากกว่า 25,000 ข้อผิดพลาด" ตัวเลขดังกล่าวที่แสดงใน VS มักจะผิด มีข้อผิดพลาดเล็กน้อย แต่ด้วยการสร้าง dll ที่ใช้บ่อยทำให้การสร้างอื่น ๆ ล้มเหลวเช่นกันทำให้เกิดข้อผิดพลาดทางดาราศาสตร์ ฉันมักจะเริ่มแก้ไขด้วยข้อความแสดงข้อผิดพลาดครั้งแรกที่พบในผลลัพธ์ของการสร้างไม่ใช่ในรายการข้อผิดพลาด
Bernhard Hiller

13
ฉันต้องการดูลายเซ็นก่อนและหลังในวิธีการที่คุณเปลี่ยน BTW - ข้อผิดพลาด 25k ไม่ได้ฟังดูเหมือนมีจำนวนมากเกินกว่าที่จะจัดการได้ น่าเบื่อใช่น่ากลัวใช่จัดการไม่ได้
jmoreno

46
ส่วนต่อประสานสาธารณะเป็นสัญญา อย่าทำลายสัญญาดังกล่าว - สร้างสัญญาใหม่
แมทธิวอ่าน

6
ข้อผิดพลาด 25000! ฮูสตันเราเจอปัญหา ยกเลิกการเปลี่ยนแปลงและพูดคุยกับผู้จัดการของคุณอย่างแน่นอนและอธิบายกับเขาว่าคุณอาจต้องสร้างอินเทอร์เฟซใหม่ทั้งหมด
รหัส Whisperer

คำตอบ:


349

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

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


79
มันไม่จำเป็นต้องเป็นใหม่ระดับ มันอาจจะเป็นฟังก์ชั่น, อินเทอร์เฟซ, ลักษณะ ฯลฯ
Jan Hudec

33
นอกจากนี้ยังช่วยในกรณีที่อินเทอร์เฟซเก่าสามารถถูกแทนที่ด้วย wrapper ความเข้ากันได้รอบใหม่
Jan Hudec

79
บางครั้งข้อผิดพลาด 25000 ข้อจริงหมายถึงเราไม่เคยกล้าแตะต้อง แต่ตอนนี้มีผู้มาใหม่เข้ามาลองให้เขาทำความสะอาดคอกม้า Augean
mouviciel

13
@theDmi: ฉันเห็นด้วยการเปลี่ยนแปลง 1 ข้อและข้อผิดพลาด 25k น่าจะหมายถึงการเปลี่ยนแปลงมากที่สุด 2.5k และฉันไม่แปลกใจเลยที่จะพบว่ามันอยู่ที่ประมาณ 250 งานจำนวนมากทำงานอย่างใดอย่างหนึ่ง แต่ทำได้
jmoreno

33
ข้อผิดพลาด 25000 ทั้งหมดอาจแก้ไขได้ด้วยการเปลี่ยนแปลงเพียงครั้งเดียว ถ้าฉันแบ่งคลาสฐานของ heirarchy ขนาดใหญ่ทุกคลาสที่ได้รับจะคายข้อผิดพลาดเกี่ยวกับฐานที่ไม่ถูกต้องการใช้คลาสเหล่านั้นทั้งหมดจะคายข้อผิดพลาดเกี่ยวกับคลาสที่ไม่มีอยู่ ฯลฯ ลองจินตนาการว่าเป็น "getName" และฉันเพิ่ม ข้อโต้แย้ง การแทนที่ในคลาสการใช้งาน "HasAName" ตอนนี้ไม่ทำงาน (ข้อผิดพลาด) และทุกสิ่งที่สืบทอดมาจากตอนนี้จะสร้างข้อผิดพลาด (1,000 คลาสทั้งหมด) รวมถึงทุกครั้งที่ฉันสร้างอินสแตนซ์ของพวกเขา (24x ต่อคลาส) เฉลี่ย). การแก้ไขคือ ... หนึ่งบรรทัด
Yakk

80

แบ่งและพิชิตด้วย refactorings

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

หาร

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

พิชิต

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

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

ตัวอย่าง

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

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

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

บางครั้งมันก็ใช้ไม่ได้

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

น่าเสียดายที่มันไม่ทำงานหากการเปลี่ยนแปลงลายเซ็นซับซ้อนเกินไปและไม่สามารถแยกย่อยเป็นการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ ได้ แต่นี่เป็นของหายาก การแยกปัญหาออกเป็นปัญหาเล็กมักแสดงว่าเป็นไปได้


12
นี้. สร้างใหม่ถ้าคุณทำได้ (ปลอดภัย) มิฉะนั้นคุณต้องมีการย้ายที่ถูกต้อง
sleske

3
และสำหรับความรักในสิ่งใดก็ตามโปรดใช้ประโยชน์จากเครื่องมือการรีแฟคเตอร์ในตัวของ IDE แทนการเปลี่ยนลายเซ็นของเมธอด (เช่น) ในเครื่องจากนั้นจึงแก้ไขข้อผิดพลาดที่ตามมา
KlaymenDK

36

อธิบายงานของคุณกับเจ้านายของคุณเพื่อช่วยให้เขาเข้าใจปัญหาและความต้องการของคุณในฐานะนักพัฒนาซอฟต์แวร์มืออาชีพ

หากคุณเป็นส่วนหนึ่งของทีมค้นหานักพัฒนานำและขอคำแนะนำจากเขา

โชคดี.


15
นี่เป็นขั้นตอนแรกที่ฉันจะทำ - "ฉันเป็นรุ่นน้องและเจ้านายของฉันบอกให้ฉันทำอะไรสักอย่างและตอนนี้ฉันได้รับข้อความแสดงข้อผิดพลาดขนาดใหญ่จริง ๆ แต่เจ้านายของฉันไม่ได้บอกฉันเกี่ยวกับเรื่องนี้" ขั้นตอนที่ 1: "เฮ้เจ้านายฉันทำสิ่งนี้ แต่ฉันได้รับข้อผิดพลาด 25k ในตอนนี้นั่นเป็นสิ่งที่ควรจะเกิดขึ้นหรือ ... "
Pimgd

28

อย่าแตะต้องมัน อย่าทำอะไรเลย

ให้นั่งลงบนเก้าอี้แล้วตะโกนว่า "Heeeeelp !!!!!" ดังเท่าที่คุณสามารถ

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

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


2
นี่เป็นสิ่งสำคัญที่ต้องจำไว้อย่างแน่นอน หากพนักงานใหม่มีความทะเยอทะยานถึงระดับมากพวกเขาอาจอุตสาหะ (ใจง่าย) มากพอที่จะทำภารกิจที่ยิ่งใหญ่ซึ่งจบลงด้วยการได้รับข้อได้เปรียบของหน่วยความจำ 5 ไบต์เท่านั้น
The Great Duck

@TheGreatDuck: บอกฉันว่าคุณไม่เคยเห็นอินเทอร์เฟซที่ใช้ทุกที่และผิดทุกที่ ฉันแน่ใจว่ามี
Joshua

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

1
@Joshua btw ฉันเข้าร่วมชุมชนนี้เพียงเพราะคำถามนี้เข้ามาในฟีดคำถามยอดนิยมของฉัน ฉันไม่มีประสบการณ์กับการออกแบบขนาดใหญ่เช่นนี้ ฉันเห็นด้วยกับมุมมองของบุคคลนี้
The Great Duck

22

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


10

ประเมินผล

ประเมินว่าการเปลี่ยนแปลงนี้จำเป็นหรือไม่หรือคุณสามารถเพิ่มวิธีการใหม่และเลิกใช้วิธีอื่นได้

ข้างหน้า

หากจำเป็นต้องเปลี่ยนแปลง ดังนั้นจึงจำเป็นต้องมีแผนการโยกย้าย

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

นี่คือจุดกระทำ: ตรวจสอบว่าการทดสอบทั้งหมดผ่านกระทำส่ง

โยกย้าย

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

ดังนั้นไปข้างหน้า; อย่าลังเลที่จะใช้เครื่องมือเพื่อช่วยเหลือ ( sedเป็นพื้นฐานที่สุดมีคนอื่น)

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

นี่คือจุดกระทำ (หรืออาจจะหลายจุดกระทำ): ตรวจสอบว่าการทดสอบทั้งหมดผ่านกระทำกระทำผลัก

เอาออก

หลังจากเวลาผ่านไป (อาจจะน้อยวัน) เพียงแค่ลบวิธีการเก่า


4
sedอาจเป็นความคิดที่ไม่ดี ... สิ่งที่จริง "เข้าใจ" ภาษาและจะไม่ทำการเปลี่ยนแปลงที่รุนแรงโดยไม่ตั้งใจจะดีกว่า
wizzwizz4

1
@ wizzwizz4: น่าเสียดายที่ฉันพบเครื่องมือน้อยมากที่เข้าใจภาษาดีพอสำหรับ C ++; เครื่องมือส่วนใหญ่ดูเหมือนจะตอบสนองต่อการเปลี่ยนชื่อและนั่นคือ ได้รับการเปลี่ยนชื่อเฉพาะการเรียกใช้เมธอดที่แน่นอน (และไม่ใช่การเรียกเมธอดที่มากเกินไปหรือไม่เกี่ยวข้อง แต่มีชื่อคล้ายกัน) นั้นน่าประทับใจอยู่แล้ว แต่ก็ไม่เพียงพอสำหรับสิ่งที่ซับซ้อนกว่า อย่างน้อยที่สุดคุณจะต้องมีความสามารถในการ (1) การโต้แย้งแบบสุ่ม (2) นำการแปลงไปใช้กับการโต้แย้งที่กำหนด (เรียก.c_str()ตัวอย่าง) และแนะนำอาร์กิวเมนต์ใหม่ sedทำงานแล้วคอมไพเลอร์ก็จับประเด็นของมันหลังจากนั้น
Matthieu M.

1
sed(หรือed) อาจเพียงพอสำหรับสิ่งนี้ - ตราบใดที่คุณตรวจสอบความแตกต่างอย่างถูกต้องก่อนที่คุณจะยอมรับ
Toby Speight

นี่คือ TCRR ของ html ใช่ไหม :)
Daniel Springer

8

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

ฉันคิดว่าคุณได้แก้ไขรหัสด้วยตนเองซึ่งทำให้เกิดข้อผิดพลาดทั้งหมด ฉันคิดว่าคุณคุ้นเคยกับ Java (เห็นการอ้างอิงของคุณกับ OSGi) ดังนั้นใน Eclipse (ฉันไม่ทราบว่าคุณใช้สภาพแวดล้อมการเขียนโปรแกรมใด แต่สภาพแวดล้อมอื่นมีเครื่องมือ refactoring คล้ายกัน) คุณสามารถใช้ "Refactoring -> Rename" เพื่ออัปเดตการอ้างอิงทั้งหมดไปยังวิธีการซึ่งจะทำให้คุณไม่มีข้อผิดพลาด

ในกรณีที่คุณทำการเปลี่ยนแปลงอื่น ๆ กับวิธีการที่เป็นลายเซ็นมากกว่าเพียงแค่เปลี่ยนชื่อ (เปลี่ยนจำนวนหรือชนิดของพารามิเตอร์) คุณสามารถใช้ "Refactoring -> Change method Signature" อย่างไรก็ตามโอกาสที่คุณจะต้องระวังให้มากขึ้นเป็นคำตอบอื่น ๆ ที่แนะนำ นอกจากนี้ไม่ว่าประเภทของการเปลี่ยนแปลงจะยังคงเป็นงานที่ค่อนข้างยอมรับการเปลี่ยนแปลงทั้งหมดในฐานรหัสไม่ว่าง


2
OP กล่าวโดยเฉพาะว่า OSGi อยู่ที่งานก่อนหน้านี้ดังนั้นจึงไม่เกี่ยวข้องกับที่นี่จริงๆ
CVn

3
@ MichaelKjörlingหาก OP เป็นโปรแกรมเมอร์ Java ในงานก่อนหน้าของพวกเขามีโอกาสที่ดีกว่าพวกเขาเป็นโปรแกรมเมอร์ Java ในงานนี้ด้วย
รวย

@ MichaelKjörlingฉันต้องการให้คำแนะนำที่เป็นรูปธรรมโดยใช้ Eclipse สำหรับการปรับโครงสร้างใหม่เนื่องจาก OP คุ้นเคยกับ Java ไม่ว่า OP จริง ๆ แล้วใช้ Java สำหรับโครงการปัจจุบันหรือไม่ฉันเดาว่าสำคัญน้อยกว่า แต่ฉันควรชี้แจงคำตอบของฉันให้ชัดเจน ขอบคุณ
MikkelRJ

6

นี่คือผลงานของฉัน

ฉันเพิ่งเริ่มงานใหม่เมื่อไม่นานมานี้ซึ่งฉันกำลังทำงานกับแอปพลิเคชันขนาดใหญ่มาก (รหัส 15M บรรทัด)

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

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

ตามที่ @Greg ชี้ให้เห็นคุณควรจะสามารถทดสอบรหัสที่มีอยู่เพื่อให้มีการอ้างอิงที่ถูกต้องเพื่อเปรียบเทียบกับ (การทดสอบการถดถอย) โซลูชันของคุณควรสามารถสร้างผลลัพธ์ที่เหมือนกันมากกว่าผลลัพธ์ที่มีอยู่เดิม ในขั้นตอนนี้คุณไม่สนใจเกี่ยวกับหรือไม่ว่าผลลัพธ์ที่มีสิทธิ เป้าหมายแรกคือการสร้างใหม่ไม่ใช่เพื่อแก้ไขข้อบกพร่อง หากโซลูชันที่มีอยู่บอกว่า "2 + 2 = 42" โซลูชันของคุณก็ควรจะเช่นกัน หากไม่ส่งข้อยกเว้นคุณไม่ควรทำเช่นนั้น ถ้ามันคืนค่า null คุณควรคืนค่าเป็นโมฆะด้วย และอื่น ๆ มิฉะนั้นคุณจะยอมลดจำนวนบรรทัด 25k

นี่คือ เพื่อประโยชน์ของความเข้ากันได้ย้อนยุค

ทำไม? เพราะตอนนี้มันเป็นเครื่องรับประกันที่เป็นเอกลักษณ์ของคุณในการปรับโครงสร้างที่ประสบความสำเร็จ

และหลายหน่วยทดสอบการอ้างอิงโดยตรงว่าอินเตอร์เฟสหรือเชื่อมต่อกับคลาสพื้นฐานซึ่งอ้างอิงอินเตอร์เฟสนั้น

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

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

เมื่อคุณออกแบบและใช้งาน "สัญญา" ใหม่แล้วให้แทนที่สัญญาเก่า เลิกใช้หรือถอดออก

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

บรรทัดรหัส 25k ดูเหมือนว่าฉันมีปัญหามากพอที่จะทำให้ฉันมุ่งเน้นไปที่งานเดียวเท่านั้น

เมื่องานแรกของคุณเสร็จสิ้น เปิดเผยบั๊ก / ฟีเจอร์เหล่านั้นกับเจ้านายของคุณ

ในที่สุดตามที่ @Stephen ได้บอก:

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


5

ทดสอบมัน

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

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

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