คุณปลดอาวุธโคบาลคาวบอยได้อย่างไร [ปิด]


37

ฉันพบคำถาม (รหัสโคบาลของทีม) แต่มันเกี่ยวข้องกับ "Ninja Coder" มากกว่าปัญหาที่ฉันมี

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

เขาปฏิเสธที่จะฟังทีมและเมื่อเร็ว ๆ นี้เขาได้หยุดการตรวจสอบโค้ดการทดสอบหน่วยการแบ่งปันรายละเอียดการใช้งาน ฯลฯ

ใช่เขา "รหัส" เร็ว แต่รหัสของเขาเป็นเพียงตัวสร้างบั๊ก สมาชิกในทีมคนอื่น ๆ และฉันอยู่ใน "ขั้นตอนการแก้ไขข้อบกพร่อง" และ 80% ของข้อบกพร่องมาจากรหัสของเขา ฉันไม่ต้องการแก้ไขข้อบกพร่องของเขา และผู้บริหารก็ตาบอดหรือไม่ต้องการเห็นสิ่งนี้หรือบางทีพวกเขาอาจชอบความเร็วของเขา

มีวิธีใดบ้างที่ฉัน (ในฐานะเพื่อนร่วมงานอายุน้อยกว่าไม่ใช่เจ้านายของเขา) สามารถทำอะไรกับมันได้บ้าง?

ฉันจะปลดอาวุธโคบาลโคบาลนี้ได้อย่างไร

ฉันรู้สึกเหมือนฉันเป็นคนสุดท้ายที่ใส่ใจโครงการอย่างแท้จริง


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

8
ภายใต้อำนาจของผู้ที่เขาหยุดความคิดเห็นรหัส?
OtávioDécio

14
ดังนั้น ... คุณไม่มีใครจัดการเรื่องนี้ นั่นเป็นปัญหาของคุณไม่ใช่รหัสโคบาล
OtávioDécio

3
หากเป็นเช่นนั้นการต่อสู้ก็ดีสำหรับกระบวนการใด ๆ เมื่อทั้งหมดอยู่ในความดูแลไม่มีใครอยู่ในความดูแลและผลิตภัณฑ์ทนทุกข์ทรมานจากผลกระทบของผู้ยืนดู
OtávioDécio

7
แต่เราจะปลดอาวุธ "close thread" cowboys ได้อย่างไร ...
Rig

คำตอบ:


21

ฉันเห็นตัวเลือกไม่กี่:

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

6

เขาปฏิเสธที่จะฟังทีมและเมื่อเร็ว ๆ นี้เขาได้หยุดการตรวจสอบโค้ดการทดสอบหน่วยการแบ่งปันรายละเอียดการติดตั้ง ...

การตรวจสอบโค้ดไม่จำเป็นต้องให้ผู้ให้รหัสส่งงานเพื่อตรวจสอบ

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

ใช่เขา "รหัส" เร็ว แต่รหัสของเขาเป็นเพียงตัวสร้างบั๊ก สมาชิกในทีมคนอื่น ๆ และฉันอยู่ใน "ขั้นตอนการแก้ไขข้อบกพร่อง" และ 80% ของข้อบกพร่องมาจากรหัสของเขา ฉันไม่ต้องการแก้ไขข้อบกพร่องของเขา และผู้บริหารก็ตาบอดหรือไม่ต้องการเห็นสิ่งนี้หรือบางทีพวกเขาอาจชอบความเร็วของเขา

รหัสมาจากข้อกำหนด ผลความต้องการในการทดสอบ runnable ที่ตรวจสอบความต้องการได้รับการตอบสนอง การทดสอบเหล่านั้นสามารถแบ่งย่อยได้อีกและสามารถเขียนได้ก่อนการเปลี่ยนแปลงเพื่อตรวจสอบว่าการเปลี่ยนแปลงนั้นตรงตามข้อกำหนด (แดง - เขียว - refactor; สาระสำคัญของ TDD)

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

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

มีวิธีใดบ้างที่ฉัน (ในฐานะเพื่อนร่วมงานอายุน้อยกว่าไม่ใช่เจ้านายของเขา) สามารถทำอะไรกับมันได้บ้าง?

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

ฉันรู้สึกเหมือนฉันเป็นคนสุดท้ายที่ใส่ใจโครงการอย่างแท้จริง

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


5

ไปที่การจัดการด้วยสถิติของคุณเกี่ยวกับจำนวนข้อบกพร่อง / ปัญหาที่มาจากนักพัฒนารายนี้ อธิบายให้พวกเขาฟังว่าการแก้ไขบั๊กส่งผลกระทบต่อประสิทธิภาพการทำงานของทีม หาก 80% ของปัญหามาจากคนคนหนึ่งจริง ๆ นั่นต้องได้รับการแก้ไขอย่างแน่นอน ตราบใดที่คุณอธิบายให้ฝ่ายบริหารจัดการเห็นด้วย (เช่น "เสียเวลาคือเสียเงิน") พวกเขาจะเข้าไปแทรกแซง

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


4

มีวิธีใดบ้างที่ฉัน (ในฐานะเพื่อนร่วมงานอายุน้อยกว่าไม่ใช่เจ้านายของเขา) สามารถทำอะไรกับมันได้บ้าง?

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


1
โคเดอร์โคบาลอาจได้รับการยกเว้นจากความกดดันหากผู้บริหารไม่เข้าใจถึงผลกระทบที่แท้จริงของเขาพวกเขาอาจตาบอดเพราะผลกระทบที่รับรู้ของเขา
mhoran_psprep

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

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

0

เขาปฏิเสธที่จะฟังทีมและเมื่อเร็ว ๆ นี้เขาได้หยุดการตรวจสอบโค้ดการทดสอบหน่วยการแบ่งปันรายละเอียดการติดตั้ง ...

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


แน่นอนว่าเรามีกระบวนการและเอกสารมากมาย แต่มันเกี่ยวกับผู้คนที่พวกเขาใช้มันอย่างไร
Adronius

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

ไม่แน่นอน แต่เป็นประเภท เขาทำการเปลี่ยนแปลงโค้ดจากนั้นเขาก็ทำตามขั้นตอน "เป็นทางการ" เพื่อทำโค้ด review = ใช้เครื่องมือบางอย่างเท่านั้นเองดังนั้นโค้ดจึงมีสถานะ "ตรวจสอบ" หรือขอคู่ครองของเขา (ซึ่งไม่สนใจรหัส) "ตรวจสอบ" รหัสของเขา จากนั้นเขาก็ "อธิบาย" รหัสในหนึ่งนาทีและเสร็จสิ้น Huray และเขาไปส่งการเปลี่ยนแปลง
Adronius
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.