การละเมิดหลักการแห้ง


10

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

พิจารณาสถานการณ์สมมติต่อไปนี้:

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

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

ดังนั้นฉันมีคำถามสองสามข้อ:

1. ) มีชื่อสำหรับรูปแบบการต่อต้านนี้หรือไม่? ฉันเคยเห็นสิ่งนี้เกิดขึ้นบ่อยครั้งฉันพบว่ามันยากที่จะเชื่อว่านี่ไม่ใช่การต่อต้านแบบ

2. ) ฉันเห็นทางเลือกไม่กี่อย่าง:

a.) แก้ไขorNเพื่อรับพารามิเตอร์ที่ระบุค่าของตัวแปรสมาชิกทั้งหมดที่ต้องการ จากนั้นแก้ไขcNเพื่อโทรorNด้วยพารามิเตอร์ที่จำเป็นทั้งหมดที่ส่งผ่านเข้ามา

ข.) พยายามที่จะแก้ไขพอร์ตด้วยตนเองจากการorN cN(ใจคุณฉันไม่ต้องการทำสิ่งนี้ แต่เป็นไปได้จริง)

c.) คัดลอกorNไปที่cN--again, yuck แต่ฉันเขียนเพื่อความสมบูรณ์

d.) พยายามที่จะคิดออกที่เสียแล้วซ่อมอิสระจาก cNorN

ทางเลือกที่ดูเหมือนว่าการแก้ไขที่ดีที่สุดในระยะยาว แต่ฉันสงสัยว่าลูกค้าจะให้ฉันใช้มัน ไม่เคยมีเวลาหรือเงินเพื่อแก้ไขสิ่งที่ถูกต้อง แต่เวลาและเงินเพื่อแก้ไขปัญหาเดียวกันเสมอ 40 หรือ 50 ครั้งใช่ไหม

ใครช่วยแนะนำวิธีการอื่น ๆ ที่ฉันอาจไม่ได้พิจารณา?


"มีชื่อสำหรับรูปแบบการต่อต้านนี้หรือไม่" ต่อต้าน 'รูปแบบแห้ง' ต่อต้านรูปแบบ? :) IMHO คุณตอบด้วยตัวเอง
Steven Jeuris

อาจจะเรียกมันว่า "The Dry Violator"
FrustratedWithFormsDesigner

2
ฉันเรียกมันว่า: DRY กระแทก
AJC

5
คัดลอกและวางโค้ด?
tylermac

มันถูกเรียกว่า "พ่อครัวมากเกินไปทำให้เสียน้ำซุป" รูปแบบ
Doc Brown

คำตอบ:


18
  1. มันเรียกว่ารหัสซ้ำ - ฉันไม่รู้ชื่อแฟนซีอีกต่อไปสำหรับสิ่งนี้ ผลกระทบระยะยาวเป็นไปตามที่คุณอธิบายและแย่ลง

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

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

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


3
+1 หากไม่เพียง แต่สำหรับการกล่าวถึงของรหัสที่ซ้ำกัน แต่สำหรับความพยายามอย่างเต็มที่ที่เกี่ยวข้องกับเรื่องราวของการปรับเปลี่ยนรหัส : D
Andreas Johansson

9

มีการอ้างอิงถึงรูปแบบWET (We Enjoy Typing) แต่ฉันไม่รู้ว่าเป็นชื่อมาตรฐานหรือไม่

... การอนุญาตให้ใช้สิทธิ์ซอฟต์แวร์ถือเป็นข้อยกเว้นที่น่าทึ่งสำหรับแนวทางปฏิบัติ DRY (อย่าซ้ำตัวเอง) - รหัสสิทธิ์ใช้งานซอฟต์แวร์ควรเป็น WET (We Enjoy Typing - ซึ่งตรงกันข้ามกับ DRY) เท่าที่จะทำได้

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

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


3
WET อาจหมายถึง: เขียนทุกอย่างสองครั้ง
StuperUser

1
@StuperUser ฉันค้นพบว่าในทุกวันเมื่อวานนี้ ...
jeremy-george

3

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

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

สิ่งนี้เรียกว่า refactor นอกจากนี้ยังปรากฏว่ามีการเขียนรหัสโดยไม่มีการออกแบบล่วงหน้า ดูการพัฒนา Test Driven เขียนรหัสว่าควรเรียกใช้อย่างไรแทนที่จะเรียกใช้รหัส แต่มีการนำไปใช้ ดูTDDสำหรับคำแนะนำเกี่ยวกับวิธีการทำงานให้สำเร็จ


3

หากคุณกำลังคัดลอกรหัสคุณจะแนะนำหนี้ทางเทคนิคของการบำรุงรักษาคู่หรือมากขึ้นโดยเฉพาะ: การทำสำเนารหัส

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

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


1

ฟังดูเหมือนรหัสสปาเก็ตตี้สำหรับฉัน การแก้ไขที่ดีที่สุดคือ refactor / rewrite

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

http://upload.wikimedia.org/wikipedia/commons/thumb/9/93/Spaghetti.jpg/175px-Spaghetti.jpg


-1 Refactor และ rewrite เป็นสองตัวเลือกที่แตกต่างกันมาก การเขียนซ้ำทั้งหมดทิ้งซอฟต์แวร์ไปไม่ใช่ความคิดที่ดี joelonsoftware.com/articles/fog0000000069.html
P.Brian.Mackey

1
รหัสสปาเก็ตตี้นั้นเป็น IMO ที่กว้างกว่าและยาวกว่า แม้ว่ารหัสดังกล่าวมักจะมีการพิมพ์ซ้ำกัน แต่คุณสามารถมีรหัสสปาเก็ตตี้ได้โดยไม่ต้องทำซ้ำและยังมีการทำสำเนาสูง แต่ไม่ใช่สปาเก็ตตี้
PéterTörök

@ P.Brian.Mackey ฉันไม่เคยพูดว่า Refactor และเขียนใหม่เป็นสิ่งเดียวกัน OP ควรตัดสินใจว่าจะใช้
Tom Squires

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

@ jhocking - ฉันเชื่อว่านโยบายที่ไม่เขียนซ้ำไม่ใช่การบล็อกความคืบหน้าในโปรแกรมอื่น แต่เป็นการสูญเสียการแก้ไขที่แท้จริงตลอดเวลา ขลัง "ถ้า (GoldenNugget> 22)" ในขณะที่ชื่อไม่ดียังคงแก้ปัญหาเฉพาะที่อาจเป็นไปไม่ได้ที่จะระบุโดยไม่ต้องวิจัยหรือไม่กี่ชั่วโมง ตอนนี้รับข้อมูลเดียวกันและปรับปรุงมันเป็นสิ่งที่ควรทำแทน นั่นคือ refactor การขว้างมันออกไปและพูดว่า "เราจะทำในครั้งต่อไป" เป็นการเสียเวลาเปล่า เหตุผลเดียวกันในการแก้ไขปัญหาที่แก้ไขไปแล้วนั้นเป็นการเสียเวลา เพิ่มรหัสที่ดีด้านบนของหนี้ที่เพิ่มขึ้นที่ไม่ดี
P.Brian.Mackey

0

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

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

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


-3

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

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


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