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

นี่เป็นเพราะปัญหาหลักของการรีวิวโค้ด:
1. ผู้คนไม่รู้ว่าทำไมพวกเขาจึงรีวิวโค้ด
2. คนไม่ทบทวนสิ่งที่ถูกต้อง
3. คำขอดึงไม่สามารถตรวจสอบได้

ในบทความนี้ เราจะมุ่งเน้นไปที่เหตุผลที่เราตรวจสอบโค้ด

เหตุผลบางประการ

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

หากต้องการดูว่าเหตุใดเราจึงตรวจสอบโค้ด คำถามที่ดีที่สุดที่เราถามตัวเองได้คือ: ทำไมเราจึงต้องการให้ผู้อื่นตรวจสอบโค้ดของเรา

นี่คือสาเหตุบางประการ:

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

หากคุณดูรายการอย่างระมัดระวัง คุณอาจสังเกตเห็นว่ามีเพียงสองรายการในรายการที่ต้องการคนมากกว่านี้

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

นักพัฒนาไม่ได้อยู่คนเดียวในเรื่องนี้ นักเขียนก็ทำเช่นเดียวกัน

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

ฟังดูคุ้นเคยไหม?

ให้มันลอง.

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

ทำความเข้าใจว่าทำไม

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

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

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

อะไรต่อไป?

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

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