มันเป็นการปฏิบัติที่ไม่ถูกต้องหรือไม่ที่จะไม่ลบไฟล์ซ้ำซ้อนทันทีจาก VCS แต่ให้ทำเครื่องหมายว่า "จะถูกลบ" ด้วยความคิดเห็นก่อน?

ฉันต้องการทราบว่าวิธีจัดการกับไฟล์ต้นฉบับที่ต้องลบออกจากการควบคุมเวอร์ชันอาจถือได้ว่าเป็นการปฏิบัติที่ไม่ดีหรือไม่

ฉันต้องการอธิบายให้คุณตามตัวอย่าง:

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

ฉันจะไม่ลบไฟล์ที่ซ้ำซ้อนดังกล่าวทันทีผ่านทาง SVN-> ลบ (แทนที่ด้วยคำสั่งลบของระบบควบคุมเวอร์ชันที่คุณเลือก) แต่ให้ใส่ความคิดเห็นในไฟล์เหล่านั้นแทน (ฉันอ้างอิงทั้งที่หัวและท้ายกระดาษ) ว่าพวกเขากำลังจะไป ถูกลบ + ชื่อของฉัน + วันที่และ - ที่สำคัญกว่า - ทำไมพวกเขาถึงถูกลบ (ในกรณีของฉันเพราะพวกเขาตายรหัสสับสน) จากนั้นฉันบันทึกและส่งไปยังการควบคุมเวอร์ชัน ครั้งต่อไปเมื่อฉันต้องคอมมิต / เช็คอินบางอย่างในโปรเจ็กต์ถึง version control ฉันกด SVN-> Delete จากนั้นพวกมันก็จะถูกลบใน Version Control - ซึ่งแน่นอนว่ายังคงสามารถเรียกคืนผ่านการแก้ไขได้

ทำไมต้องทำเช่นนี้แทนที่จะลบออกทันที

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

"อืม ... ทำไมไฟล์เหล่านั้นถึงถูกลบไปฉันทำงานได้ดีมาก่อน" (กด 'ย้อนกลับ' -> ผู้ชายที่ย้อนกลับไปแล้วจะหายไปตลอดกาลหรือไม่พร้อมใช้งานในสัปดาห์หน้าและผู้รับมอบหมายต่อไปจะต้องค้นหาฉันอย่างน่าเบื่อเหมือนว่าไฟล์เหล่านั้นเป็นอย่างไร)

แต่คุณไม่ทราบหรือไม่ว่าเหตุใดไฟล์เหล่านั้นจึงถูกลบในข้อความยืนยัน?

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

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

จากมุมมองของคนนอกวิธีการนี้ดูเหมือนว่าจะหยั่งรากในมุมมองแบบอนุรักษ์นิยมของการควบคุมแหล่งที่มา

"จะเกิดอะไรขึ้นถ้าฉันลบไฟล์ที่ไม่ได้ใช้แล้วใครสักคนต้องการมัน?" บางคนอาจถาม

คุณใช้การควบคุมแหล่งที่มา ย้อนกลับการเปลี่ยนแปลงหรือดีกว่ายังคุยกับคนที่ลบไฟล์ (สื่อสาร)

"ถ้าฉันลบไฟล์ที่ตายแล้วจะมีใครบางคนเริ่มใช้มันอีกครั้งและพวกเขาทำการเปลี่ยนแปลง" คนอื่นอาจถาม

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

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

หากควรลบออกให้ลบออก ตัดไขมันออกจากฐานรหัส

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

Vincent Savard ในความเห็นเกี่ยวกับคำถามกล่าวว่า:

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

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

หากข้อความคอมมิชชันไม่ได้บอกเล่าเรื่องราวนักพัฒนาก็จำเป็นต้องเขียนข้อความคอมมิท

การกลัวที่จะลบรหัสหรือลบไฟล์เป็นตัวบ่งชี้ถึงปัญหาที่เป็นระบบของกระบวนการ:

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

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

ใช่มันเป็นการปฏิบัติที่ไม่ดี

คุณควรใส่คำอธิบายสำหรับการลบในข้อความกระทำเมื่อคุณกระทำการลบไฟล์

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

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

ในความคิดของทั้งสองของตัวเลือกของคุณไม่ปฏิบัติที่ดีที่สุด , ตรงข้ามกับการที่ไม่ดี , ปฏิบัติ:

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

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

1. เพิ่มความคิดเห็นที่ระบุว่ามันเป็นตัวเลือกสำหรับการลบและการคัดค้าน #warning หรือคล้ายกัน (ภาษาส่วนใหญ่มีกลไกบางอย่างเช่นในJavaในกรณีที่เลวร้ายที่สุดprintคำสั่งหรือสิ่งที่คล้ายคลึงกันจะพอเพียง) โดยเฉพาะกับ timescale และ พร้อมรายละเอียดการติดต่อ วิธีนี้จะแจ้งเตือนทุกคนที่ยังใช้รหัสอยู่ คำเตือนเหล่านี้เป็นปกติในแต่ละฟังก์ชั่นหรือระดับถ้าสิ่งดังกล่าวอยู่
2. หลังจากเวลาอัพเกรดคำเตือนเป็นขอบเขตไฟล์มาตรฐาน#warning(บางคนไม่สนใจคำเตือนการคัดค้านและกลุ่มเครื่องมือบางอย่างไม่แสดงคำเตือนดังกล่าวตามค่าเริ่มต้น)
3. ต่อมาแทนที่ขอบเขตของไฟล์#warningด้วย a #errorหรือสิ่งที่เทียบเท่า - สิ่งนี้จะทำลายโค้ดในเวลา build แต่สามารถถ้าจำเป็นจริงๆจะถูกลบออก แต่บุคคลที่ลบมันไม่สามารถเพิกเฉยได้ (นักพัฒนาซอฟต์แวร์บางคนไม่อ่านหรือแก้ไขคำเตือนใด ๆ หรือมีจำนวนมากจนไม่สามารถแยกคำเตือนที่สำคัญออกได้)
4. สุดท้ายทำเครื่องหมายไฟล์ (ในหรือหลังวันที่ครบกำหนด) ตามที่ถูกลบใน VCS
5. หากลบแพ็คเกจ / ไลบรารี / ฯลฯ ทั้งหมดในขั้นตอนการเตือนฉันจะเพิ่ม README.txt หรือ README.html หรือคล้ายกับข้อมูลว่าเมื่อไร & ทำไมมีการวางแผนที่จะกำจัดแพ็คเกจและปล่อยไฟล์นั้นไว้ด้วย เปลี่ยนเป็นคำพูดเมื่อถูกลบเนื่องจากเป็นเนื้อหาเดียวของแพ็กเกจสำหรับบางเวลาหลังจากลบเนื้อหาที่เหลือ

ข้อดีอย่างหนึ่งของวิธีนี้ก็คือว่าบางระบบเวอร์ชัน(CVS, PVCS ฯลฯ )จะไม่ลบไฟล์ที่มีอยู่ในการเช็คเอาต์ถ้ามันได้ถูกลบออกใน VCS นอกจากนี้ยังให้นักพัฒนาที่ขยันขันแข็งผู้ที่แก้ไขคำเตือนทั้งหมดของพวกเขามีเวลามากในการแก้ไขปัญหาหรืออุทธรณ์การลบ นอกจากนี้ยังบังคับให้นักพัฒนาที่เหลืออยู่อย่างน้อยมองไปที่การแจ้งลบและบ่นมาก

โปรดทราบว่า#warning/ #errorเป็นกลไก C / C ++ ที่ทำให้เกิดคำเตือน / ข้อผิดพลาดตามด้วยข้อความที่ให้เมื่อคอมไพเลอร์พบรหัสนั้น java / java-doc มี@Deprecatedหมายเหตุประกอบเพื่อออกคำเตือนการใช้งาน & @deprecatedเพื่อให้ข้อมูลบางอย่าง ฯลฯ มีสูตรการทำคล้ายกับงูหลามและฉันเคยเห็นassertใช้เพื่อให้ข้อมูลที่คล้ายกัน#errorในโลกแห่งความจริง

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

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

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

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

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

ดังนั้น (ในโครงการ C ++) ฉันเพิ่ม

#error this is not as dead as I thought it was

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

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

ในความต่อเนื่องของการปฏิบัติที่ไม่ดีสิ่งนี้ค่อนข้างน้อย ฉันจะทำสิ่งนี้เป็นครั้งคราวเมื่อฉันต้องการตรวจสอบสาขาและสามารถดูรหัสเก่าได้ สิ่งนี้สามารถทำให้การเปรียบเทียบกับรหัสการแทนที่ง่ายขึ้น ฉันมักจะได้รับรหัสตรวจสอบความคิดเห็น "cruft" ด้วยคำอธิบายเล็กน้อยฉันผ่านการตรวจสอบรหัส

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

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

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

• ขั้นตอนที่ 1: เปลี่ยนชื่อคลาสเพิ่มความคิดเห็นของคุณกระทำ
• ขั้นตอนที่ 2: ลบไฟล์และคอมมิชชัน

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

นอกจากนี้ยังสอนให้คนรู้จักวิธีดูข้อความที่ส่งเข้ามาสำหรับไฟล์บางคนไม่รู้ด้วยซ้ำว่าเป็นไปได้