เมื่อใดที่จะส่งมอบรหัส?

59

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

ดังนั้นคำถามคือเมื่อใดให้คอมมิชชันกับที่เก็บจริงเพื่อให้คอมมิชชันมีความสมเหตุสมผล?

ในฐานะที่เป็นส่วนเสริม: เป็นวิธีปฏิบัติที่ถูกต้องหรือไม่ในการวัดการพัฒนาโครงการตามความมุ่งมั่น?

programming-practices version-control coding

— ริ้น
แหล่งที่มา

9

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

— unholysampler

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

79

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

— Neil Butterworth
แหล่งที่มา

10

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

— Edward Strange

34

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

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

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

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

— tdammers
แหล่งที่มา

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

— Juha Untinen

ใช่ แต่มีระดับน้อยกว่าเพราะ (ดูคำตอบต้นฉบับ) คุณจะไม่รบกวนใครโดยตรง ทั้งนี้ขึ้นอยู่กับ SCM ที่เป็นปัญหาโดยทั่วไปถือว่าเป็นการปฏิบัติที่ดีในการล้างประวัติการกระทำของคุณก่อนที่จะรวมอัปสตรีมแม้ว่า (เช่นgit rebase -i)

— tdammers

13

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

สำหรับ VCS ที่ไม่กระจาย (เช่น SVN) จะใช้ตรรกะเดียวกันแทนที่เก็บข้อมูลโลคัลใช้ไพรเวตสาขาแทนการพุช - ผสานกับสาขาหลัก

— vartec
แหล่งที่มา

+1 ประหลาดใจที่นี่ไม่ได้ถูกโหวตเพิ่มอีก นั่นเป็นความคิดแรกของฉัน - dvcs หรือ vcs

— Michael Durrant

9

คุณควรกระทำเร็วและบ่อยครั้ง

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

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

คุณวัดการพัฒนาผลิตภัณฑ์ตามมูลค่าที่ส่งมอบให้กับผู้ใช้ ไม่มีการวัดที่แม่นยำอื่น ๆ

— Rein Henrichs
แหล่งที่มา

1

+1 เมื่อคุณรวม BDD-As-If-You-Mean-It, Refactor จนกว่าคุณจะวาง, Atomic Coding และภาษาที่แสดงออกอย่างสูง 90 วินาทีอาจใช้เวลานานในการดำเนินการโดยไม่ผิดเพี้ยน

— Jörg W Mittag

8

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

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

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

หากผู้กระทำตามกฎข้างต้นจะกลายเป็นเรื่องไม่สำคัญไปที่:

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

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

— justjkk
แหล่งที่มา

ผมคิดว่าคำตอบนี้จะต้องเป็นคำตอบที่ได้รับการยอมรับ แต่อาจถามกำลังมองหาคำอธิบายที่ง่าย :)

— Behnam Rasooli

7

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

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

— Catchops
แหล่งที่มา

5

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

— Neil Butterworth

1

@Neil Butterworth: ... เว้นแต่จะมีผู้พัฒนารายอื่นที่ทำงานในสาขาเดียวกันโดยมีการพึ่งพาโค้ดของคุณ

— FrustratedWithFormsDesigner

@ เฟร็ดในกรณีนี้มันควรจะสามารถคอมไพล์ได้ แต่ฉันไม่เห็นว่ามันจะต้องพร้อมสำหรับการรวมและการทดสอบระบบ

— Neil Butterworth

1

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

— George Mauer

2

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

— สตีเฟ่นซี. เหล็ก

6

ในฐานะที่เป็นส่วนเสริม: เป็นวิธีปฏิบัติที่ถูกต้องหรือไม่ในการวัดการพัฒนาโครงการตามความมุ่งมั่น?

เลขที่มีWTF รายวันเกี่ยวกับสาเหตุที่เป็นความคิดที่น่ากลัว

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

แต่ไม่เคยตรวจสอบว่ามันไม่ได้รวบรวม ฉันรู้ว่ามันดูเหมือนโง่จริงๆที่จะพูดออกมาดัง ๆ แต่ฉันต้องอธิบายให้คนฟังก่อน

— Tyanna
แหล่งที่มา

1

+1 สำหรับคำเตือนการคอมไพล์ เรามีกระปุกออมสินที่สำนักงานซึ่งทุกคนจะต้องเสียค่าธรรมเนียมในแต่ละครั้งที่เขา / เธอทำสิ่งที่ทำให้การสร้างล้มเหลวเป็นผล น่าเศร้าที่เราได้ค่อนข้างเงินด้วยวิธีนี้อย่างน้อยแรก :)

— เรย์

@ เรย์ - ที่สุดท้ายของฉันการปรับเข้าสู่กองทุนล็อตโต้ อนิจจาเราไม่เคยหลงรักมันจากนิสัยที่ไม่ดี : P

— Tyanna

1

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

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

— FrustratedWithFormsDesigner
แหล่งที่มา

จำไว้ว่าด้วยระบบแบบกระจาย, commit! = share คุณควรผลักดันเมื่อคุณมีบางอย่างพร้อมที่จะแชร์

— Rein Henrichs

@Rein Henrichs: จุดดีแม้ว่าการควบคุมแหล่งที่มาที่นี่ไม่มีฟังก์ชั่นนั้น (อย่างน้อยก็เท่าที่ฉันรู้) เมื่อมีบางสิ่งเกิดขึ้นทุกคนในโครงการสามารถเห็นและซิงค์ใหม่ (และบางครั้งก็ทำแบบสุ่มสี่สุ่มห้า)

— FrustratedWithFormsDesigner

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

— Rein Henrichs

@ Rein Henrichs: ฉันจะไม่เถียงสิ่งนั้น !!

— FrustratedWithFormsDesigner

1

ทันทีที่สอดคล้องกันงานที่จะทำ งานเป็นส่วนหนึ่งของเป็นเรื่องของผู้ใช้

งานจะทำเมื่อ:

การทดสอบหน่วยที่เกี่ยวข้องผ่าน
รหัสมีเอกสารอย่างถูกต้องและ
รหัสถูกผูกมัด

คุณสามารถให้คำจำกัดความที่แตกต่างกันได้

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

1

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

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

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

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

นี่คือวิธีการทำงานกับ Git แต่ตัวการใช้กับการควบคุมเวอร์ชันใด ๆ

— Jasper Kennis
แหล่งที่มา

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

— ริ้น

การแบ่งส่วนนั้นไม่ได้เป็นการคอมไพล์ มันสามารถทำได้กับการควบคุมเวอร์ชันทุกชนิดนี่เป็นเพียงตัวอย่างที่ฉันรู้ว่า Git สร้างมันขึ้นมาแล้ว

— Jasper Kennis

-1

เมื่อ:

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

— quant_dev
แหล่งที่มา

upvoted สำหรับสิ่งนี้คือแนวปฏิบัติที่ดีที่สุดของเรา

— jersoft