วิธีการขอโทษเมื่อคุณทำลายสิ่งก่อสร้างตอนกลางคืน [ปิด]

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

การเป็นผู้พูดภาษาอังกฤษที่ไม่ใช่เจ้าของภาษาฉันมีปัญหาในการหาคำที่ถูกต้อง มีคนช่วยได้ไหม

อย่าขอโทษ!

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

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

ถ้าเป็นเช่นนั้นนี่จะเป็นอีกสิ่งที่คุณไม่ควรขอโทษ แน่นอนมันเป็นรูปแบบการต่อต้านทีม

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

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

ฉันรักคำขอโทษเพื่อนร่วมงาน ขอโทษอร่อยอร่อย

คำพูดสองคำสำหรับคุณ:

คนที่ทำผิดพลาดมักไม่ทำอะไรเลย - วิลเลียมคอนเนอร์มากี

ใครก็ตามที่ไม่ทำผิดพลาดนั้นไม่ได้พยายามอย่างหนักพอ - Wess Roberts

ฉันเห็นด้วยกับจิมจีอย่าขอโทษ แต่เรียนรู้จากมันและอย่าทำผิดพลาดอีกครั้ง ... ให้มันแห้ง)

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

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

เราเอาอะไรบางอย่างที่แตกหักไปและเปลี่ยนมันเป็นการฝึกสร้างทีม

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

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

• แสดงความเสียใจ
• ระบุปัญหา
• รับผิดชอบ
• ทำการชดใช้
• บันทึกหน้า

นั่นคือ "ฉันขอโทษ [ทะเบียนด่วน] ที่ฉันทำให้คุณไม่สะดวก [ใช้ความรับผิดชอบ] โดยบังเอิญ [SAVE FACE] ทำลายการสร้าง [ปัญหาของรัฐ] โดนัทมาหาฉันในวันพรุ่งนี้ [แก้ไขข้อผิดพลาด]"

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

ในที่สุดความคิดบางอย่างเกี่ยวกับการสร้างความเสียหาย:

ฉันทำงานกับทีมคอมไพเลอร์ C # / Visual Basic แน่นอนว่าวันนี้ Visual Studio เป็นโครงการขนาดใหญ่ที่มีทีมงานของตัวเองเพียงจัดการโครงสร้างพื้นฐานและห้องขนาดใหญ่พร้อมระบบปรับอากาศเฉพาะของตัวเอง ย้อนกลับไปในช่วงกลางทศวรรษ 1990 เมื่อฉันเริ่มเป็นนักศึกษาฝึกงานทีมสร้าง Visual Basic คือผู้ฝึกงานคนหนึ่ง - ฉัน - และตู้เสื้อผ้าที่เต็มไปด้วยเครื่องจักร เวลาเปลี่ยนไป!

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

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

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

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

อย่างไรก็ตามจดหมายขอโทษอย่างเป็นทางการอาจจะมากเกินไป

กฎพื้นฐาน - เมื่อคุณผิด ADMIT IT: - | คุณไม่ต้องขอโทษด้วยซ้ำ ทุกคนทำผิดพลาด ข้อดียอมรับมัน นั่นคือการทำงานเป็นทีม สมาชิกในทีมคนอื่น ๆ ควรดึงเข้าหากันเพื่อช่วยคุณ หากพวกเขาทำไม่ได้ขอความช่วยเหลือ สิ่งที่ต้องกล่าวมากที่สุดในภายหลังคือ - เราเรียนรู้อะไรได้บ้าง?

พวกเขากล่าวว่าการแต่งงานที่ประสบความสำเร็จขึ้นอยู่กับคำพูดเล็ก ๆ น้อย ๆ สามคำ - "ฉันผิด"

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

คำขอโทษที่ดีที่สุดคือแก้ไขการหยุดพักอย่างรวดเร็ว

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

หากเพื่อนร่วมงานของคุณทดสอบการเปลี่ยนแปลงอย่างมีชีวิตชีวาและคาดว่าจะพบกับการหยุดพักในตอนกลางคืน (C) คุณมีกระบวนการที่เปราะบาง (และคุณจำเป็นต้องแนะนำการทดสอบเช่นเดียวกับที่พบใน Extreme Programming)

เป็นไปได้ว่า (D) การเปลี่ยนแปลงของคุณทำให้เกิดการเปลี่ยนแปลงที่ไม่คาดคิดในรหัสของบิลที่เกิดขึ้นก่อนหน้านี้หรือมีการเปลี่ยนแปลงในบิลด์เดียวกับของคุณ

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

• (A) ฉันล้มเหลวในการทดสอบการสร้าง แต่ตรวจสอบในการเปลี่ยนแปลงของฉัน ขออภัยฉันกำลังเปลี่ยนกระบวนการของฉันดังนั้นฉันจะไม่ทำมันอีกครั้ง
• (B) ฉันผ่านการทดสอบการสร้างและเพิ่มการทดสอบ JUnit XYZtest.java เพื่อลดโอกาสที่จะเกิดขึ้นอีกครั้ง
• (C) เนื่องจากเราไม่มีกระบวนการทดสอบการสร้างฉันจึงสร้างหนึ่งสำหรับการเปลี่ยนแปลงของฉัน ฉันต้องการแบ่งปันกับคุณว่าเราสามารถปรับปรุงกระบวนการสร้างของเราได้อย่างไร
• (D) ฉันจะทำงานร่วมกับ Bill เพื่อเขียนการทดสอบ JUnit XYZtest.java เพื่อลดโอกาสที่จะเกิดขึ้นอีกครั้ง

ฉันแน่ใจว่ามี (E) ที่ฉันไม่ได้คิด

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

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

สำหรับคนที่กระโดดข้ามคุณ ... ฉันอยากรู้ว่าพวกเขาเคยเขียนด้วยข้อผิดพลาดหรือเปล่า

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

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

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

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

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

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

ตามกฎทั่วไปฉันจะพูดว่า:

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

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

ทีมล้มเหลว

บริษัท ของคุณต้องการการตรวจสอบโค้ดเพิ่มเติมเกี่ยวกับการพัฒนาครั้งแรก

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

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

หากปล่อยของคุณไม่สามารถยกเลิกได้อย่างง่ายดายมีปัญหาที่ใหญ่กว่ากับกลุ่มนี้

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

แต่อีกครั้งถ้าคุณเป็นหนึ่งในคนที่สร้างหน้าต่างแตกแล้ว ... ฉันช่วยไม่ได้ (เป็นเรื่องยากที่จะทำ btw อย่างไม่น่าเชื่อก่อนที่ทุกคนจะตั้งคำถามกับ MS ที่สร้างปรัชญา แต่ตอนนี้มีคนทำแล้วและ QA ของ บริษัท ก็หยุดทำงานไปหนึ่งวัน

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

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

หากการทำลายการสร้างเป็นเรื่องใหญ่นั่นหมายความว่ากระบวนการของคุณเสีย

คุณควรทำงานสร้างต่อเนื่องไม่ใช่งานสร้างยามค่ำคืน

ดีกว่าตอบช้ากว่าไม่เคย ...

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

โดยส่วนตัวฉันเห็นงานสร้างที่เสียหายเป็นโอกาส

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

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

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

แต่ใช่ให้แน่ใจว่าได้แก้ไข ไม่ใช่เรื่องใหญ่. มันไม่ได้อยู่ในการผลิต แค่คืนที่ไร้ค่า

การปฏิบัติตามปกติใน บริษัท ของฉันคือ:

• ตะโกนว่า "ไม่ใช่ฉัน!" (โดยปกติจะเป็นหลักฐาน CVS / SVN เป็นอย่างอื่น)
• การสวมเสื้อยืดพูดว่า "my-userlogin ist Schuld!" (ใช่ 50% ของนักพัฒนาของเราเป็นเจ้าของเสื้อดังกล่าว)
• อ้างว่ามันใช้งานได้ในกล่องรับสัญญาณในเครื่องและการทดสอบทั้งหมดผ่านไปได้ด้วยดี

บริษัท ของฉันมีวิธีที่ดีในการจัดการกับ "เหตุการณ์" ดังกล่าว:

• คนงานต้องสวมเครื่องแต่งกายต่อไปนี้สำหรับครึ่งวัน ( http://www.tradoria.de/kostueme/kruemelmonster-sesamstrasse-kostuem-kruemelkostuem-337103661.html )

• ฉันจะไม่ขอโทษ

• ฉันจะโทษว่าเป็นผู้นำของ CI ที่อนุญาตให้ฉันสร้างงานที่เสียหาย

• ควรมีกระบวนการ CI เพื่อหยุดนักพัฒนาจากการส่งโค้ดที่เสียหาย

• หากการบิลด์ในเครื่องล้มเหลวไม่ควรอนุญาตให้เข้าสู่บิลด์เซิร์ฟเวอร์

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

หากคุณกำลังทำงานในโครงการโอเพ่นซอร์ส

เพียงแค่พูดว่า "ขอโทษนะฉันทำลายโครงสร้างอาจเป็นเพราะฉันง่วงเกินไป!"

และเพิ่มเป็นความคิดเห็น GitHub

เป็นเพราะนักพัฒนาซอฟต์แวร์โอเพนซอร์สหลายคนเขียนรหัสในช่วงเที่ยงคืน