วิธีรับสมาชิกในทีมใหม่ให้ทันสมัยกับโครงการได้อย่างไร [ปิด]


12

เรากำลังจะจ้างวิศวกรใหม่ 1-2 คนสำหรับทีมซอฟต์แวร์ (ประกอบด้วยนักพัฒนา 3 คน, 1 ผู้ทดสอบ)

ขั้นตอนในการรวมเข้ากับทีมคืออะไร?

ความคิดของฉันคือ:

  • อ่านเอกสาร (มาตรฐานการเข้ารหัส, เอกสารในวิธีการพัฒนาที่เราใช้)
  • ให้พวกเขาอ่านรหัสที่มีอยู่
  • มอบหมายงานง่ายๆให้พวกเขา
  • ในตอนท้ายทำให้พวกเขารับผิดชอบส่วนของรหัส

เราจะทำอะไรได้อีก


โครงการอยู่ในภาคการแพทย์ (ระบบอัลตร้าซาวด์) และจะไปแล้ว 5 ปี เรามีการเผยแพร่เป็นประจำทุกปีและเรากำลังจะเสร็จสิ้นการปล่อยหนึ่งครั้งเมื่อเราต้องการเพิ่มวิศวกร 1-2 คน

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


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

3
@ BenDeMott: ใส่ได้เป็นอย่างดี ฉันไม่เห็นด้วยเพิ่มเติม ถ้าคุณให้คำตอบฉันจะโหวตมันสองสามครั้ง (ถ้า SE จะให้ฉัน)
Marjan Venema

1
2 โหวตเพื่อปิด สิ่งนี้ไม่สร้างสรรค์
JeffO

1
@BenDeMott: คุณต้องให้คำตอบว่า :)
c_maker

2
ฉันต้องการเพิ่มว่านี่เป็นโอกาสที่ดีในการวัดหนี้ทางเทคนิคในโครงการของคุณ ยิ่งใช้เวลานานเท่าไหร่ก็ยิ่งมีหนี้สินมากขึ้นเท่านั้นยิ่งคุณมีหนี้ทางเทคนิคมากขึ้นเท่านั้นในโครงการของคุณ
anon

คำตอบ:


9

มาจากคนที่ต้องเร่งความเร็วในการเขียนโค้ดต่าง ๆ มากมายในอาชีพของฉันนี่คือสิ่งที่ฉันอยากจะแนะนำ:

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

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

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


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

5

ความรู้สึกของฉันคือความอดทนของคนส่วนใหญ่ในการอ่านเอกสารค่อนข้างต่ำ (ดีสำหรับหนึ่งหรือสองวัน

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

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

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


5

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


4

ฉันทำงานในอุตสาหกรรมมา 10 เดือนเท่านั้น (ในตำแหน่ง) แต่ฉันพบสิ่งต่อไปนี้ช่วยฉัน:

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

ทั้งสองอย่างนี้ช่วยฉันได้บ้าง โชคดี.


3

ฉันจะไปจากระดับสูงถึงต่ำ

สาธิตแอปโดยเร็วที่สุด

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

อธิบายสถาปัตยกรรมระดับสูง

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

เตรียมเอกสารออนบอร์ดไว้อย่างดีเยี่ยม

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

กระตุ้นให้เขา / เธอถามคำถาม (และพร้อมตอบคำถาม)

ด้วยคำตอบแนะนำพวกเขา แต่อย่าบอกพวกเขาว่าต้องทำอะไร ให้คำแนะนำแก่พวกเขา แต่ให้พวกเขาคิดออกเองในที่สุด

ช่วยสมาชิกในทีมคนอื่น ๆ ต้อนรับผู้มาใหม่

มีเหรียญสองด้านเมื่อมีคนเข้าร่วมทีม ทีมจำเป็นต้องมีเครื่องมือเพื่อต้อนรับนักพัฒนาใหม่เช่นกัน

ปล่อยให้พวกเขาหยิบชิ้นเล็ก ๆ สองชิ้น

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

กระตุ้นให้พวกเขาทำงานหนักขึ้นเมื่อพวกเขารู้สึกสะดวกสบายมากขึ้น

ผู้สมัครที่ดีจะทำสิ่งนี้ตามธรรมชาติ


1

หนึ่ง "การปฐมนิเทศ" การไหลที่ฉันได้ผ่าน (และพบว่ามีประโยชน์) เป็นสิ่งที่ตามแนวของ:

  1. การนำเสนอสั้น ๆ ที่ให้ "ภาพใหญ่" ว่าองค์ประกอบคืออะไรรูปร่างที่พอดีและสถาปัตยกรรมทั่วไป
  2. ภาพรวมของรหัสแนะนำฟังก์ชั่นที่จัดการตรรกะหลักสำหรับองค์ประกอบที่กำหนดให้ฉัน ครอบคลุมบางสิ่งที่เกี่ยวข้องกับข้อกำหนดและรูปแบบการเข้ารหัส
  3. พวงของปัญหาเปิดและข้อบกพร่องที่มีลำดับความสำคัญต่ำได้รับมอบหมาย (ซึ่งส่วนใหญ่จะแปลเป็นภาษาท้องถิ่นให้กับองค์ประกอบที่กำหนดให้ฉันและค่อนข้างง่าย)
  4. ฉันคาดว่าจะดีบักผ่านแอปพลิเคชันและขอความช่วยเหลือเกี่ยวกับสิ่งที่ฉันไม่สามารถถอดรหัสได้
  5. หลังจากแก้ไขแล้วฉันก็เดินผ่านขั้นตอน (การตรวจสอบโค้ดการทดสอบระดับ dev และอื่น ๆ ) ของการปล่อยการรวมเข้าด้วยกัน
  6. ทำซ้ำสำหรับงาน / ข้อบกพร่องที่เหลืออยู่ที่จัดสรร

ฉันรู้สึกว่าวิธีนี้ (และความหลากหลายของมัน) จะมีประโยชน์เพราะ:

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

1

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


1

นี่คือวิธีที่ฉันจะไปเกี่ยวกับ

  1. ให้งานที่เกี่ยวข้องกับโครงการแก่พวกเขา (เช่น: หากโครงการของคุณคือแอปพลิเคชันฐานข้อมูลขอให้พวกเขาสร้างแอปพลิเคชันเพื่อเชื่อมต่อกับฐานข้อมูลและดำเนินการอย่างง่าย)
  2. เมื่อคุณพบว่าพวกเขาเข้าใจแนวคิดในการทำงานแล้วให้พวกเขาสาธิตตัวอย่างของโครงการ
  3. ขอให้พวกเขาอ่านเอกสาร
  4. ทำให้คุ้นเคยกับรูปแบบการเข้ารหัสและมาตรฐาน
  5. ภายหลังให้แบบฝึกหัดการดีบัก (เพื่อให้ทราบถึงการไหลของโครงการ)
  6. ขอให้พวกเขาแก้ไขจุดที่คุณได้แก้ไขไปแล้ว (เพื่อค้นหาตรรกะของพวกเขาด้วย)
  7. ในที่สุดก็ทำให้พวกเขาเป็นส่วนหนึ่งของโครงการ

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


1

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

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


1

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

นอกจากนี้คุณสามารถลองรวมเข้ากับทีมอื่นที่มีอยู่แล้วในทีมโดยทดลองใช้งานสไตล์ศูนย์ประเมินบางอย่างเช่นสร้างสะพานใน 45 นาทีจากกระดาษ 4 แผ่นที่รองรับถ้วยกาแฟ เราใช้เทคนิคนี้ในหลักสูตรภาคปฏิบัติในสาขาวิศวกรรมซอฟต์แวร์เพื่อให้นักเรียน 8 กลุ่มทำลายน้ำแข็งก่อนที่พวกเขาจะทำงานในโครงการเดียวเป็นเวลา 3 สัปดาห์ มันช่วยเร่งความเร็วของทีมในการจัดตั้งเฟส


1

1) ให้คำอธิบายกฎและแนวทางเกี่ยวกับรหัสของคุณแก่พวกเขา ให้คำอธิบายทั่วไปเกี่ยวกับวิธีการทำงานของแอปพลิเคชันของคุณและโครงสร้างรหัสทั่วไป

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

3) เริ่มให้โครงการที่ใหญ่ขึ้นและใหญ่ขึ้นอย่างช้า ๆ ในขณะที่ตรวจสอบน้อยลงเรื่อย ๆ

4) นั่งถัดจากพวกเขาเป็นครั้งคราว คุณสามารถเรียนรู้ได้มากมายโดยดูจากวิธีที่คนอื่นมีปัญหา สิ่งเล็ก ๆ เช่น "โอ้คุณสามารถมองหาฟังก์ชั่นในรหัสของคุณได้โดยกดปุ่ม ctrl-" มีประโยชน์มาก

ตอนนี้ฉันได้พบว่ามีสองขั้ว :

  • คนที่ถามคำถามทุกห้านาที "เส้นทางนี้เข้าร่วมทำอะไรได้บ้าง" Google ควรให้คำตอบก่อนและมาหาคุณก็ต่อเมื่อพวกเขาไม่สามารถหาคำตอบได้

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


1

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

a) ผู้พัฒนาใหม่ทั้งหมดจะได้รับการแนะนำเกี่ยวกับข้อกำหนดของโครงการและกระบวนการพัฒนาเป็นเวลา 2 วัน

b) มอบหมายงาน 3 สัปดาห์ในการเขียนการทดสอบ Junit สำหรับรหัสที่มีความครอบคลุมไม่เพียงพอ

c) เมื่อ 3 เสร็จแล้วมอบหมายงานเล็ก ๆ

d) มอบหมายงานที่ซับซ้อนและทำ


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

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

1

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

คุณควรกำหนดนักพัฒนาอาวุโสโดยเฉพาะอย่างยิ่งต่อนักพัฒนาใหม่ที่สามารถช่วยให้คำปรึกษาแก่ผู้สมัคร

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


0

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

พวกเขาจะไม่เข้าใจจนกว่าจะมีงานต้องทำดังนั้นฉันขอแนะนำให้แบ่งออกเป็นสองส่วนส่วนหนึ่งก่อนที่พวกเขาจะเริ่มทำงานจริงและส่วนที่สองหลังจากพวกเขาเริ่มทำงาน พวกเขาจะดูในรหัสหรือเอกสารและคิดว่า " WTF !? " เมื่อสิ่งนี้เกิดขึ้นใครบางคนจะมากับพวกเขาและอธิบายรายละเอียดเล็กน้อย

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