การใช้รูปแบบที่แตกต่างกันสำหรับคุณสมบัติที่คล้ายกัน

ฉันเป็นผู้พัฒนาเพียงผู้เดียวในโครงการที่อาจมีคนอื่นนำไปใช้ในโครงการต่อไปในอนาคต

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

จากนั้นก็ถึงเวลาที่จะใช้งานคุณสมบัติ B มันคล้ายกับ A แต่คราวนี้ฉันต้องการใช้โอกาสนี้เพื่อเล่นกับรูปแบบ Y ฉันมีความสุขกับผลลัพธ์สุดท้ายดีกว่าเมื่อใช้คุณสมบัติ A แต่ตอนนี้โค้ดของฉันใช้สอง รูปแบบที่ต่างกัน, X และ Y, สำหรับคุณสมบัติที่คล้ายกัน

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

โปรดทราบว่าคำถามนี้ไม่ได้เกี่ยวกับการเลือกรูปแบบที่เหมาะสมสำหรับปัญหาที่กำหนด ; มันมีอยู่สองรูปแบบที่อยู่ร่วมกันในฐานของรหัสเพื่อแก้ปัญหาที่คล้ายกันซึ่งสามารถลดลงเหลือเพียงครั้งเดียวเพื่อให้มีการปรับโครงสร้าง

• รหัสนั้นมีกลิ่นหรือไม่?
• อะไรคือข้อเสียของการรักษาซอร์สโค้ดเช่นนี้?
• ฉันควรจะใช้รูปแบบเดียวเท่านั้นหรือไม่ เช่น refactor A เพื่อใช้ Y หรือใช้ X ต่อไปเมื่อเขียน B?
• ฉันจะสื่อสารได้อย่างไรว่าสาเหตุที่มีสองรูปแบบที่แตกต่างกันสำหรับคุณสมบัติที่คล้ายกันนั้นไม่มีเหตุผล
• ฉันกังวลมากเกินไปเกี่ยวกับสิ่งที่นักพัฒนาคนต่อไปคิดเกี่ยวกับรหัสของฉันหรือไม่

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

คุณไม่ต้องกังวลมากเกินไป แต่เป็นกลิ่นที่รุนแรงซึ่งคุณควรจัดการและทำความสะอาด

ข้อเสียของการมีวิธีแก้ไขปัญหาต่าง ๆ ในปัญหาเดียวกันใน codebase:

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

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

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

อย่าเล่นใน codebase ต้นแบบการเขียนนั้นคุณสามารถค้นหาข้อดีและข้อเสียของรูปแบบ / การออกแบบหนึ่งมากกว่าอีกแบบหนึ่ง

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

คาดว่าจะมีการพัฒนาโค้ดสำหรับต้นแบบ

ไม่ว่าจะเป็นกลิ่นรหัสหรือไม่นั้นขึ้นอยู่กับปัญหา A และปัญหา B ที่คล้ายกัน ดูเหมือนว่าคำตอบของ JacquesB จะถือว่าพวกเขาคล้ายกันมากและหากคุณเปลี่ยนปัญหา A (เพื่อแก้ไขข้อผิดพลาดตัวอย่าง) คุณจะต้องเปลี่ยนปัญหา B ในเวลาเดียวกัน JaqueB อาจจะถูกต้อง แต่ก็อาจเป็นไปได้ว่า A และ B เปลี่ยนแปลงอย่างอิสระเพราะพวกเขาไม่ได้มีลักษณะคล้ายกันทั้งหมด ในสถานการณ์นั้นคุณไม่น่าจะอธิบายข้อเสียได้

จากคำอธิบายของคุณดูเหมือนว่าจะมีกลิ่นเล็กน้อย (ซ้ำ) แต่ก็ยากที่จะบอกว่ากลิ่นเหม็นนั้นเป็นอย่างไร ตัวอย่างเช่นถ้า A ใช้เทมเพลตเมธอดและ B ใช้กลยุทธ์ปัญหาทั้งสองอาจแตกต่างกันมากแม้ว่าจะใช้รูปแบบการมิเรอร์ ฉันจะรอดูวิธี ในกรณีที่ปัญหา C เข้ามาและมันก็เหมือนกับ A และ B จากนั้นฉันจะสร้าง A เพื่อให้สอดคล้องกับ B แล้วสร้าง C ควรจะง่ายมาก หากมีข้อผิดพลาดใน A ฉันก็อยากจะ refactor มันให้ตรงกับ B แล้วแก้ไขข้อผิดพลาด ในกรณีที่ไม่มีการเปลี่ยนแปลง .... มันไม่สำคัญหรอกเหรอ?

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

ไม่คุณสามารถใช้รูปแบบหลายรูปแบบในฐานรหัสเดียว

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