ฉันควรบอกใครสักคนว่าความมุ่งมั่นของพวกเขาทำให้เกิดการถดถอยหรือไม่?

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

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

หากเป็นความคิดที่ดีที่จะบอกพวกเขาสิ่งที่ดีในการทำโดยไม่ก่อให้เกิดความผิดหรือทำให้พวกเขาได้รับการป้องกันคืออะไร?

สมมติว่ามีข้อโต้แย้งว่าข้อบกพร่องนั้นบอบบางพอที่การทดสอบอัตโนมัติของเซิร์ฟเวอร์ CI ไม่สามารถรับได้

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

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

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

จากนั้น:

พวกเขา:แน่นอนว่าต้องจัดการ... สถานการณ์ที่ฉันไม่ทราบ ...

หรือบางสิ่งตามแนวของ:

พวกเขา: ไม่ขอโทษฉันจำไม่ได้, ดูเหมือนฉันผิด

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

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

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

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

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

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

ใช่เสมอ ในฐานะโปรแกรมเมอร์คุณต้องเรียนรู้จากความผิดพลาด

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

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

หากมันเกี่ยวข้องกับการอธิบายผู้คนถึงวิธีที่จะไม่แนะนำบั๊กให้ลองทำดู

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

โดยทั่วไปใช่

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

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

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

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

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

หากฉันส่งมอบข้อผิดพลาดที่มีข้อผิดพลาดคุณควรบอกฉัน หากฉันพบความมุ่งมั่นของคุณที่มีข้อบกพร่องฉันจะบอกคุณอย่างแน่นอน

เราจะปรับปรุงก็ต่อเมื่อเราเข้าใจข้อผิดพลาดของเรา นั่นคือวิธีที่เราผลิตรหัสที่ดีขึ้นในอนาคต

คุณได้รับคำตอบที่ยอดเยี่ยมที่นี่

ฉันสามารถเพิ่มเทคนิคที่ฉันเรียนรู้จากผู้จัดการเพียงครั้งเดียวเมื่อฉันทำผิด

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

เธอพูดกับฉันด้วยน้ำเสียงเกือบขอโทษที่ดูเหมือนว่าจะมีปัญหาและฉันจะมีเวลาตรวจสอบหรือไม่

บ่อยครั้งที่ความผิดพลาดนั้นเป็นของฉันและเธอก็รู้ นั่นคือทักษะ

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

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

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

มีแรงฉุดที่ดีสำหรับคำถามของคุณ! ทุกคนบอกคุณว่าต้องทำอะไร คุณควรบอกหรือไม่ ใช่! เมื่อใดก็ตามที่คำถามถามว่า "ฉันควรสื่อสารมากขึ้นหรือไม่" คำตอบคือเกือบทุกครั้งใช่!

แต่เพื่อเพิ่มสิ่งที่แตกต่าง: หลักฐานของคุณมีข้อบกพร่อง

เพื่อนร่วมงานได้แสดงความมุ่งมั่นที่ไม่ทำลาย CI แต่นำคุณไปสู่การค้นพบปัญหา

ยินดีด้วย! คุณพบข้อบกพร่องใหม่ไม่ใช่การถดถอย อย่างจริงจังคุณทดสอบด้วยตนเองทุกสถานการณ์และบรรทัดของรหัสที่ไม่ครอบคลุมโดยการทดสอบอัตโนมัติ (หรือคู่มือมาตรฐาน) เมื่อคุณส่งมอบ?

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

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

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

บอกพวกเขาเมื่อมันมีเพียงคุณสองคน

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

ดังนั้นคุณไม่ควรลังเลที่จะพูดว่ามีคนทำผิดพลาด นี้มันแค่ธรรมดา. ทุกคนทำผิดพลาดแม้แต่สิ่งที่ดีที่สุด! เฉพาะผู้ที่ไม่ทำอะไรเลยไม่มีข้อผิดพลาด;)

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

เหตุใดฉันจึงไม่เห็นคำตอบเดียวที่นี่ซึ่งสะท้อนถึงความคิดเห็นที่โหวตที่สุดในคำถาม?

ใช่บอกพวกเขาอย่างแน่นอนเกี่ยวกับเรื่องนี้ แต่อย่าทำต่อหน้าทีมทั้งหมด

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

ฉันมักจะพบว่ามันทำงานได้ดีที่สุดเมื่อคุณเริ่มต้นด้วยการชมเชยและจากนั้นได้รับข้อผิดพลาด ... บางสิ่งบางอย่างเช่น "การแก้ไขที่คุณใช้งานได้ดี แต่ดูเหมือนว่าจะมี x, y, z" หรือ "ขอบคุณสำหรับการทำ , b, c, แต่ดูเหมือนว่าจะทำให้ x, y, z "

คำตอบง่ายๆ: ใช่

คำตอบอีกต่อไป: งานล่าสุดของฉันคือ บริษัท Agile ที่ใช้ TDD กับเครื่องมือ CI เพื่อให้แน่ใจว่าสิ่งที่อยู่ใน repo SVN ของเรานั้นดีรหัสทำงานตลอดเวลา เมื่อมีบางสิ่งเกิดขึ้นเซิร์ฟเวอร์ TeamCity ของเราจะได้รับสำเนารวบรวมและทดสอบหน่วย นอกจากนี้ยังมีการทดสอบการรวมเป็นรายชั่วโมง หากมีข้อผูกมัดที่ทำให้ CI ล้มเหลวทุกคนจะได้รับอีเมลที่ระบุว่างานสร้างนั้นพังตามความมุ่งมั่นของบุคคลใดบุคคลหนึ่ง

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

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

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

มีหลายปัจจัยในการเล่น

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

หากปัญหานั้นน้อย - ตัวพิมพ์ผิด / thinko / cut & paste bug - และตัวแบ่งเป็นเพียร์ไม่ว่างและคุณมั่นใจในการประเมินปัญหาของคุณคุณอาจไม่จำเป็นต้องสนใจมัน (เช่นfoo.x = bar.x; foo.y = bar.y, foo.z = bar.y)

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

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

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

จะเกิดอะไรขึ้นถ้าคุณไม่บอกพวกเขา

ข้อเสีย

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

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

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

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

ข้อดี

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

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