สิ่งที่ควรมาก่อน: การทดสอบหรือการตรวจสอบโค้ด

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

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

แนะนำวิธีใดและทำไม

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

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

เป็นการดีที่ในโลก Agile ทั้งสอง :)

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

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

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

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

หากคุณฝึกการตรวจสอบโค้ดก่อนที่จะทำการเช็คอินการตรวจสอบโค้ดจะอยู่ระหว่างสองขั้นตอนการทดสอบ: คุณในฐานะนักพัฒนาทดสอบรหัสของคุณก่อนเพื่อนของคุณทำการตรวจสอบโค้ดคุณทำการตรวจสอบในภายหลัง การทดสอบการรวมตัว

ทดสอบก่อน ทดสอบครั้งสุดท้าย ทดสอบทดสอบทดสอบ

การตรวจสอบรหัสเป็นการดีที่จะมี แต่ยาก - อาจเป็นกระบวนการที่เจ็บปวดหากบุคลิกภาพมีส่วนร่วมหรือมีความคิดเห็นต่างกัน

การทดสอบชัดเจนมาก: ใช้งานได้หรือไม่ได้ผล ดังนั้นทดสอบทดสอบทดสอบ! และตรวจสอบรหัสถ้าเป็นไปได้

ในงานสุดท้ายของฉันเรามีการตรวจสอบโค้ดสามประเภทที่เราจะทำในขั้นตอนต่าง ๆ ของวงจรชีวิตผลิตภัณฑ์ ประเภทแรกที่เราเรียกว่า Sanity Review และมันจะเกิดขึ้นก่อนที่นักพัฒนาจะทำการทดสอบหน่วย - ในความเป็นจริง Sanity Reviews ก็ทำเสร็จก่อนที่คุณสมบัติจะเสร็จสมบูรณ์ แนวคิดก็คือสมาชิกในทีมคู่หนึ่งจะนั่งลงและไปดูส่วนของโค้ดแบบสุ่มสองสามอย่างที่อยู่ในกระบวนการพัฒนาเพื่อให้แน่ใจว่าการพัฒนานั้นดำเนินไปได้ด้วยดีและเราไม่ได้จบลงด้วยยักษ์ รายการ TDWTF เมื่อฟีเจอร์พร้อมที่จะรวมเข้าด้วยกันสิ่งนี้ทำขึ้นสำหรับผู้ที่ต้องการคำแนะนำเพิ่มเติม (ผู้พัฒนารุ่นใหม่, ผู้ที่ได้รับการว่าจ้างใหม่และผู้ที่ได้รับมอบหมายให้ทำงานในสิ่งที่พวกเขาคุ้นเคยน้อยกว่าสมาชิกคนอื่น ๆ ) และโดยทั่วไป เก็บไว้ในการประชุมสั้น ๆ ที่แก้ไขปัญหาร้ายแรงเท่านั้น

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

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

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

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

ข้อใดคือไข่หรือไก่
มันขึ้นอยู่กับ.

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

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

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

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

เพียงสองเซ็นต์ของฉัน

Capers-Jones ผู้ศึกษาและวัดประสิทธิภาพและผลลัพธ์ของกระบวนการพัฒนาซอฟต์แวร์มากกว่าคนอื่น ๆ แนะนำลำดับกิจกรรมกำจัดข้อบกพร่องดังต่อไปนี้ :

• การตรวจสอบการออกแบบ
• การตรวจสอบรหัส
• การทดสอบหน่วย
• ทดสอบฟังก์ชั่นใหม่
• การทดสอบการถดถอย
• การทดสอบประสิทธิภาพ
• การทดสอบระบบ
• การทดสอบเบต้าภายนอก

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