จับคู่การเขียนโปรแกรมเมื่อผู้ขับขี่และผู้สังเกตการณ์มีระดับทักษะและประสบการณ์ต่างกัน

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

แต่ฉันแค่สงสัยว่ากลยุทธ์ยังคงใช้ได้ในกรณีนี้ ตัวอย่างเช่น

• หากพวกเขามีระดับทักษะการเขียนโปรแกรมที่แตกต่างกันมาก
• หากไม่มีประสบการณ์ในโดเมนปัญหาในขณะที่อีกคนหนึ่งมี
• มันยังใช้ได้ไหมถ้าพวกเขามีระดับทักษะการเขียนโปรแกรมต่ำ?

คุณสามารถแนะนำกลยุทธ์การเขียนโปรแกรมคู่ในกรณีข้างต้นได้หรือไม่?

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

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

นี่คือการเขียนโปรแกรมการใช้งานกรณีคู่ที่ถูกสร้างขึ้นสำหรับ: การแบ่งปันประสบการณ์ระหว่างหนวดเคราเก่าและตั๊กแตนวัยเยาว์

นี่คือการแบ่งปันแบบสองทาง: แมลงเปรียวมีอะไรมากมายที่จะสอนให้กับสมองรูมาติก

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

ฉันคิดว่าฉันเรียนรู้เพิ่มเติมเกี่ยวกับ Java2EE ในช่วง 4 เดือนนี้ด้วยการเขียนโปรแกรมคู่มากกว่าการอ่านหนังสือและหัวหน้าทีมได้เรียนรู้เกี่ยวกับแพลตฟอร์มเช่นกัน

ช่องว่างประสบการณ์ระหว่างคนทั้งสองเป็นกุญแจสำคัญในการจับคู่การเขียนโปรแกรม imho

ฉันจะอธิบายประสบการณ์ของฉันและพยายามใช้ "กลยุทธ์" ออกมา

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

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

ประโยชน์อีกอย่างคือการมุ่งเน้นที่งานง่าย ๆ ไม่มีสิ่งรบกวน (ฮ่า ๆ ๆ ลองจินตนาการถึงการเปิด Twitter ก่อนที่หัวหน้าของคุณจะได้)

บางครั้งมันก็ค่อนข้างน่ากลัวเพราะแม้กระทั่งช่วงพักดื่มน้ำชาก็กลายเป็น "ความฟุ้งซ่านจากการทำงาน" (ไม่ใช่จากมุมมองของเขา; มันไม่สะดวกที่จะขอหยุดพักและอื่น ๆ )

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

ฉันคิดว่ามันจะทำงานได้ดีขึ้นในกรณีที่เขามีทักษะการเขียนโปรแกรมขั้นพื้นฐานเพราะฉันไม่ต้องอธิบายว่า "อาเรย์คืออะไร"

หวังว่าจะช่วย :)

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

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

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

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