จับคู่ Programming / Collaboration ใน บริษัท ขนาดเล็ก

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

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

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

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

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

ฉันรู้ว่านี่ไม่ใช่สถานการณ์ที่เหมาะกับทุกคน แต่ฉันก็เต็มใจที่จะให้วิธีการที่หลากหลาย

เราทุกคนทำงานในพื้นที่ส่วนกลางนักพัฒนาไม่มีสำนักงาน / ห้องเล็ก ๆ

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

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

และหากวิธีนี้ จำกัด จำนวนโครงการที่ บริษัท ของคุณสามารถจัดการได้ในแต่ละครั้งคุณสามารถกำหนดโครงการที่ทำงานร่วมกันสองโครงการนี้พร้อมกันได้

เราเพิ่งทดลองกับวิธีการนี้มีหนึ่งในพวกเขาพัฒนารุ่น + การทำงานร่วมกับ APIs และจัดการโปรแกรมเมอร์อื่น ๆมุมมองและควบคุม เราพบข้อดีดังต่อไปนี้ของการตั้งค่านี้:

1. โครงสร้างรหัสผลลัพธ์ในวิธีที่ดีกว่ามากถ้าเพียงคนเดียวที่ทำงานในทุกด้านของโครงการ
2. เราไม่ต้องเตือนพวกเขาเกี่ยวกับการส่งรหัสไปยังที่เก็บ ฯลฯ
3. พวกเขาต้องใช้ความพยายามในการทดสอบรหัสของแต่ละคนแทนที่จะใช้รหัส QA เฉพาะของเราเท่านั้น

ในความคิดของฉันการเขียนโปรแกรมคู่ไม่ใช่วิธีแก้ไขปัญหาที่คุณยกระดับ

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

หากไม่มีไดนามิกนี้ประโยชน์ของการเขียนโปรแกรมคู่จะสูญหายไป

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

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

เกี่ยวกับวัฒนธรรมและคุณภาพ

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

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

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

ในที่สุดคุณภาพและคุณค่าเป็นคำจำกัดความของมนุษย์เพียงคุณหรือบุคคลอื่นในองค์กรของคุณสามารถ (และควร) คิด

การเขียนโปรแกรมคู่และการจัดการขนาดเล็ก

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

ในการป้องกันการเขียนโปรแกรมคู่: การเขียนโปรแกรมคู่ไม่ได้เกี่ยวกับผู้ชายบางคนมองข้ามไหล่ของผู้ชายคนอื่น นั่นคือขนาดเล็กเท่าที่การจัดการได้รับ PP เป็นเรื่องเกี่ยวกับการใช้สองจิตใจคิดเกี่ยวกับสองระดับในเวลาเดียวกัน - เป็นหนึ่งในข้อเสนอที่คนที่มีระดับสูง , ภาพใหญ่ปัญหาขณะที่อื่น ๆ ดูแลถั่วและ boltsจำเป็นในการผลิตรหัสการทำงาน และในความเห็นที่ต่ำต้อยของฉันมันไม่ค่อยได้ผลถ้าผู้เข้าร่วมทั้งสองไม่อยู่ในฐานะที่จะเปลี่ยนสถานที่ พวกเขาควรจะมีประสบการณ์ในทำนองเดียวกันมากพอที่จะมีคลังแสงระดับมืออาชีพที่คล้ายกันและคำศัพท์มืออาชีพที่ใช้ร่วมกัน (เรายังไม่ได้เชื่อมโยงใจ - ยัง muhahaha)

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

• กระตุ้นให้พวกเขามีส่วนร่วมใน SO ภายใต้แท็กภาษาที่เหมาะสมหรือโพสต์ตัวอย่างโค้ดเพื่อตรวจสอบ Code Review SE เริ่มการแข่งขันแบบไม่เป็นทางการเล็กน้อยเพื่อดูว่าใครจะได้รับคะแนนตัวแทนมากที่สุดต่อสัปดาห์

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

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

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

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

คำถามของฉันคือว่าทุกคนเคยอยู่ในสถานการณ์ที่คล้ายกันและสิ่งที่ทำงานสำหรับพวกเขา

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

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

ตามความเป็นจริงฉัน (ในฐานะนักพัฒนาที่ก้าวหน้าที่สุด) ขอความเห็น / ช่วยเหลือของคนอื่นมากกว่าที่ฉันทำเพราะฉันให้ความสำคัญกับการรับรู้จากสายตาภายนอก

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

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

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

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

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