อย่ารีบทำให้โค้ดเป็น DRY เร็วเกินไป

 (testing.googleblog.com)
15 คะแนน โดย GN⁺ 2024-05-31 | 10 ความคิดเห็น | แชร์ทาง WhatsApp

เหตุผลที่ไม่ควรกำจัดโค้ดซ้ำเร็วเกินไป

  • หากนำหลักการ DRY(Don't Repeat Yourself) มาใช้อย่างเคร่งครัดเกินไป อาจทำให้เกิดการทำ abstraction แบบ "Premature" และทำให้การเปลี่ยนแปลงในอนาคตซับซ้อนยิ่งขึ้น
  • ควรคิดให้ดีว่าความซ้ำซ้อนนั้นไม่จำเป็นจริงหรือไม่ หรือเป็นฟีเจอร์ที่จะพัฒนาแยกจากกันเมื่อเวลาผ่านไป
    • แม้ฟังก์ชันหรือคลาสจะดูเหมือนกัน แต่ก็อาจมีบริบทและความต้องการทางธุรกิจที่แตกต่างกัน
    • แทนที่จะมุ่งทำให้โค้ดสั้นลง ควรคิดว่าจุดประสงค์ของฟังก์ชันนั้นจะยังคงเดิมเมื่อเวลาผ่านไปหรือไม่
  • ความเสี่ยงของ abstraction: หากฟังก์ชันมีโอกาสพัฒนาไปในทิศทางที่ต่างกัน abstraction อาจกลับกลายเป็นโทษมากกว่าประโยชน์
    • เมื่อต้องออกแบบ abstraction ไม่ควรรีบผูกพฤติกรรมที่ในระยะยาวอาจพัฒนาแยกจากกันเข้าด้วยกันตั้งแต่เนิ่น ๆ
  • หากยังไม่แน่ใจ ควรแยกพฤติกรรมเหล่านั้นออกจากกันไว้ก่อน จนกว่าจะเห็นรูปแบบร่วมที่ชัดเจนพอจะอธิบายการรวมเข้าด้วยกันเมื่อเวลาผ่านไป
    • ในงานขนาดเล็ก การจัดการกับโค้ดซ้ำอาจง่ายกว่าการแก้ความซับซ้อนที่เกิดจาก abstraction แบบ Premature
    • ในช่วงเริ่มต้นของการพัฒนา ควรยอมให้มีโค้ดซ้ำอยู่บ้างและรอจังหวะที่เหมาะสมในการทำ abstraction
  • ความต้องการในอนาคตมักคาดเดาได้ยาก
    • ควรนึกถึงหลักการ YAGNI(You Aren't Gonna Need It)
    • ความซ้ำซ้อนอาจไม่ใช่ปัญหา หรือเมื่อเวลาผ่านไปมันจะแสดงให้เห็นอย่างชัดเจนว่าจำเป็นต้องมี abstraction ที่ผ่านการพิจารณามาอย่างรอบคอบ

บทความที่เกี่ยวข้อง

10 ความคิดเห็น

 
bbulbum 2024-06-03

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

ในความเห็นบน Hacker News
ความเข้าใจผิดเกี่ยวกับหลักการ DRY: DRY มีไว้เพื่อป้องกันการซ้ำซ้อนของข้อมูล/ความรู้ ไม่ใช่การซ้ำซ้อนของโค้ด หากโฟกัสแค่การซ้ำซ้อนของโค้ด อาจนำไปสู่การปรับให้เหมาะสมเกินความจำเป็น
ผมเห็นด้วยกับความเห็นนี้มากที่สุดครับ
 
wedding 2024-06-03

ช่วงรอยต่อแบบนี้ก็ไม่ได้กังวลกันเรื่องนั้นบ่อย ๆ เหรอครับ? เพราะไม่มีโค้ดที่สมบูรณ์แบบ การคอยคิดคอยกังวลอยู่ทุกวันก็คงเป็นงานของพวกเราแหละมั้งครับ ผมว่ามันแล้วแต่กรณีครับ
 
aer0700 2024-06-01

ช่วงนี้มีบทความที่มองโครงสร้างที่มีระดับการนามธรรมสูงอย่างกังขาถูกโพสต์ขึ้นมาบ่อย ๆ นะครับ
MSA, clean code, SOLID, DRY ฯลฯ...
ผมก็แอบคิดว่าผู้คนอาจกำลังรู้สึกเหนื่อยล้ากับคำพวกนี้อยู่เหมือนกัน
จริง ๆ แล้วสิ่งเหล่านี้ก็เป็นแค่หมุดหมายให้อ้างอิงเวลาเราคิดว่าจะเขียนโค้ดอย่างไรให้ อ่านง่าย เข้าใจง่าย ไม่ทำให้หน่วยความจำรั่ว ไม่มีข้อผิดพลาด และทำงานได้เร็ว เท่านั้นเอง...
ก็แค่ปรับใช้ให้พอดีและให้เหมาะกับสถานการณ์ทางธุรกิจที่ตัวเองกำลังเผชิญอยู่ในตอนนี้ก็น่าจะพอครับ
 
kandk 2024-06-01

เป็นบทความที่ดีมากครับ
ผมคิดว่านี่สำคัญเป็นพิเศษตอนเปลี่ยนจากโมเดล Waterfall ไปเป็นโมเดล Agile
ทั้งที่เป็น Agile แต่ก็พยายามคาดการณ์อนาคตมากเกินไป
 
iolothebard 2024-06-01

ต้องรีบแค่ไหนถึงจะเรียกว่า “รีบเกินไป”?
 
kandk 2024-06-01

คำตอบนั้นง่ายเกินไป: ถ้าทำตั้งแต่แรก มันก็ "รีบเกินไป"
คำถามที่ยากขึ้นอีกหน่อยคือ แล้วเมื่อไหร่ถึงจะเรียกว่า "ไม่ได้รีบเกินไป"
 
iolothebard 2024-06-23

ฟังดูเหมือนเล่นคำ แต่ถ้าไม่ทำตั้งแต่แรก ก็จะกลายเป็นว่า "ไม่รีบเกินไป" เองสินะ ^^;
 
kandk 2024-06-23

ใช่ โดยเฉพาะใน Agile
 
GN⁺ 2024-05-31
ความเห็นจาก Hacker News

  • การใช้หลักการ DRY ตั้งแต่เนิ่น ๆ: การใช้หลักการ DRY ตั้งแต่ต้นเป็นเรื่องที่ดี แทนที่จะจัดการข้อมูลที่คล้ายกันแยกกัน การใช้โค้ดเบสร่วมกันมีประสิทธิภาพกว่า

  • ลำดับความสำคัญของแนวปฏิบัติที่ดีที่สุด: แนวปฏิบัติที่ดีที่สุดไม่ได้มีน้ำหนักเท่ากันทั้งหมด การให้ความสำคัญกับความอ่านง่ายและความเป็นเอกภาพของโค้ดเป็นสิ่งสำคัญ การเขียนโค้ดคือกระบวนการเลือกแนวปฏิบัติที่เหมาะสมที่สุด

  • ความเข้าใจผิดเกี่ยวกับหลักการ DRY: DRY มีไว้เพื่อป้องกันการทำข้อมูล/ความรู้ซ้ำ ไม่ใช่แค่การทำโค้ดซ้ำ หากโฟกัสเฉพาะเรื่องโค้ดซ้ำ อาจนำไปสู่การปรับให้เหมาะเกินความจำเป็น

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

  • ปัญหาของโซลูชัน DRY ที่ซับซ้อน: บางครั้งโค้ดที่ทำซ้ำกันก็ยังดีกว่าโซลูชัน DRY ที่ซับซ้อน หากใช้ DRY เร็วเกินไป อาจก่อให้เกิดปัญหาเชิงโครงสร้างที่คาดไม่ถึง

  • DRY ไม่ใช่แนวปฏิบัติที่ดีที่สุดเสมอไป: การทำซ้ำมักเป็นสัญญาณว่าจำเป็นต้องมี abstraction การใช้ DRY แบบไม่ยั้งคิดเป็นความผิดพลาดที่วิศวกรระดับกลางมักทำกัน

  • ตัวอย่างโค้ดแบบง่าย: ฟังก์ชันสองตัวอาจถูกรวมเป็นฟังก์ชันเดียวได้ สิ่งสำคัญคือการอธิบายข้อดีข้อเสียของการรีแฟกเตอร์ให้ชัดเจน

  • ปัญหาการบำรุงรักษาของโค้ดแบบ DRY: โค้ดแบบ DRY อาจซับซ้อนขึ้นจนดูแลรักษาได้ยาก ขณะที่โค้ดแบบ WET เรียบง่ายกว่า แต่การเปลี่ยนแปลงสามารถคาดเดาได้

  • ผลข้างเคียงของหลักการ DRY: หลักการ DRY อาจทำให้โค้ดเบสซับซ้อนขึ้นและบำรุงรักษายาก หนังสือบางเล่มเกี่ยวกับ clean code ส่งผลกระทบเชิงลบต่อวงการ

  • การทำให้เป็นนามธรรมและประสิทธิภาพ: การทำให้เป็นนามธรรมอาจส่งผลเสียต่อประสิทธิภาพ การยอมให้มีโค้ดซ้ำที่ออกแบบตามรูปแบบข้อมูลเฉพาะอาจช่วยในการเพิ่มประสิทธิภาพได้