ทำอย่างไรจึงจะรักษาประสิทธิภาพได้เมื่องานสร้างเสียหายเกือบตลอดเวลา


25

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

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

ต้องบอกว่าในระหว่างวันทุกคนมีหน้าต่างประมาณ 10-15 นาทีซึ่งเราอนุญาตให้เช็คอิน

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

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


8
ทำไมคุณถึงไม่มีสาขา
ช่วยให้รอด

6
วิธีแก้ปัญหาที่ชัดเจนคือการตั้งสาขา "ส่วนบุคคล" ของคุณและผูกไว้กับมันจากนั้นรวมสาขานั้นเข้ากับสาขาที่ทีมทำงาน
gnat

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

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

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

คำตอบ:


54

เพื่อเริ่มต้นกับความคิดเห็นนี้:

... การมีสาขาหมายถึงความซับซ้อนเป็นพิเศษและทำให้การทำงานพิเศษ ...

เป็นเท็จทั้งหมด ฉันมักจะได้ยินจากคนที่ไม่คุ้นเคยกับการแตกแขนง แต่ก็ยังผิด

หากคุณมีนักพัฒนาหลายคนสะสมการเปลี่ยนแปลงในพื้นที่การเปลี่ยนแปลงในท้องถิ่นของพวกเขาเป็นสาขา de-พฤตินัยของพื้นที่เก็บข้อมูลหลัก

ในที่สุดเมื่อพวกเขาผลักดันนี้เป็นผสานพฤตินัย

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


ตอนนี้คุณพูด

ไม่มีใครได้รับอนุญาตให้เช็คอินในขณะที่สร้างเป็นสีแดง

แต่ในกรณีนี้การสร้างไม่สามารถแก้ไขได้ดังนั้นจึงไม่ถูกต้องนัก

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

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

โดยทั่วไปแล้วคำตอบที่จะ

ทำอย่างไรจึงจะรักษาประสิทธิภาพได้เมื่องานสร้างเสียหายเกือบตลอดเวลา

คือหยุดการทำลายการสร้าง


23
+9000 สำหรับ "หยุดการทำลายโครงสร้าง" อย่างจริงจัง. จุดรวมทั้งหมดของการรวมอย่างต่อเนื่องคือการหยุดการสร้างและถ้าแตกให้แก้ไขอย่างรวดเร็วและใกล้กับจุดพักมากที่สุด
Patrick Hughes

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

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

14

นักพัฒนา ... สะสมการเปลี่ยนแปลงในพื้นที่ ... คุณสามารถเห็นวงจรอุบาทว์

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

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

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

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

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

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

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


7

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

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

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

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


5

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

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

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

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


-2 และไม่มีใครต้องการที่จะแบ่งปันว่าทำไม .. เฮ้
hequ

1
คุณไม่สามารถสร้างไข่เจียวได้โดยไม่ทำให้ไข่แตก
William Payne

2

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

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


1

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


3
แต่เพื่อให้งานนี้เป็นไปไม่ได้ "... โปรดจำไว้ว่าฉันเป็นนักพัฒนาไม่ใช่ผู้จัดการและไม่สามารถเปลี่ยนกระบวนการ ... "
SChepurin

@Schepuri กระบวนการของคุณไม่มีประสิทธิภาพคุณต้องเปลี่ยนกระบวนการระยะเวลา ในฐานะนักพัฒนาคุณอาจไม่สามารถอนุมัติการเปลี่ยนแปลง แต่คุณสามารถทำงานเพื่อปรับปรุงกระบวนการได้เสมอ
oefe

1

อีกสองสิ่งที่สามารถช่วยได้ที่นี่:

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

แต่คุณควรดูที่สาขาจริงๆ

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.