บางครั้งเมื่อเราตรวจสอบประวัติการกระทำของซอฟต์แวร์เราอาจเห็นว่ามีข้อผูกพันบางอย่างที่ใหญ่มาก - พวกเขาอาจเปลี่ยนไฟล์ 10 หรือ 20 ไฟล์ที่มีการเปลี่ยนแปลงหลายร้อยบรรทัดซอร์สโค้ด (เดลต้า) ฉันจำได้ว่ามีคำที่ใช้กันทั่วไปสำหรับการกระทำที่ยิ่งใหญ่ แต่ฉันจำไม่ได้ว่าคำนั้นคืออะไร มีใครช่วยฉันบ้าง อะไรคือคำที่ผู้เขียนโปรแกรมมักใช้เพื่ออ้างถึงการกระทำที่ยิ่งใหญ่และยักษ์ใหญ่?

BTW มีการเปลี่ยนแปลงมากมายรวมกันเป็นแนวปฏิบัติที่ดีหรือไม่?

ปรับปรุง: ขอบคุณพวกคุณสำหรับการสนทนาที่สร้างแรงบันดาลใจ! แต่ฉันคิดว่า "code bomb" เป็นคำที่ฉันกำลังมองหา

(1) Ben Collins-Sussman : "... " code bombs "นั่นคือคุณจะทำอย่างไรเมื่อมีคนแสดงโครงการโอเพนซอร์ซที่มีฟีเจอร์ใหม่ขนาดยักษ์ที่ใช้เวลาเขียนนานหลายเดือน? โค้ดหลายพันบรรทัด? ... "

(2) Dan Fabulich : "The Code Bomb หรือ: The Newbie with Big Ideas ... การวางระเบิด Codeเป็นแผ่นใหญ่ที่ไม่มีใครสามารถตรวจสอบได้"

(3) Google Summer of Code: แนวทาง : "กระทำก่อนกำหนดส่งบ่อย ... โปรดอย่าทำงานตลอดทั้งวันจากนั้นผลักทุกอย่างออกมาในการวางระเบิดครั้งเดียวแทนการกระทำทุกอย่างควรอยู่ในหน้าที่เดียวเท่านั้น ซึ่งควรสรุปในข้อความบันทึก "

(4) Jeff Atwood : "code-bombs ... กฎ # 30: อย่าไปมืด ...

เราอาจเรียกมันว่าไม่ดีกระทำ :)

การปฏิบัติที่ไม่ดี

และใช่ว่าโดยทั่วไปจะถือว่าเป็นการปฏิบัติที่ไม่ดีเนื่องจากมีผลกระทบด้านลบของ:

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

กรณีที่ยอมรับได้

อย่างไรก็ตามคุณสามารถมีกรณีที่ยอมรับได้ดี ตัวอย่างเช่น

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

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

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

Update: คำตอบของ David Caryเชื่อมโยงไปยังนักแสดงด้านไอทีที่มีชื่อเสียงโดยใช้คำว่า"code-bomb" (ที่สำคัญที่สุดคือ Collins-Sussman ผู้สร้างดั้งเดิมของการโค่นล้ม ) เช่นนั้น (ถึงตอนนี้ฉันไม่สามารถพูดได้ว่าฉันได้ยินบ่อยครั้ง)

BTW มีการเปลี่ยนแปลงมากมายรวมกันเป็นแนวปฏิบัติที่ดีหรือไม่?

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

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

ดังนั้นมีมากกว่านั้นเพียงแค่ดูจำนวนไฟล์ที่สัมผัสได้ในการคอมมิชชัน

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

ฉันเรียกมันว่า"SVN ทั่วไปทั่วไป"หรือ"พรุ่งนี้เป็นวันที่เผยแพร่"

เท่าที่ฉันรัก SVN ฉันเพิ่งถูกปิดโดยความจริงที่ว่าฉันไม่สามารถทำอะไรได้

แก้ไข: พวกเขามักจะมีคำว่า "สิ่ง" และ "เบียร์" ในข้อความยืนยัน

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

A "รหัสร้อนนึ่ง" :-)

• initial commit - โครงการที่ไม่ได้อยู่ภายใต้การควบคุมการแก้ไขโยนลงใน SVN
• refactoring - สถาปนิกมีแนวคิดที่ยอดเยี่ยมเกี่ยวกับการเปลี่ยนชื่อคลาสจาก / เป็นSmurf Naming Conventionหรือเปลี่ยนรูทของลำดับชั้นของแพ็คเกจ
• รูปแบบรหัส - สถาปนิกได้ตัดสินใจเปลี่ยนการเยื้องรหัสจาก 4 เป็น 3 ช่องว่างหรือเปลี่ยนการสิ้นสุดบรรทัดจาก Unix เป็น Windows (หรือเปลี่ยนกลับ)
• ความมุ่งมั่นในวันศุกร์ - โจมักจะทำงานทั้งสัปดาห์ของเขาในวันศุกร์เวลา 16:30 น
• uuups กระทำ - เท็ดมีไดเรกทอรีรากถูกลบโดยไม่ได้ตั้งใจยอมรับและตอนนี้เขาปั๊มลำดับชั้นไฟล์ทั้งหมดลงใน SVN อีกครั้ง

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

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