ฉันควรทำอย่างไรเมื่อฉันรอนานเกินไประหว่างการคอมมิท?

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

อะไรดีกว่า?

1. ทำสิ่งหนึ่งที่มีขนาดใหญ่มากในรายการสิ่งที่ฉันเปลี่ยน
2. พยายามแบ่งมันออกเป็นข้อผูกพันเล็ก ๆ ที่อาจไม่ได้รวบรวมเนื่องจากไฟล์มีการแก้ไขหลายอย่างเปลี่ยนแปลงชื่อเมธอดเพิ่มเติม ฯลฯ
3. พยายามทำการย้อนกลับบางส่วนของไฟล์เพื่อความมุ่งมั่นที่เหมาะสมจากนั้นนำการเปลี่ยนแปลงใหม่กลับมา

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

โดยวิธีการ:ฉันใช้ SVN และ Subclipse ฉันสร้างสาขาใหม่ก่อนทำการเปลี่ยนแปลงใด ๆ เหล่านี้

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

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

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

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

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

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

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

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

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

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

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

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

จากข้อมูลที่คุณให้ฉันเลือกตัวเลือกที่ 1 บางทีคุณควรตั้งค่าการแจ้งเตือนเพื่อให้คุณยืนยันการเปลี่ยนแปลง

การสร้างต้นแบบและการเขียนใหม่

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

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

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

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

ดังนั้นฉันจะไปหาตัวเลือก 1 หากไม่สามารถทำได้ตัวเลือกที่ 2

ตัวเลือก 3 ต้องใช้ความพยายามมากและไม่คุ้มค่า

พยายามแบ่งมันออกเป็นข้อผูกพันเล็ก ๆ ที่อาจไม่ได้รวบรวมเนื่องจากไฟล์มีการแก้ไขหลายอย่างเปลี่ยนแปลงชื่อเมธอดเพิ่มเติม ฯลฯ

เมื่อฉันพบตัวเองในสถานการณ์ที่คล้ายคลึงกันฉันใช้เทคนิคต่อไปนี้:

1. เพิ่มเฉพาะรหัสที่เกี่ยวข้องกับคุณสมบัติเฉพาะ: git add --patch
2. ซ่อนการเปลี่ยนแปลงอื่น ๆ ทั้งหมด: git stash save --keep-index
3. เรียกใช้การทดสอบ / ลองรวบรวม
4. กระทำการเปลี่ยนแปลงหากทุกอย่างโอเคถ้าไม่ไป 1

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

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

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

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

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

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

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

โปรแกรมเมอร์ที่เข้ามาในโครงการในภายหลังไม่น่าจะต้องการย้อนกลับไปเป็นเวอร์ชันที่ไม่ได้รวบรวม ดังนั้น IMHO ตัวเลือกที่ 2 คือความบ้า

ตัวเลือกที่ 3 ฟังดูเหมือนเวลาที่ว่าถ้าฉันเป็นเจ้านายของคุณและเห็นคุณเสียเวลาทำเช่นนี้ฉันจะคุยกับคุณเล็กน้อยเกี่ยวกับเวลาที่คุณควรค่า

ในการวนซ้ำ: โดยการตรวจสอบรหัสของคุณคุณจะครอบคลุม / บันทึกก้นของคุณในกรณีที่เครื่องของคุณล้มเหลว ทุกอย่างในทีมคนเดียวคือการแต่งกายด้วยหน้าต่าง

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

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

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

นอกจากนี้ยังเป็นวิธีที่ดีในการฝึกฝนนิสัยการเขียนโปรแกรมที่ดี

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

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

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

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

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

หลังจากนั้นคุณจะเห็นว่าการเปลี่ยนแปลงครั้งต่อไปไม่ได้นำคุณ "ยาวเกินไป" (ความหมาย)