วิธีที่ดีที่สุดในการมีส่วนร่วมกับผู้พัฒนารุ่นเยาว์ในการออกแบบแอปพลิเคชันจากศูนย์? [ปิด]


9

เราเป็นทีมงานของนักพัฒนา 3 คน (2 devs ประสบการณ์และจูเนียร์)

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

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

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

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

เรากำลังคิดวิธีการบางอย่าง:

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

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


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

คำตอบ:


12

ฉันแนะนำแนวทางดังต่อไปนี้:

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

2
ให้แน่ใจว่าพวกเขาอยู่ในการออกแบบอย่างแน่นอน จากนั้นเขาจะเข้าใจว่าการมีส่วนร่วมของเขาเหมาะสมกับภาพรวมและมูลค่าเพิ่มอะไร เขาอาจจมน้ำตายในความซับซ้อน แต่อย่างน้อยเขาก็จะได้รู้ว่าเขาอยู่ในมหาสมุทรใด!
Michael Green

1

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

  • ฟังก์ชั่นนี้ให้จำนวน N บุคลากรจากตารางบุคลากร
  • ฟังก์ชั่นนี้ให้สถิติบุคลากรที่ได้รับ ID ของบุคลากร

->

ภารกิจ: สร้างเพจที่มีรายการบุคลากรที่แสดงสถิติของเขา / เธอเมื่อมีการคลิกบันทึกบุคลากร นี่คือหน้าตัวอย่างง่ายๆที่สร้างขึ้นก่อนหน้าในโครงการ

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


0

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

ปัญหาการเขียนโปรแกรมคู่จะไม่เกิดขึ้นหากคุณดำเนินการตามกระบวนการด้วยการพิมพ์ / กำลังคิดเปลี่ยนทุก 10 นาที (หรือมากกว่านั้น) โดยไม่มีข้อยกเว้นการทำตามขั้นตอนที่อธิบายไว้โดย Kent Beck (แต่ฉันจำไม่ได้ว่าอยู่ที่ไหน)

สำหรับการเกี่ยวข้องกับคนอื่น ๆ ในการออกแบบ - สิ่งที่เราได้พบว่าช่วยได้ในระหว่างขั้นตอนการออกแบบเอกสารการออกแบบบางอย่าง (กับ UML บางรุ่น) จะถูกสร้างขึ้น ผู้อื่น (ผู้อยู่ใต้บังคับบัญชาของคุณ) สามารถพิสูจน์อ่านตรวจทานเล่นผู้สนับสนุนของปีศาจได้ บทบาทของบุคคลที่สามที่ไม่ถูกทำลายอิสระนี้จะเป็นประโยชน์อย่างมากเช่นการทดสอบเชิงสำรวจ - http://www.softwaretestinghelp.com/exploratory-testing-beyond-traditional-testing-boundaries

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