วิธีจัดการกับปรัชญาการใช้ซ้ำรหัส


10

ฉันพบว่าตัวเองคิดเกี่ยวกับการใช้รหัสซ้ำเมื่อเริ่มต้นโครงการใหม่

ฉันควรใช้รหัสในระดับใด
ฉันควร จำกัด ขอบเขตแอปพลิเคชันหรือฉันควรทำให้สามารถนำมาใช้ใหม่นอกโครงการได้หรือไม่?

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


คำตอบ:


21

รหัสต้องทำงานก่อนที่จะสามารถนำมาใช้ซ้ำได้ ดังนั้นที่แสดงถึงการออกแบบและ (หลัก) ฟังก์ชั่นควรมาก่อนการพิจารณาของการใช้รหัสซ้ำ

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


2
"ถูก" ในประโยคแรกที่พิมพ์ผิด "มี" หรือไม่?

@delnan - อะไร "คือ" :-) ขอบคุณที่รับทราบ

9

จำ KISS และ YAGNI:

รหัสre-usability better to be consideredเมื่อคุณมีของคุณเอกสารการออกแบบพร้อม สิ่งนี้จะช่วยให้คุณเห็นส่วน / ส่วนของรหัสที่อาจมีการทำซ้ำ

ดังนั้นเมื่อคุณไม่มีการออกแบบที่ชัดเจนแล้วใช้แนวทางKISS และ YAGNIในการทำงานของคุณ!


1

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

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

  1. วิธีที่เร็วที่สุด
    คัดลอกรหัสก่อนหน้าจากโครงการอื่น (ไม่มีเวลามาก) ในโครงการปัจจุบันของฉัน
  2. วิธีที่เร็วที่สุดที่สอง
    คัดลอกรหัสก่อนหน้าและวางลงในไลบรารีทั่วไปจากนั้นรวมไลบรารีนั้นในโครงการปัจจุบัน (เพื่อทำให้การย้ายไปข้างหน้าง่ายขึ้น)

    2b ถ้าฉันเปลี่ยนแปลงโครงการอื่น (ดั้งเดิม) ฉันจะปรับโครงสร้างใหม่เพื่อใช้ไลบรารีใหม่ [แต่โดยทั่วไปจะไม่ทำเช่นนั้นเว้นแต่ฉันจะต้องแตะโครงการนั้นใหม่]

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


เหตุใดจึงต้องใช้การดำเนินการอย่างเดียวเมื่อคุณมีสี่หรือห้าอย่างที่เหมือนกัน วิธี "เร็วที่สุด" ของคุณนั้นเร็วที่สุดในระยะเวลาอันใกล้นี้
คาเลบ

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

1

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

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


0

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.