แก้ไขข้อผิดพลาดขณะทำงานในส่วนต่าง ๆ ของรหัสฐาน

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

คุณทำอะไรในสถานการณ์นั้น

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

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

แก้ไข:ฉันเปลี่ยนหมายเลขสามเพื่อสะท้อนถึงสิ่งที่ฉันหมายถึงจริงๆ

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

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

ฉันมักจะไป # 2 มันทำให้พื้นที่เก็บข้อมูลสะอาดขึ้นและทำให้บันทึกเข้าใจง่ายขึ้น ฉันเกลียดเมื่อ devs อื่นที่ฉันทำงานด้วยกระทำการแก้ไขข้อผิดพลาด 15 คุณสมบัติและ refactorings ทั้งหมดในกระทำเดียวกัน

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

ฉันทำ # 2 การใช้เครื่องมือเช่นคอมไพล์ทำให้ไม่สามารถแยกออกเป็นหลายคอมมิตได้ หากคุณไม่สามารถโน้มน้าวให้ทีมของคุณเปลี่ยนไปใช้เครื่องมือที่ทันสมัยกว่านี้ได้ git-svn จะให้ส่วนที่เหมาะสมกับสิ่งที่คุณใช้ในการแก้ปัญหานี้ โพสต์บล็อกนี้ให้ภาพรวมที่ดีเกี่ยวกับขั้นตอนการทำงานที่คุณกำลังพยายามแก้ไข: The Thing About Git

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

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

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

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

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

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

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

คำตอบสั้น ๆ : # 2 คุณต้องการแก้ไขข้อผิดพลาดนั้น (พร้อมหมายเหตุในตัวติดตาม!) ติดแท็กในประวัติรุ่นของคุณเป็นเอนทิตีที่แยกต่างหาก

คำตอบอีกต่อไป:

• สะดุดข้ามข้อผิดพลาด
• เขียนการทดสอบหรือแสดงข้อผิดพลาดเพิ่มเติม
• ทำแบบทดสอบ
• ยอมรับการเปลี่ยนแปลงนั้นและการทดสอบ ( git add --interactiveหรือdarcs record -iVCS ของคุณทำ) (*)
• กลับไปที่สิ่งที่ฉันทำ

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

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

ฉันแก้ไขข้อผิดพลาดและฉันแยกข้อผูกพันหนึ่งข้อสำหรับแต่ละการแก้ไข / คุณสมบัติ

ส่วนใหญ่แล้วการเปลี่ยนแปลงจะไม่อยู่ในไฟล์เดียวกันดังนั้นจึงเป็นการง่ายที่จะแยกการกระทำ หากการเปลี่ยนแปลงอยู่ในไฟล์เดียวกันฉันใช้ TortoiseHg (mecurial GUI front-end) เพื่อเลือก diffs ที่ต้องการอย่างแม่นยำ (ฉันคิดว่ามันเป็นไปได้ที่จะทำสิ่งนี้บนบรรทัดคำสั่งด้วยส่วนขยายของบันทึกแต่มันสะดวกน้อยกว่า )

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

ฉันมักจะทำ # 2 การบันทึกงานปัจจุบันของฉันที่อื่น: โดยปกติจะใช้งานได้ดีโดยการสร้างโปรแกรมปะแก้ นอกจากนี้ IDEs บางตัว (IntelliJ) ยังอนุญาตให้มีการเปลี่ยนแปลงชั้นวางซึ่งก็คือ: บันทึกงานปัจจุบันที่อื่น

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

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

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

เราทำอันดับ 1 # 2 ฟังดูดี แต่ฉันไม่สามารถพูดได้ว่าเรามีปัญหากับ # 1 ที่ # 2 จะแก้ไขได้

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