คำถามติดแท็ก pair-programming

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

55 teamwork  code-reviews  pair-programming 

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

50 agile  pair-programming 

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

32 project-management  agile  scrum  pair-programming  extreme-programming 

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

30 agile  pair-programming 

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

28 agile  pair-programming 

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

22 design  programming-practices  pair-programming 

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

20 teamwork  collaboration  team-leader  pair-programming 

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

20 agile  pair-programming 

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

17 pair-programming  flow 

ฉันทำงานในทีมการเขียนโปรแกรม eXtreme และทำการเขียนโปรแกรมแบบคู่มานานกว่า 7 ปีในสภาพแวดล้อมแบบ windows เมื่อเราเริ่มทำมันใครบางคนจะเข้าสู่ระบบด้วยข้อมูลประจำตัวของ windows ของพวกเขาและดังนั้นการเข้าถึงทรัพยากรโดเมนและการควบคุมรุ่นที่เฉพาะเจาะจงมากขึ้นทั้งหมดจะต้องรับผิดชอบต่อผู้ใช้ windows ที่ ในที่สุดเราก็ได้พัฒนาให้บัญชีการจับคู่ windows สำหรับสถานีจับคู่ที่เฉพาะเจาะจง (เช่น pairA, pairB, PairC ฯลฯ …) devs ทั้งหมดรู้รหัสผ่านของบัญชีเหล่านี้ ความรับผิดชอบต่อการกระทำ (เช็คอิน) ทำได้โดยการใส่ชื่อย่อของโปรแกรมเมอร์ไว้ในคอมเม้นต์ระหว่างการคอมมิท จนถึงตอนนี้สิ่งนี้ใช้ได้ดีสำหรับเรา แต่ปัจจุบัน บริษัท ของฉันกำลังผ่านการตรวจสอบ ISO 27001 และผู้ตรวจสอบบัญชีถูกตั้งค่าสถานะเป็นความเสี่ยง ฉันมีวิธีแก้ปัญหาที่เป็นไปได้หลายอย่างเช่นการสร้างบัญชีการจับคู่สำหรับชุดค่าผสมทุกคู่ แต่ฉันอยากทราบว่ามีคนอื่นประสบปัญหานี้หรือไม่และพวกเขาแก้ไขได้อย่างไร ผู้ตรวจสอบยอมรับวิธีการแก้ปัญหาอะไรบ้าง

16 pair-programming  iso 

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

16 development-process  pair-programming 

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

15 pair-programming  metrics 

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

15 agile  pair-programming 

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

14 agile  code-reviews  pair-programming  extreme-programming 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว คุณเคยมีประสบการณ์เกี่ยวกับบุคคลที่ไม่ได้ทำงานกับโปรแกรมเมอร์ในระหว่างกระบวนการเข้ารหัสหรือไม่? มันเหมือนกับการเขียนโปรแกรมคู่ แต่บุคคลหนึ่งเป็นบุคคลที่ไม่ใช่ด้านไอทีที่รู้เรื่องธุรกิจเป็นอย่างมากอาจเป็นวิศวกรกระบวนการที่มีพื้นฐานทางคณิตศาสตร์ที่รู้วิธีคำนวณสิ่งต่าง ๆ และสามารถเข้าใจโค้ดที่ไม่ใช้สำนวนได้ ฉันพบว่าบางภาษาเฉพาะโดเมนเช่น PL / SQL นั้นค่อนข้างเข้าใจได้ง่ายโดยวิศวกรที่ไม่ใช่ไอที บุคคลเหล่านี้เป็นผู้เขียนรหัสและรับประกันความถูกต้องของสูตรปัจจัย ฯลฯ ฉันพบว่าการเขียนโปรแกรมคู่ชนิดนี้มีประสิทธิภาพมากผู้ใช้ประเภทวิศวกรรมรู้สึกว่าพวกเขายังเป็น "เจ้าของ" และ "ผู้เขียน" ของรหัสและช่วยลดความเข้าใจผิดในกระบวนการสื่อสาร พวกเขายังช่วยออกแบบกรณีทดสอบ การปฏิบัตินี้เป็นเรื่องปกติหรือไม่ มันมีชื่อหรือไม่? คุณเคยมีประสบการณ์คล้าย ๆ กันบ้างไหม?

14 teamwork  requirements  client-relations  business-logic  pair-programming