โปรแกรมเมอร์ควรแก้ไขงานสร้างที่ล้มเหลวของคนอื่นหรือไม่? [ปิด]

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

โปรแกรมเมอร์คนที่สองทำสิ่งที่ถูกต้องหรือควรรอจนกระทั่งโปรแกรมเมอร์คนแรกแก้ไขปัญหาได้หรือไม่

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

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

มันขึ้นอยู่กับ.

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

• โครงการอยู่ในเฟสที่การเปลี่ยนแปลงทั้งหมดจะต้องเชื่อมโยงกับตั๋วที่มีอยู่หรือไม่ ถ้าเป็นเช่นนั้นคุณยื่นตั๋วหรือไม่ ตั๋วนั้นมอบให้คุณหรือไม่?

อย่างไรก็ตามให้ความสำคัญกับการแก้ไขข้อผิดพลาดไม่ได้อยู่ที่การตำหนิผู้รับผิดชอบ

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

ชื่อเสียงของคุณคือ 100% ในการควบคุมของคุณ สิ่งเช่นนี้ทำให้ชื่อเสียงของคุณเสื่อมเสียและการพยายามขัดชื่อเสียงที่เสื่อมเสียนั้นยากมาก

สื่อสาร

ไม่มีกฎที่เข้มงวด (ข้างกฎทีมของคุณเอง) สำหรับสถานการณ์เหล่านั้น

Dev2 ควรจะบอก dev1 ได้ว่าเขาสามารถแก้ไขข้อผิดพลาดได้ไม่ว่าใครก็กลัวสิ่งที่เกิดจากการแลกเปลี่ยนพวกเขาเป็นส่วนหนึ่งของทีม

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

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

อย่างที่ได้รับการกล่าวว่าคนที่แก้ไขมันควรจะส่งอีเมลถึงคนที่ทำลายมันและรายละเอียดว่าการแก้ไขคืออะไร

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

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

การมีสคริปต์ 'ชี้นิ้วแห่งการตำหนิ' เป็นวิธีที่ดีในการทำเช่นนี้หรือทำให้คนที่ทำลายการซื้อโดนัท !!

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

ฉันเห็นด้วยกับข้อเสนอแนะของลุคเกรแฮมในการส่งอีเมลอธิบายแม้ว่าฉันจะบอกว่ามันเป็นมากกว่าความสุภาพ - เป็นการสื่อสารขั้นพื้นฐาน

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

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

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

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

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

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

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

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

มันขึ้นอยู่กับว่า ...

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

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

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

ในสภาพแวดล้อมอื่น ๆ มันหยาบคายหรือคาดหวังมากด้วยเหตุผลที่ไม่ดี

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

ครั้งแรก 'กลับบ้าน' เป็นสมัย โปรแกรมเมอร์ไม่กลับบ้านอีกต่อไป - เป็นเพียงออนไลน์หรือออฟไลน์ คุณสามารถปิงและรอ

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