เหตุใดการ "คัดลอกและวาง" โค้ดจึงเป็นอันตราย [ปิด]

บางครั้งเจ้านายของฉันจะบ่นกับเรา:

เหตุใดเราจึงต้องใช้เวลานานในการใช้งานคุณลักษณะนี้

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

เป็นคำถามที่ยากจริงๆเพราะการคัดลอกและวางรหัสไม่ใช่เรื่องง่ายในมุมมองของฉัน

คุณมีเหตุผลที่ดีพอที่จะอธิบายเรื่องนี้กับหัวหน้าที่ไม่ใช่ฝ่ายเทคนิคของคุณหรือไม่

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

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

ให้หัวหน้าของคุณอ่านเกี่ยวกับหลักการ DRY (อย่าทำซ้ำตัวเอง)

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

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

คุณจะดีกว่าในการแชร์โค้ดโดยการสร้างไลบรารีแทนที่จะคัดลอกโค้ดโดยใช้การคัดลอกและวาง

คุณจะยังคงได้รับข้อได้เปรียบด้านความเร็วมากกว่าการเขียนซ้ำ (ค้นหาแบบแห้ง) แต่จะมีเพียงที่เดียวในการรักษาโค้ด

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

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

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

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

• "แน่นอนฉันมีรหัสที่ทำแบบนั้นได้แล้ว!"
• "เดี๋ยวก่อนรหัสทั้งห้ารุ่นนี้เป็นรหัสที่ฉันต้องการใช้เป็นแหล่งที่มาของฉัน"
• "อืมฟังก์ชั่น 'util_func_023' ทั้งหมดนี้ทำหน้าที่อะไรฉันไม่ได้บันทึกไว้ใช่ไหมฉันต้องการฟังก์ชั่นใดในตอนนี้?
• "โอ้ใช่รหัสนี้ใช้ Code Base Y เดาว่าฉันต้อง [ เลือกอย่างใดอย่างหนึ่ง:คัดลอก Code Base Y ทั้งหมดไปยังโปรเจ็กต์ใหม่ของฉัน / ใช้เวลาหนึ่งวันในการขจัดฟังก์ชันเดียวที่ฉันต้องการจาก Code Base Y / ใช้เวลาหนึ่งสัปดาห์ในการขจัด ฟังก์ชันหนึ่งที่ฉันต้องการจาก Code Base Y] "
• "ฉันลอกทุกอย่างเย้!"
• "ทำไมถึงไม่ทำงาน"
• นี่คือจุดที่คุณใช้เวลาหลายชั่วโมง / วัน / สัปดาห์ในการดีบักโค้ดที่มีอยู่ซึ่งคล้ายกับสิ่งที่คุณต้องการแทนที่จะเขียนโค้ดที่คุณต้องการเริ่มต้นจริงๆ

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

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

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

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

หลักการแห้ง (ไม่ซ้ำตัวเอง): แห้งบนวิกิพีเดีย

"ความรู้ทุกชิ้นต้องมีการแสดงที่เชื่อถือได้เพียงอย่างเดียวไม่คลุมเครือและเชื่อถือได้ภายในระบบ"

การเชื่อมโยงอื่น ๆ

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

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

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

แน่ใจหรือว่าเจ้านายของคุณต้องการฟังเกี่ยวกับหลักการ DRY ข้อบกพร่องและเทคโนโลยีอื่น ๆ

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

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

การคัดลอกและวางโค้ดมักจะนำไปสู่Programming by Coincidence

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

ภายในแอปพลิเคชันเดียวกันการ "คัดลอกและวาง" นั้นไม่ดี แต่ระหว่างฐานรหัสที่พัฒนาโดยทีมอื่นหรือด้วยรอบการเผยแพร่ที่ต่างกัน "คัดลอกและวาง" อาจเป็นตัวเลือกที่ดีที่สุด

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

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

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

บอกหัวหน้าของคุณว่าส่วนของชื่อตัวแปรแต่ละชื่อรวมถึงชื่อของโปรเจ็กต์เก่าและตอนนี้คุณต้องเปลี่ยนทั้งหมดด้วยตนเอง หากเจ้านายของคุณไม่รู้ (หรืออยากรู้) ว่าทำไมการคัดลอก / วางจึงไม่ดีเขา / เธอก็อาจจะเชื่อเช่นนั้น :)

ใช่ปัญหาที่ใหญ่ที่สุดคือไม่ใช่แค่คัดลอกและวาง - คัดลอกแล้ววางจากนั้นแก้ไขเล็กน้อย

หลังจากนั้นเมื่อตัวแปรที่วางไว้มีปัญหาก็จะเปลี่ยนไป จากนั้นในภายหลังตัวแปรอื่นจะเปลี่ยนไป

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

และคุณไม่รู้หรือไม่ว่าการเข้ารหัสแบบเส็งเคร็งแบบนี้มักจะเป็นโมฆะเกือบทั้งหมด

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

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

ฉันชอบระบบไม่ใช่หลาย ๆ รหัส

มีการแลกเปลี่ยนระหว่างความเร็วในการพัฒนาฟังก์ชันทันทีต่อหน้าคุณ (โดยเฉพาะเมื่อแอปพลิเคชันมีขนาดเล็ก) และค่าบำรุงรักษาในระยะยาวเมื่อแอปพลิเคชันเติบโตขึ้น

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

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

เขาคิดถูกว่าหากทีมเคยใช้ฟังก์ชันการทำงานที่คล้ายกันมาก่อนการทำซ้ำจะมากในครั้งที่ 2ง่ายกว่า

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

ใน บริษัท ของฉันเราทำงานร่วมกับชั้นเรียนและวิธีการและจัดทำเอกสารทางเทคนิคสำหรับพวกเขาเสมอ ฉันคิดว่ามันเป็นแนวทางปฏิบัติที่ดีที่สุดถ้าคุณสามารถใช้แอพพลิเคชั่นการค้นหา svn ของคุณเองพร้อมคีย์ที่ดีเพื่อค้นหาคลาสเมธอดที่เคยใช้มาก่อน :)