การจัดการกับนักพัฒนาอย่างต่อเนื่องโดยไม่สนใจเคสที่เป็นขอบในงานของเขา

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

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

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

กำหนดให้เขาต้องเขียนการทดสอบหน่วยอัตโนมัติสำหรับรหัสของเขา การเขียนการทดสอบหน่วยบังคับให้คนหนึ่งคิดผ่านกล่องขอบ

รายละเอียดบางอย่าง:

1. เพื่อให้แน่ใจว่าเขาจะไม่รู้สึกแยกออกจากกันสิ่งนี้ควรได้รับการจัดตั้งให้กับทีมของคุณทั้งหมด กำหนดให้ทุกคนต้องเขียนการทดสอบหน่วยโดยอัตโนมัติสำหรับรหัสใหม่หรือรหัสที่แก้ไข
2. ต้องการชื่อหน่วยการทดสอบที่จะอธิบายเป็นกรณีที่พวกเขากำลังทดสอบ
3. ครอบคลุมการทดสอบหน่วยอัตโนมัติในการตรวจสอบรหัสในระดับสูง ให้ผู้ตรวจสอบค้นหากรณีทดสอบที่ไม่ได้รับ (เช่นกรณีขอบที่เขาพลาดเป็นประจำ) หลังจากได้รับคำติชมจากทีมของเขาเกี่ยวกับคดีที่ไม่ได้รับจำนวนหนึ่งเขาอาจจะเรียนรู้ที่จะต้องพิจารณาคดีเหล่านั้นก่อนการพิจารณา
4. บังคับใช้กฎนี้สำหรับทีมทั้งหมด: หาก QA พบข้อบกพร่องนักพัฒนาซอฟต์แวร์ที่รับผิดชอบจะต้องทำการทดสอบอัตโนมัติเพื่อยืนยันความล้มเหลวและพิสูจน์ว่าพวกเขาได้ทำการแก้ไขแล้ว (ก่อนที่พวกเขาจะทำงานอื่นใด)

ให้รายการตรวจสอบแก่เขาเช่น

• อินพุตว่าง
• อินพุตที่ช่วงปลายขนาดใหญ่สุดขีด
• อินพุตที่ส่วนท้ายเล็กสุดของช่วง
• อยู่รวมกัน
• อินพุตที่ละเมิดค่าคงที่สมมติว่า (เช่นถ้า x = y)

กลุ่มควบคุมคุณภาพสามารถช่วยจัดทำรายการตรวจสอบ

มอบรายการตรวจสอบให้กับนักพัฒนาทั้งหมดไม่ใช่แค่คนนี้

วิศวกรที่ดี

ถูก

แต่มีปัญหากับเขา - บ่อยครั้งที่เขาล้มเหลวในการแก้ไขปัญหาขอบในรหัสของเขา

มันเป็นวิศวกรที่มีคุณภาพที่ดีไม่แชร์

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

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

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

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

คุณสามารถทำรีวิวรหัสหรือรีวิวออกแบบก่อนหน้านี้ในกระบวนการ?

สอนเขาให้เขียนโปรแกรมทดสอบก่อน จับคู่กับเขา คุณจะเขียนกรณีทดสอบและเขาจะเขียนรหัสเพื่อผ่านการทดสอบ

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

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

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

นอกจากนี้ฉันจะไม่พิจารณาการพิสูจน์คนโง่ทุกฟังก์ชั่นของคลาสส่วนตัวหรือฟังก์ชันภายใน

วิธีที่ฉันเลือกสำหรับรหัสที่จะต้องมั่นคงและมีเสถียรภาพมากคือ:

if(conditions_met)
{
DoStuff();
}
else
{
CrashAppAndDumpMemory();
}

วิธีนี้คุณจะได้รับแอปพลิเคชันที่เป็นของแข็งใน QA และเมื่อคุณได้รับการปล่อยตัวแอปจะมั่นคงและปลอดภัย

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

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

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

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

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

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