ยอมรับทั้งหมด แต่ไม่เข้าใจเลยสักอย่าง

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

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

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

Brian Kernighan เคยกล่าวไว้ในปี 1974 ว่าการดีบั๊ก (debugging) นั้นยากกว่าการเขียนโปรแกรมถึงสองเท่า เขาหมายถึงโค้ดที่มนุษย์เป็นคนเขียน เพราะอย่างน้อยมนุษย์ก็ยังเข้าใจงานของตัวเอง

ในปัจจุบัน คำแนะนำอาจผ่านทั้ง linter และแม้แต่ผ่านการทดสอบ (tests) แต่มันก็ยังอาจตั้งอยู่บนสมมติฐานที่ผิดพลาดได้ สิ่งนี้เกิดขึ้นเพราะผู้คนอ่านคำแนะนำในฐานะ "ผลลัพธ์" (output) มากกว่าที่จะมองว่าเป็น "โค้ด" ผลลัพธ์ที่ดูดีจึงได้รับการอนุมัติ

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

สิ่งนี้สร้างปัญหาที่เกิดขึ้นจริง:

  • คุณต้องดีบั๊กโค้ดที่คุณไม่เคยอ่าน เมื่อมีบางอย่างพังในอีกไม่กี่สัปดาห์ต่อมา คุณต้องเริ่มนับหนึ่งใหม่
  • กรณีขอบเขต (edge cases) ล้มเหลว คำแนะนำอาจจัดการเส้นทางปกติ (happy path) ได้ดี มีการเช็ค null มาให้ แต่กลับพลาดตรรกะเฉพาะเจาะจงที่ธุรกิจของคุณต้องการ
  • คุณไม่สามารถปกป้อง pull request ของตัวเองได้ หากผู้ตรวจสอบ (reviewer) ถามว่าทำไมคุณถึงเลือกใช้วิธีนี้ คุณจะไม่มีคำตอบ เพราะคุณไม่ได้เป็นคนตัดสินใจ คุณแค่ไม่ได้ปฏิเสธมัน

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

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

ลองทำสิ่งเหล่านี้แทน:

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

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

Source: https://dev.to/cloudx/accept-all-understand-none-4dob

Optional learning community: https://t.me/GyaanSetuAi