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

หลักการ DRY ระบุว่า "ความรู้ทุกชิ้นต้องมีการแสดงผลที่ชัดเจน ไม่คลุมเครือ และมีอำนาจเพียงหนึ่งเดียวภายในระบบ" หลักการนี้ได้รับการกำหนดโดยAndy HuntและDave ThomasในหนังสือThe Pragmatic Programmerของ พวกเขา ^{[ 1 ]}พวกเขานำไปใช้อย่างกว้างขวางเพื่อรวมถึงสคีมาฐานข้อมูลแผนการทดสอบระบบการสร้างและแม้แต่เอกสาร[ ^{2 ] เมื่อ} นำหลักการ DRY ไปใช้อย่างประสบความสำเร็จ การแก้ไของค์ประกอบใดองค์ประกอบหนึ่งของระบบจะไม่จำเป็นต้องเปลี่ยนแปลงองค์ประกอบอื่นที่ไม่เกี่ยวข้องทางตรรกะ นอกจากนี้ องค์ประกอบที่เกี่ยวข้องทางตรรกะทั้งหมดจะเปลี่ยนแปลงอย่างคาดการณ์ได้และสม่ำเสมอ จึงทำให้ระบบอยู่ในสถานะซิงค์กันนอกจากการใช้วิธีการและซับรูทีนในโค้ดแล้ว Thomas และ Hunt ยังอาศัยตัวสร้างโค้ดระบบการสร้างอัตโนมัติ และภาษาสคริปต์เพื่อปฏิบัติตามหลักการ DRY ในทุกระดับ

กรณีเฉพาะของ DRY คือหลักการเลือกเพียงทางเดียวเบอร์ทรานด์ เมเยอร์ ได้นิยามหลักการนี้ ไว้ว่า: "เมื่อใดก็ตามที่ระบบซอฟต์แวร์ต้องรองรับชุดทางเลือก โมดูลเพียงโมดูลเดียวในระบบเท่านั้นที่ควรทราบรายการทางเลือกทั้งหมด" ^{[ 3 ]}หลักการนี้ถูกนำไปใช้ในการออกแบบ Eiffel

มุมมองที่ตรงข้ามกับ DRY เรียกว่า WET ซึ่งเป็นคำย่อที่มักใช้แทนคำว่าwrite everything twice ^{[ 4 ]} (หรืออีกนัยหนึ่งคือเขียนทุกครั้งเราชอบพิมพ์หรือเสียเวลาทุกคน ) โซลูชัน WET เป็นเรื่องปกติในสถาปัตยกรรมแบบหลายชั้น ซึ่งนักพัฒนาอาจได้รับมอบหมายให้เพิ่มช่องแสดงความคิดเห็นในแบบฟอร์มในเว็บแอปพลิเคชัน ตัวอย่างเช่น ข้อความ "comment" อาจถูกทำซ้ำในป้ายกำกับ แท็ก HTML ชื่อฟังก์ชันการอ่าน ตัวแปรส่วนตัว DDL ของฐานข้อมูล การสืบค้น และอื่นๆ แนวทาง DRY จะกำจัดความซ้ำซ้อนนั้นโดยใช้เฟรมเวิร์กที่ลดหรือกำจัดงานแก้ไขทั้งหมด ยกเว้นงานที่สำคัญที่สุด ทำให้สามารถเพิ่มตัวแปรความรู้ใหม่ได้ในที่เดียว^{[ 5 ]} แนวคิดของ "WET" ในฐานะทางเลือกแทนการเขียนโปรแกรม "DRY" นี้มีมาตั้งแต่ปี 2002 เป็นอย่างน้อยในโลกของ Java แม้ว่าจะไม่ทราบว่าใครเป็นผู้คิดค้นคำนี้^{[ 6 ]}

แนวทางอื่นในการสร้างนามธรรมคือการหลีกเลี่ยงการสร้างนามธรรมแบบเร่งรีบ (AHA) AHA มีรากฐานมาจากความเข้าใจที่ว่ายิ่งวิศวกรลงทุนลงแรงในการสร้างนามธรรมของซอฟต์แวร์มากเท่าไร พวกเขาก็ยิ่งรู้สึกว่าต้นทุนของการลงทุนนั้นไม่สามารถกู้คืนได้ ( ความผิดพลาดของต้นทุนจม ) ดังนั้น วิศวกรจึงมักจะทำซ้ำนามธรรมเดิมทุกครั้งที่ความต้องการเปลี่ยนแปลง การเขียนโปรแกรมแบบ AHA ถือว่าทั้งโซลูชัน WET และ DRY จะสร้างซอฟต์แวร์ที่แข็งทื่อและบำรุงรักษายากอย่างหลีกเลี่ยงไม่ได้ แทนที่จะเริ่มต้นด้วยนามธรรม หรือสร้างนามธรรมที่จำนวนการทำซ้ำที่กำหนด ซอฟต์แวร์จะมีความยืดหยุ่นและแข็งแกร่งมากขึ้นหากสร้างนามธรรมเมื่อจำเป็น หรือเมื่อการทำซ้ำนั้นกลายเป็นอุปสรรคและทราบแล้วว่านามธรรมนั้นต้องทำงานอย่างไร ตามที่ Kent C. Dodds กล่าวไว้ มันคือการปรับให้เหมาะสมกับการเปลี่ยนแปลงก่อน และหลีกเลี่ยงการปรับให้เหมาะสมก่อนเวลาอันควร^{[ 7 ] [ 8 ]}

คำนี้ถูกบัญญัติโดยวิศวกรซอฟต์แวร์Cher Scarlettและการปฏิบัตินี้ได้รับการอธิบายครั้งแรกโดยวิศวกรซอฟต์แวร์และนักเขียนSandi Metzว่า "ชอบการทำซ้ำมากกว่านามธรรมที่ไม่ถูกต้อง" ^{[ 8 ]}

• อย่าเขียนซ้ำในWikiWikiWeb
• ครั้งเดียวเท่านั้นที่วิกิวิกิเว็บ
• 97 สิ่งที่โปรแกรมเมอร์ทุกคนควรรู้ (สำนักพิมพ์ O'Reilly)
• ความเข้าใจผิดเรื่องการปรับค่ามาตรฐานมากเกินไป (การอภิปรายเกี่ยวกับความสุดขั้วในแวดวงวิชาการเทียบกับสถานการณ์ฐานข้อมูลในโลกแห่งความเป็นจริง)
• Wilson G, Aruliah DA, Brown CT, Chue Hong NP, Davis M, Guy RT และคณะ (2014). "แนวปฏิบัติที่ดีที่สุดสำหรับการคำนวณทางวิทยาศาสตร์" PLOS Biol 12 ( 1) e1001745. arXiv : 1210.0530 . doi : 10.1371/journal.pbio.1001745 . PMC  3886731 . PMID  24415924 . อย่าทำซ้ำตัวเอง (หรือผู้อื่น)