จะให้โปรแกรมเมอร์รุ่นเยาว์เขียนแบบทดสอบได้อย่างไร? [ปิด]

เรามีโปรแกรมเมอร์รุ่นน้องที่เขียนข้อสอบไม่เพียงพอ
ฉันต้องจู้จี้เขาทุกสองชั่วโมง "คุณสอบข้อเขียนหรือเปล่า"
เราได้ลองแล้ว:

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

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

คุณรู้ถึงแรงจูงใจเพิ่มเติมหรือไม่?

นี่เป็นหนึ่งในสิ่งที่ยากที่สุดที่จะทำ คนเดินทางของคุณเพื่อได้รับมัน

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

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

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

บางทีอาจจะมีใครบางคนในกลุ่มของคุณให้การนำเสนอUnit Testing 101โดย Kate Rhodes ฉันคิดว่ามันเป็นวิธีที่ดีในการทำให้ผู้คนตื่นเต้นกับการทดสอบหากส่งได้ดี

สิ่งที่คุณสามารถทำได้อีกอย่างคือให้ Jr. Devs ฝึกฝนBowling Game Kataซึ่งจะช่วยให้พวกเขาเรียนรู้ Test Driven Development มันอยู่ใน java แต่สามารถปรับให้เข้ากับภาษาใดก็ได้

ตรวจสอบโค้ดก่อนทำการคอมมิตทุกครั้ง (แม้ว่าจะเป็นเวลา 1 นาที "ฉันเปลี่ยนชื่อตัวแปรนี้แล้ว") และในการตรวจสอบโค้ดให้ตรวจสอบการทดสอบหน่วยใด ๆ

อย่าลงชื่อเข้าใช้คอมมิตจนกว่าจะมีการทดสอบ

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

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

1. "อืมไม่ถูกต้อง ... "
2. ค้นหาปัญหาที่เป็นไปได้
3. เขียนทดสอบแสดงว่ารหัสล้มเหลว
4. แก้ไขปัญหา
5. แสดงว่ารหัสใหม่ผ่าน
6. วนซ้ำหากปัญหาเดิมยังคงอยู่

ฉันพยายามทำสิ่งนี้แม้ในขณะที่ต่อสู้กับสิ่งต่างๆและฉันก็ทำเสร็จในเวลาเดียวกันโดยมีชุดทดสอบบางส่วนเท่านั้นที่มีอยู่แล้ว

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

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

มาเริ่มกันเลยกับผู้สร้าง:

แสดงว่าการออกแบบกลายเป็นเรื่องง่ายขึ้น

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

แสดงว่าป้องกันข้อบกพร่อง

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

ทำให้มันเป็นเรื่องอัตตาที่บอกว่ามี แต่โปรแกรมเมอร์ที่ไม่ดีเท่านั้นที่ทำไม่ได้

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

@ จัสตินสแตนดาร์ด : ในการเริ่มต้นอาชีพใหม่จับคู่ชายหนุ่มกับตัวคุณเองหรือโปรแกรมเมอร์อาวุโสคนอื่น

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

@ Justin Standard : อ่านการนำเสนอการทดสอบหน่วย 101โดย Kate Rhodes

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

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

@ Dominic Cooney : ใช้เวลาและแบ่งปันเทคนิคการทดสอบ

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

@ Dominic Cooney : ตอบคำถามตัวอย่างและหนังสือ

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

@ Adam Hayle : รีวิวสุดเซอร์ไพรส์.

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

@ Rytmis : รายการจะถือว่าเสร็จสิ้นเมื่อมีกรณีทดสอบเท่านั้น

โอ้น่าสนใจ ฉันเห็นว่าฉันต้องทำตอนนี้จริงๆไม่งั้นฉันจะทำอะไรไม่เสร็จ สิ่งนี้สมเหตุสมผล

@ jmorris : กำจัด / เสียสละ

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

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

การให้เหตุผลการเตรียมการสอนการติดตามการสนับสนุน

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

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

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

นี่คือสิ่งที่ฉันจะทำ:

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

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

เขาทำแบบนี้อยู่แล้ว จริงๆ. เขาก็ไม่จดไว้ ไม่เชื่อ? ดูเขาผ่านวงจรการพัฒนามาตรฐาน:

• เขียนโค้ด
• รวบรวมมัน
• วิ่งไปดูว่ามันทำอะไร
• เขียนโค้ดชิ้นต่อไป

ขั้นตอน # 3 คือการทดสอบ เขาทำการทดสอบอยู่แล้วเขาก็ทำการทดสอบด้วยตนเอง ถามคำถามนี้กับเขา: "พรุ่งนี้คุณจะรู้ได้อย่างไรว่าโค้ดจากวันนี้ยังใช้งานได้" เขาจะตอบว่า: "รหัสมันน้อยมาก!"

ถาม: "แล้วสัปดาห์หน้าล่ะ"

เมื่อเขาไม่ได้รับคำตอบให้ถามว่า: "คุณต้องการให้โปรแกรมของคุณบอกคุณอย่างไรเมื่อการเปลี่ยนแปลงทำลายสิ่งที่ทำงานเมื่อวานนี้"

นั่นคือสิ่งที่เกี่ยวกับการทดสอบหน่วยอัตโนมัติ

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

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

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

แน่นอนว่าฉันไม่รู้อะไรเลยจริงๆ แต่ฉันหวังว่าคำพูดนี้จะมีประโยชน์

แก้ไข: [ Justin Standard ]

อย่าทำให้ตัวเองผิดหวังสิ่งที่คุณต้องพูดนั้นค่อนข้างถูกต้อง

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

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

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

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

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

ในฐานะโปรแกรมเมอร์รุ่นน้องฉันคิดว่า Id เปิดเผยว่ามันเป็นอย่างไรเมื่อฉันพบว่าตัวเองตกอยู่ในสถานการณ์คล้ายกับนักพัฒนารุ่นเยาว์ของคุณ

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

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

อย่างมีความสุข 2 ปีที่ผ่านมาฉันหวังว่าเพื่อนร่วมงานของฉันบางคนอาจคิดว่าฉันเป็นโปรแกรมเมอร์ทั่วไป

เก็บแต้มกลับบ้าน

1. มหาวิทยาลัยส่วนใหญ่แย่มากในการเตรียมนักศึกษาสำหรับโลกแห่งความเป็นจริง
2. การเขียนโปรแกรมแบบจับคู่ช่วยฉันได้จริงๆ นั่นไม่ได้หมายความว่ามันจะช่วยทุกคน แต่มันได้ผลสำหรับฉัน

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

ใครจะรู้พวกเขาอาจได้สิ่งที่ดีกว่าเทคนิคที่ทีมของคุณใช้ในปัจจุบัน

หากโปรแกรมเมอร์รุ่นน้องหรือใครก็ตามไม่เห็นคุณค่าในการทดสอบก็ยากที่จะให้พวกเขาทำ ...

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

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

ฉันสองความคิดเห็นของ RodeoClown เกี่ยวกับการตรวจสอบโค้ดทุกครั้งที่คอมมิต เมื่อเขาทำสำเร็จแล้วสักสองสามครั้งเขาจะมีนิสัยชอบทดสอบสิ่งต่างๆ

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

หมายเหตุ: คุณต้องการaddon ที่มีสีแตกต่างของธันเดอร์เบิร์ดจริงๆถ้าคุณวางแผนที่จะทำสิ่งนี้

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

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

หมายเหตุ: เรามีนักพัฒนา 'อาวุโส' 2 คนและรุ่นน้อง 3 คน สิ่งนี้อาจไม่ปรับขนาดหรือคุณอาจต้องปรับกระบวนการเล็กน้อยกับนักพัฒนาเพิ่มเติม

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

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

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

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

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

โชคดี.

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

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

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

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

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

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

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

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

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

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

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

@ jsmorris

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

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

หลังจากเย็นที่ร้านกาแฟเป็นเวลาหนึ่งชั่วโมงฉันก็กลับไปที่สำนักงานคว้าอึของฉันและจากไป หลังจากนั้นไม่กี่วันพวกเขาก็โทรมาถามฉันว่าจะเข้ามาไหมฉันบอกว่าจะสัมภาษณ์ แต่พรุ่งนี้อาจจะ

“ งั้นเลิกกันแล้วเหรอ”

บนที่เก็บซอร์สของคุณ: ใช้ hooks ก่อนแต่ละคอมมิต (เช่น pre-commits hook สำหรับ SVN เป็นต้น)

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

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

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

นักพัฒนาควรมีค่าเฉลี่ยในการตรวจสอบว่ากรณีทดสอบของเขาครอบคลุมโค้ด 100% หรือไม่ ด้วยวิธีนี้หากเขาไม่ยอมรับรหัสที่ผ่านการทดสอบ 100% ถือว่าเป็นความผิดของเขาเองไม่ใช่ความผิด "อ๊ะขอโทษที่ฉันลืม"

ข้อควรจำ: ผู้คนไม่เคยทำในสิ่งที่คุณคาดหวังพวกเขามักจะทำสิ่งที่คุณตรวจสอบ

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

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

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

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

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

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

หมายเหตุด้านข้าง: ในที่สุดคุณจะต้องการให้ทีม QA รายงานไปยังผู้อำนวยการ QA หรืออย่างน้อยก็ไม่ต้องให้ผู้จัดการนักพัฒนาซอฟต์แวร์เนื่องจากการให้ทีม QA รายงานไปยังผู้จัดการที่มีเป้าหมายหลักคือการทำให้ผลิตภัณฑ์เสร็จสิ้นนั้นเป็นความขัดแย้งของ น่าสนใจ.

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

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

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

หากทุกอย่างล้มเหลวให้โปรแกรมเมอร์มีความเท่าเทียมกันของโถสาบาน - ทุกครั้งที่โปรแกรมเมอร์ทำลายงานสร้างพวกเขาจะต้องใส่ $ 20, $ 50, $ 100 (อะไรก็ตามที่ทำให้พนักงานของคุณเจ็บปวดพอสมควร) ลงในโถที่คุณชื่นชอบ ( จดทะเบียน!) จนกว่าพวกเขาจะจ่ายเงินหลีกเลี่ยงพวกเขา :)

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

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

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

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

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

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

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

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