การเขียนโปรแกรมแบบจับคู่ทั่วไปในที่ทำงานเป็นอย่างไร?


16

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

ฉันสงสัยว่านี่เป็นเพราะเงิน / เวลา (หัวหน้าผมมีจุดพบคนสองคนที่คอมพิวเตอร์เครื่องหนึ่งทำงานด้วยรหัสเดียวกัน !!!! พวกเขากล้า!) หรือด้วยเหตุผลอื่น?


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

3
ยากมากที่จะโน้มน้าวเจ้านายที่มีผมหงอกว่านี่มีค่า
วอลเตอร์

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

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

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

คำตอบ:


20

ฉันมีกิ๊กเดียวกันเป็นเวลา 15 ปีและเมื่อเร็ว ๆ นี้ (12-18 เดือนล่าสุด) เริ่มใช้เทคนิค Agile เมื่อมีการใช้การเขียนโปรแกรมแบบคู่เรื่องราว / คุณลักษณะของผลลัพธ์ได้ถูกนำไปใช้งานตรงเวลาโดยไม่มีข้อบกพร่องน้อยลง ฉันยังไม่คิดว่ามันถูกใช้บ่อยพอ

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

  • ไซโลลดลงในทีม (ชนะมากเมื่อทีม 6-8 devs)
  • ผลิตรหัสด้วยข้อบกพร่องน้อยลง
  • โดยทั่วไปแล้ว dev แต่ละตัวจะหยิบทักษะจากมัน

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


DevSolo มีความเข้าใจที่ดีขอบคุณสำหรับการแบ่งปัน ฉันคาดเดาคุณอาจมีค่อนข้างทีมงานที่มีเสถียรภาพ (มูลค่าการซื้อขายต่ำของบุคลากร?)
Ozz

ยินดี. การหมุนเวียนของเราค่อนข้างต่ำ ... เรา 4 คนได้ใช้สำนักงานร่วมกันเป็นเวลา 15 ปีแม้ว่าจะมีการย้ายถิ่นฐาน 4 ครั้ง (ทั่วทั้ง 4 อาคารและ 2 รัฐ)!
DevSolo

แดกดันนามแฝงของคุณคือ 'DevSolo';) nb ประสบการณ์ของฉันเห็นด้วยกับคุณ
ChrisAnnODell

11

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


Pemdas จริงมาก!
ozz

2
+1 น่าเสียดาย การทำงานเป็นทีมเป็นทักษะที่คุณต้องพัฒนาและถ้าคุณไม่ต้องการคุณก็ทำไม่ได้ อาจเป็นสิ่งที่ผู้จัดการของโปรแกรมเมอร์ควรทำ - หาโครงสร้างทีมที่ส่งเสริมการผลิตมากที่สุดกับคนที่พวกเขามี
Michael K

4
อาชีพนี้ต้องรักษาอัตตาของตนเองไว้ ไม่ใช่เรื่องง่ายเสมอไป แต่รางวัลจะเป็นประโยชน์อย่างยิ่ง
DevSolo

@DevSole ... มันเกี่ยวข้องกับคำตอบของฉันอย่างไร?
Pemdas

@Perdas ฉันถูกสมมติว่าอาจไม่ถูกต้องว่าการต่อต้านจะเกิดจากอัตตา อย่างน้อยเมื่อฉันเห็นมันก็เป็นเหตุผล ฉันเห็นเพียง 2 (ที่ฉันจำได้) devs ต่อต้านสิ่งนี้จริงๆ อัตตาหนึ่งไม่พอดีในห้องอื่น ๆ มีปัญหา w / ความมั่นใจ
DevSolo

9

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

หวังว่ามันจะทำได้มากขึ้น


4
อีกเครื่องมือที่ใช้ถ้าคุณไม่คุ้นเคยเรียกว่า "Rubber Ducking" โดยพื้นฐานแล้ววางวัตถุบนโต๊ะของคุณเหมือนเป็ดยาง (คุณใช้ของเล่นโยดาอย่างแท้จริง) แล้วอธิบายปัญหาที่เกิดขึ้น ดูc2.com/cgi/wiki?RubberDucking
DevSolo

ฉันใช้คนที่นั่งถัดจากฉันแทน ... เราไม่สามารถวางสิ่งของบนโต๊ะทำงานของเรา
CaffGeek

อย่างจริงจัง?
Michael K

@Michael ... คุณไม่มีความคิดกฎที่เรามีที่นี่ และยังมีสิ่งที่ดีเพียงไม่กี่อย่างที่เกินความเลวทั้งหมด ... แทบจะไม่
CaffGeek

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

9

ฉันไม่สนใจมัน:

1 - ฉันชอบฟังเพลงขณะที่มีการเข้ารหัส ทุกคนไม่ต้องการได้ยิน Slayer ที่ระเบิดในหูของพวกเขา

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

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

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

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

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

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


2
@Noah จาก # 2 เพียงผู้เดียวฉันไม่แน่ใจว่าคุณเข้าใจแนวคิดของการเขียนโปรแกรมคู่หรือไม่ ความคิดที่จะไม่มองข้ามไหล่ ความคิดที่ฉันได้ฝึกฝนนั้นคือการแบ่งปันพีซีให้ทำงานควบคู่กัน มันไม่ใช่การเขียนโปรแกรมต้นแบบ / ทาส แต่เป็นโปรแกรมแบบเพียร์ บางทีในภายหลังเป็นคำที่ดีกว่าสำหรับมัน ...
DevSolo

นี้ถูกต้องสมบูรณ์ บางคนแค่อยากจะถูกทิ้งให้อยู่ตามลำพังเพื่อคิดออกเอง
MattC

และ +1 สำหรับสิ่งหูฟัง ฉันระเบิดโลหะและ / หรือความมึนงงตลอดทั้งวันและรำคาญมากเมื่อมีคนพูดกับฉันเกี่ยวกับสิ่งของ พวกเขาไม่สามารถรอจนกว่าเพลงโปรดของฉันจะจบหรือไม่ : D
MattC

2
@Noah: กำลังอ่านรายการของคุณดูเหมือนว่าคุณไม่มีคะแนนปลีกย่อยของการเขียนโปรแกรมคู่ ฉันไม่ได้บอกว่าสำหรับทุกคนและแน่นอนต้องใช้เวลาและความพยายามในการเปลี่ยนจากโหมดคาวบอยเป็นโหมดการแบ่งปัน เช่นเดียวกับที่ต้องใช้เวลาในการเรียนรู้วิธีการทำ TDD อย่างถูกต้อง (หรือวิธีปฏิบัติอื่น ๆ ที่คล่องตัวสำหรับเรื่องนั้น)
Martin Wickman

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

5

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

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


น้อยกว่าที่ฉันต้องการแน่นอน
ozz

5

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


3

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

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

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