มีกรณีพิเศษที่เราสามารถรับรหัสซ้ำได้หรือไม่

ฉันกำลังทำงานในโครงการซอฟต์แวร์ที่เราต้องสร้าง API สามตัว หนึ่งสำหรับบ้านธนาคารช่องทางหนึ่งสำหรับหน่วยงานและช่องทางที่สามสำหรับโทรศัพท์มือถือช่อง

API ของเอเจนซีนั้นสมบูรณ์ที่สุดเนื่องจากมีฟังก์ชั่นทั้งหมด .. จากนั้นเป็น Home API ที่เล็กกว่าและ API มือถือ

สถาปนิกที่นี่สร้างเลเยอร์ทั่วไป (บริการ EJB ข้ามแชนเนลที่แชร์โดย API ทั้งหมด) แต่ API นั้นแตกต่างกัน

ตอนนี้ไม่มีความแตกต่างใหญ่ระหว่าง API ทีมใหญ่เริ่มต้นด้วยแชแนลเอเจนซี่และเรากำลังปรับให้เข้ากับช่องทางบ้าน เราเป็นเพียงการเพิ่มคุณค่าของวัตถุให้กับแอพหลักของเรา มิฉะนั้นรหัสจะคล้ายกัน 95% ระหว่าง API API นั้นสร้างมาจากSpring MVCและมี (ตัวควบคุมรุ่นและยูทิลิตี้บางอย่าง)

โดยพื้นฐานแล้วคอนโทรลเลอร์กำลังทำการแมป BO กับ ChannelObject (ดูเหมือนว่าฉันไม่ใช่สถานที่ที่เหมาะสมในการทำเช่นนั้น) และยูทิลิตี้และซีเรียลไลเซอร์บางส่วน ทั้งหมดซ้ำกันในตอนนี้ พวกเขาบอกว่าสาเหตุของการทำซ้ำคือพวกเขาต้องการให้ API แยกต่างหาก "ถ้าพรุ่งนี้เราต้องการพฤติกรรมที่แตกต่างสำหรับบ้านมากกว่าเอเจนซี่หรือมือถือเราจะไม่ดิ้นรน !!"

มีกรณีที่เราควรยอมรับรหัสซ้ำหรือไม่

การทำสำเนาอาจเป็นสิ่งที่ถูกต้องที่จะทำ แต่ไม่ใช่ด้วยเหตุผลนี้

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

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

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

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

การทำซ้ำนั้นถูกกว่าการทำผิดที่ผิด

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

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

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

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

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

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

ดังนั้นหากปรากฎว่ามีทีมย่อยที่แตกต่างกันจริง ๆ แต่ละคนรับผิดชอบ API แต่ละอันแต่ละคนมีตารางเวลาและทรัพยากรที่แตกต่างกันดังนั้นถึงเวลาที่จะต้องทำซ้ำรหัส แต่ไม่ใช่ "ในกรณี"

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

ดังนั้นคุณจะจ่ายราคาของรหัสซ้ำเพื่อให้ได้เอกราชและเป็นอิสระ