คำถามติดแท็ก dry

เมื่อใดก็ตามที่ฉันเขียนการทดสอบหน่วยฉันมักจะพยายามยืนยันเพียงครั้งเดียวต่อการทดสอบเพื่อให้การดีบักง่ายขึ้นเมื่อการทดสอบล้มเหลว อย่างไรก็ตามเมื่อฉันทำตามกฎนี้ฉันรู้สึกว่าฉันกำลังคัดลอกรหัสเดียวกันในการทดสอบแต่ละครั้งอย่างต่อเนื่องและด้วยการทดสอบเพิ่มเติมมันจะยากที่จะกลับไปอ่านและบำรุงรักษา ดังนั้นการทดสอบแบบยืนยันเพียงครั้งเดียวจึงเป็นการละเมิด DRY หรือไม่ และมีกฎที่ดีหรือไม่ที่จะต้องปฏิบัติตามเพื่อหาสมดุลที่ดีเช่นเดียวกับการทดสอบหนึ่งวิธีต่อหนึ่งวิธี * * ฉันรู้ว่าอาจไม่ได้มีขนาดเดียวที่เหมาะกับการแก้ปัญหาทั้งหมดนี้ แต่มีวิธีแนะนำให้ใช้วิธีนี้หรือไม่

12 testing  unit-testing  dry 

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

11 testing  dry 

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

11 agile  documentation  architecture  dry 

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

10 language-agnostic  refactoring  dry  cqrs 

ตอนนี้ฉันกำลังดิ้นรนกับแนวคิด DRY (อย่าทำซ้ำตัวเอง) ในการเขียนโค้ดของฉัน ฉันกำลังสร้างฟังก์ชั่นนี้ซึ่งฉันกลัวว่ามันจะซับซ้อนเกินไป แต่ฉันพยายามทำตามหลักการของ DRY createTrajectoryFromPoint(A a,B b,C c,boolean doesSomething,boolean doesSomething2) ฟังก์ชั่นนี้ผมจะพูดจะใช้เวลาป้อนพารามิเตอร์ 3 แล้วการทำงานจะทำบางสิ่งบางอย่างที่แตกต่างกันเล็กน้อยที่ได้รับการผสมบูลและdoesSomething doesSomething2อย่างไรก็ตามปัญหาที่ฉันมีคือฟังก์ชั่นนี้เพิ่มขึ้นอย่างซับซ้อนด้วยพารามิเตอร์บูลีนใหม่ทุกตัวที่เพิ่มเข้ามา ดังนั้นคำถามของฉันคือดีกว่าที่จะมีฟังก์ชั่นต่าง ๆ มากมายที่ใช้ตรรกะเดียวกันจำนวนมาก (ดังนั้นละเมิดหลักการ DRY) หรือฟังก์ชั่นหนึ่งที่ทำงานแตกต่างกันเล็กน้อยตามจำนวนพารามิเตอร์ แต่ทำให้ซับซ้อนมากขึ้น (แต่ รักษา DRY) หรือไม่

10 java  design  dry 

ในภาษา OO (เช่น แต่ไม่ จำกัด เฉพาะ Java) คุณจะแก้ไขโค้ดที่ซ้ำกันอย่างไรโดยขึ้นอยู่กับขอบเขตของการเกิดขึ้น ฉันจะเริ่มต้นด้วย (ตัวอย่าง) ในคลาสเดียวกัน (ขอบเขต) ทำการแยกวิธีการแตกไฟล์ (แก้ไข) ในชั้นเรียนของลำดับชั้นเดียวกัน (ขอบเขต) ดำเนินการวิธีการแยกและดึงขึ้น (แก้ไข) ...

10 object-oriented  dry 

ฉันแน่ใจว่ามีชื่อสำหรับรูปแบบการต่อต้านนี้อยู่ที่ไหนสักแห่ง; อย่างไรก็ตามฉันไม่คุ้นเคยกับวรรณกรรมต่อต้านรูปแบบที่จะรู้ พิจารณาสถานการณ์สมมติต่อไปนี้: 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 …

10 terminology  anti-patterns  dry 

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

9 object-oriented-design  class-design  abstraction  code-reuse  dry 

ฉันต้องการเขียน Javadoc ด้วยวิธี DRY แต่เอกสาร oracle เกี่ยวกับJavadocกล่าวว่าเขียนสิ่งเดียวกันอีกครั้งในความคิดเห็นของเมธอด overload ฉันไม่สามารถหลีกเลี่ยงการทำซ้ำได้หรือไม่

9 documentation  comments  dry  javadocs