กระทำ / ตรวจสอบในรหัสทุกวันเป็นแนวปฏิบัติที่ดีหรือไม่?

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

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

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

คำถาม:การกระทำทุกวันเป็นวิธีที่ดีที่ฉันควรเปลี่ยนเวิร์กโฟลว์ของฉันเพื่อรองรับหรือไม่แนะนำให้ทำ?

แก้ไข:ฉันเดาว่าฉันควรจะชี้แจงว่าฉันหมายถึง "กระทำ" ในความหมายของ CVS (aka "push") เนื่องจากเป็นไปได้ว่าสิ่งที่ Fowler จะมีความหมายในปี 2549 เมื่อเขาเขียนสิ่งนี้

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

ฉันไม่เห็นด้วยกับกฎนี้และฉันเห็นด้วยกับสิ่งที่Mason Wheelerพูด ฉันต้องการเพิ่มแนวคิดเล็กน้อย

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

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

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

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

แค่ 2 เซ็นต์ของฉัน

แก้ไข

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

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

คุณควรพิจารณาเลิกงานของคุณเพื่อให้คุณสามารถเช็คอินได้อย่างปลอดภัยวันละสองสามครั้ง

เหตุผลของเรื่องนี้คือสอง:

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

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

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

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

Oded ให้เหตุผลสำคัญสองข้อในการส่งรหัสบ่อยที่สุดเท่าที่จะทำได้ ฉันจะเพิ่มอีกไม่กี่:

1. ขณะที่ทำงานกับรหัสของคุณส่วนอื่น ๆ อาจต้องการฟังก์ชั่นบางอย่างในรหัสนั้น พวกเขาไม่ควรรอ 6 วันเพื่อรับมัน ในกรณีนี้เพื่อนร่วมงานของฉันมักจะสร้างต้นแบบในส่วนของรหัสของฉันกระทำมันฉันเพิ่มร่างกายและกระทำอีกครั้ง และมักจะทำในไม่กี่ชั่วโมง

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

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

• พวกเขาทำลายการสร้างหรือไม่
• คุณกำลังทำซ้ำความพยายามของสมาชิกในทีมอื่นหรือไม่
• คุณกำลังทำอะไรผิดหรือเปล่า?
• หรือคนกำลังรอคอยสิ่งต่าง ๆ จากคุณ?

การเปลี่ยนแปลงเล็ก ๆ น้อย ๆ นั้นง่ายต่อการจัดการ

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

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

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

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

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

ตอนนี้สิ่งที่ดีเกี่ยวกับวิธีการทำงานนี้

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

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

ข้อโต้แย้งในการตรวจสอบทุกวัน:

• รหัสจะถูกจัดเก็บและสำรองข้อมูลจากความล้มเหลวของฮาร์ดไดรฟ์
• สามารถบันทึกกิจกรรมในบันทึกการกระทำ ( ฉันทำอะไรในวันพฤหัสบดี ... ? )
• การผสานรวมกับฐานรหัสที่มีอยู่เกิดขึ้นก่อนหน้านี้และในกลุ่มย่อยที่มีขนาดเล็กลงหวังว่าจะระบุความขัดแย้งหรือรวมปัญหาได้เร็วขึ้น
• ทีมของคุณมองเห็นสิ่งที่คุณกำลังทำอยู่
• เพื่อนร่วมงานของคุณสามารถทำงานกับอินเทอร์เฟซของคุณได้เร็วขึ้นทำให้พวกเขามีเวลามากขึ้นในการรวมเข้ากับ 'โค้ดที่ซับซ้อนขนาดใหญ่' ของคุณ
• รหัสของคุณจะถูกทดสอบในโลกแห่งความเป็นจริงไม่ช้าก็เร็วหรืออย่างน้อยก็มีการใช้งานมากกว่าที่คุณจะให้มันซึ่งจะนำไปสู่การระบุข้อผิดพลาดหรือการละเว้นก่อนหน้านี้

มีข้อโต้แย้งในการเช็คอินทุกวัน:

• ไม่ต้องการหรือไม่ต้องการ
• ยังไม่ได้ 'ล้างข้อมูล' รหัสของฉันมันเป็นระเบียบ
• ไม่มีเวลา

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

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

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

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

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

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

ใน Team Foundation Server คุณสามารถ 'Shelve' ซึ่งไม่เหมือนกับการเช็คอิน แต่เพียงแค่ทำการสำรองข้อมูลรหัสของคุณเพื่อที่ว่าหากเครื่องของคุณตายคุณจะไม่สูญเสียการเปลี่ยนแปลง

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