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

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

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

ตรวจสอบก่อนที่จะกระทำ - ไม่จำเป็นต้องแยกสาขา (แม้ว่าจะสามารถทำได้ถ้าต้องการ) ต้องให้ผู้ตรวจสอบการเข้าถึงโฟลเดอร์การทำงาน รหัสสามารถเปลี่ยนแปลงได้ระหว่างและหลังการตรวจสอบโดยไม่มีการติดตาม การแก้ไขที่เกิดจากการตรวจสอบจะไม่ปรากฏในที่เก็บ

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

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

1. ก่อนคอมมิทให้เรียกใช้ 'svn diff' เพื่อสร้างไฟล์ปะแก้
2. ส่งไฟล์ปะแก้ไปยังผู้ตรวจทานที่ใช้กับสำเนาที่สะอาดของลำต้น
3. ผู้ตรวจสอบดำเนินการเปลี่ยนแปลงโดยใช้ตัวดูผลต่างที่เลือกไว้
4. ผู้ตรวจสอบทำการสร้างและเรียกใช้การทดสอบ
5. หากทุกอย่างเป็นไปด้วยดีบอกนักพัฒนาพวกเขาสามารถตรวจสอบการเปลี่ยนแปลงของพวกเขา หาก
   มีปัญหานักพัฒนากลับไปที่ขั้นตอนที่ 1

มีโลกในอุดมคติแล้วก็มีโลกแห่งความเป็นจริง

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

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

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

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

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

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

ด้านล่างมีการพิจารณาอื่น ๆ ไม่กี่ที่จะคำนึงถึงถ้าคุณต้องการวิธีที่ดีที่สุด

1. จัดการกรณีที่รหัสบล็อกตรวจสอบล่าช้าจำเป็นสำหรับสมาชิกในทีมอื่น

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

_{สำหรับการเปรียบเทียบที่โพสต์การคอมเม้นท์ข้อกำหนดเหล่านี้ผ่อนคลายมากขึ้น (ฉันใช้กำหนดเวลา 2 สัปดาห์และเริ่มกังวลหลังจาก 1 สัปดาห์) - แต่เนื่องจากคุณกำหนดเป้าหมายการรีวิวก่อนหน้านี้อาจไม่น่าสนใจ}

2. รวมความขัดแย้งเมื่อส่งรหัสที่ตรวจสอบแล้ว

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

คู่ของตัวเลือกที่ต้องพิจารณาคือ

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

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

3. นักพัฒนาซอฟต์แวร์ที่กำลังรอการตรวจสอบ

กำหนดนโยบายที่ชัดเจนว่าผู้พัฒนาที่ส่งบทวิจารณ์ควรเปลี่ยนไปใช้งานใหม่หรือทำอย่างอื่น (เช่นการไล่ผู้ตรวจสอบ)

_{สำหรับการเปรียบเทียบการตรวจสอบภายหลังการโพสต์แทบจะไม่ต้องการนโยบายที่ชัดเจน (เนื่องจากเป็นเรื่องปกติที่จะดำเนินการงานต่อไปหลังจากที่คุณส่งรหัสและคำนึงถึงว่ากำหนดเวลาตรวจทานเป็นสัปดาห์หรือสองสัปดาห์) - แต่เนื่องจากคุณกำหนดเป้าหมาย ไม่น่าสนใจ.}

การพัฒนาใด ๆ ที่จำเป็นต้องมีการทบทวนจะต้องอยู่ในสาขาแยกต่างหาก ดังนั้นสาขาควรมีอยู่แล้วก่อนที่เวลาจะมาตรวจสอบ จากนั้นขั้นตอนจะต้องเป็น:

1. ทบทวน
2. แก้ไข (อาจ)
3. วนกลับไปที่บทวิจารณ์ (อาจ)
4. รวมเข้ากับลำต้น

การผสานเป็นเรื่องยาก ยิ่งกิ่งไม้อยู่นานเท่าไหร่ก็ยิ่งยากที่จะผสานมันกลับเข้าไปในลำต้น (อาจทดสอบได้ยากขึ้น)

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

บางคนลอง rebase แทนการรวมข้าม บางคนโต้แย้งว่าการคืนชีพนั้นชั่วร้าย นั่นคือการอภิปรายอื่น