วิธีแก้ไขสำเนา / วางรูปแบบ?

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

ไม่ใช่เรื่องง่ายที่จะป้องกันสิ่งนี้เนื่องจากฐานรหัสเปิดให้ทั้ง บริษัท ผู้คนจำนวนมากทำงานเกี่ยวกับเรื่องนี้

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

ส่วนหนึ่งของคำตอบคือRefactoring

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

อีกส่วนหนึ่งคือการศึกษา

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

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

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

ในฐานะส่วนหนึ่งของการศึกษาอย่าง @Peter กล่าวว่าคุณสามารถแนะนำตัวตรวจจับการคัดลอกและวางอย่างPMDและใช้เป็นส่วนหนึ่งของงานสร้างของคุณเพื่อช่วยในการบังคับใช้ส่วนนี้ของมาตรฐานการเข้ารหัสของคุณ

ตรวจสอบให้แน่ใจว่าโครงการเข้ารหัสมาตรฐานของคุณครอบคลุมรูปแบบนี้เพื่อให้คุณมีพื้นฐานในการเริ่มการสนทนา

ผู้คน (ที่ปรึกษา) รู้สึกว่าถูกกดเพื่อปล่อยคุณลักษณะโดยเร็วที่สุด

คุณไม่มีปัญหาทางเทคนิคคุณมีปัญหาสังคม แน่นอนคุณมีปัญหาด้านการจัดการ

ไม่ใช่เรื่องง่ายที่จะป้องกันสิ่งนี้เนื่องจากฐานรหัสเปิดให้ทั้ง บริษัท ผู้คนจำนวนมากทำงานเกี่ยวกับเรื่องนี้

"ฐานรหัสเปิดให้ทั้ง บริษัท " ไม่ใช่ปัญหา ไม่เป็นไร

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

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

คุณต้อง

1. เริ่มต้นที่ด้านบนด้วยผู้จัดการที่เสริมรางวัล คุณต้องเปิดเผยแนวปฏิบัติปัจจุบันและบันทึกต้นทุนและความเสี่ยง คุณต้องเสนอทางเลือกอื่นที่ช่วยลดต้นทุนและความเสี่ยง

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

3. คุณจะต้องช่วยผู้จัดการให้เครดิตแนวทางใหม่ซึ่งจะทำให้พวกเขาดูดีและคุณจะถูกเพิกเฉย

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

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

วันนี้ฉันต้องเพิ่มคุณสมบัติอื่นและฉันก็ไม่สามารถใช้มันได้อีก ฉันสร้างห้องสมุดใหม่รวมฟังก์ชั่น 100 + เป็น 10 reentrant ฟังก์ชั่นที่เปลี่ยนพฤติกรรมของพวกเขาเล็กน้อยตามบิตธงแล้วเขียนชุดการทดสอบเพื่อให้แน่ใจว่าการเปลี่ยนแปลงใด ๆ ในห้องสมุดนั้นไม่ทำลายอะไรเลย

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

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

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

ฉันเห็นด้วยกับคำตอบที่ได้รับจนถึง คุณควร:

• สร้างการทดสอบหน่วย
• ปรับปรุงโครงสร้าง
• ให้ความรู้
• ใช้ความพยายามในมาตรฐานการเข้ารหัสและตรวจจับการละเมิด

แต่ในอีกแง่หนึ่งคุณต้องดูว่าอะไรทำให้คนลอกเลียนแบบและแก้ไข

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

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

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

อ่านแนวทางการออกแบบกรอบ

หวังว่านี่จะช่วยได้

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

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

ฉันกังวลกับปัญหาเดียวกันที่นี่และสิ่งที่ฉันทำคือ: อย่าพยายามหลีกเลี่ยงสิ่งนั้นล่วงหน้าเพียงแค่สร้างใหม่เมื่อมันแย่เกินไป

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

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

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

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

วิธีเดียวที่จะกำจัดรหัสคัดลอก / วางคือ (IMHO) การตรวจสอบรหัสมีบุคคล (หรือมากกว่า) เพื่อตรวจสอบรหัสและเมื่อพวกเขาพบรหัสที่ดูเหมือนว่าจะมาจากการกระทำการคัดลอก / วางปล่อยให้โปรแกรมเมอร์ refactor

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

@Anders K. ความคิดเห็นเป็นวิธีที่ดีในการฝึกฝน เมื่อบังคับให้คนเขียนโค้ดพวกเขาไม่เชื่อในมันจะสร้างแรงเสียดทานมากมาย พวกเขาจะถอยกลับไปในกระต่ายเก่าแก่เร็วที่สุดเท่าที่จะทำได้ ฉันเชื่อมั่นว่าคุณควรเริ่มต้นจากการศึกษาเพื่อรับแรงผลักดัน