[PRIMO Tech-a-Break] รีวิวโค้ดที่ AI เขียน: 5 เรื่องที่ต้องเช็กก่อน Approve PR

สวัสดีครับ PRIMO Tech-a-Break ห่างหายไปนาน ไม่รู้ทำไม ใกล้สิ้นปีทีไร งานเข้าเยอะตลอด

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

ช่วงนี้ผมสังเกตว่า Pull Request ในทีมมีขนาดใหญ่ขึ้น และเข้ามาถี่ขึ้นกว่าเมื่อปีก่อนพอสมควร ฟีเจอร์ที่เมื่อก่อนต้องใช้เวลาเขียนสองสามวัน ตอนนี้ใช้ AI ช่วยแล้วเสร็จได้ในแค่ไม่กี่ชั่วโมง (ถ้า Token ไม่หมดซะก่อน)

ฟังดูเป็นข่าวดีครับ แต่ถ้าถามคนที่ต้องรีวิว เขาอาจไม่ได้รู้สึกแบบนั้น งานเขียนโค้ดเร็วขึ้นก็จริง แต่งานอ่านโค้ดไม่ได้เร็วขึ้นตาม คอขวดของทีมจึงย้ายจากคนเขียนมาอยู่ที่คนรีวิวแทน

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

บทความนี้ผมเลยอยากแชร์ 5 เรื่องที่ผมเช็กทุกครั้งเวลาเจอ PR ที่รู้ว่ามี AI ช่วยเขียน ไม่ได้เป็นกฎของทีมอะไรนะครับ เป็นนิสัยส่วนตัวที่ช่วยให้ผมจับปัญหาได้ก่อนขึ้น production หลายครั้งแล้ว

1. โค้ดนี้แก้ปัญหาที่ถูกต้องหรือเปล่า

ข้อนี้ฟังดูพื้นฐาน แต่ผมว่าสำคัญที่สุดครับ

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

ตัวอย่างที่ผมเจอคือ ticket ให้ "ซ่อนสมาชิกที่ไม่ active ออกจากรายงาน" แต่ PR ที่ได้กลับไปลบข้อมูลสมาชิกเหล่านั้นออกจาก query ทั้งหมด รวมถึงหน้าที่ฝ่ายบริการลูกค้าต้องใช้ค้นหาด้วย โค้ดสะอาดมาก แต่ทำผิดเรื่อง

ทุกวันนี้ผมจึงเปิด ticket อ่านก่อนเปิด diff เสมอ และลองนึกว่าถ้าเป็นผมเขียนเอง ผมจะแก้ไฟล์ไหนบ้าง ถ้า PR แตะไฟล์ที่ผมไม่ได้คาดไว้ ก็ถือเป็นสัญญาณให้ถามคนเปิด PR ก่อน

Trick: อ่าน requirement ก่อนอ่านโค้ด ถ้าเริ่มจากโค้ด เราจะถูกโค้ดพาไปและรับเอาสมมติฐานของมันมาโดยไม่รู้ตัว

2. มีของแบบนี้อยู่ในโปรเจกต์แล้วหรือยัง

AI มองเห็นโปรเจกต์ของเราได้ไม่ครบทุกส่วน สิ่งที่เกิดขึ้นบ่อยคือมันเขียน helper function ใหม่ขึ้นมา ทั้งที่ในโฟลเดอร์ utils มีฟังก์ชันที่ทำหน้าที่เดียวกันอยู่แล้ว บางครั้งชื่อต่างกันแค่นิดเดียว เช่น formatPhoneNumber กับ formatPhone

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

วิธีของผมง่ายมากครับ เวลาเห็นฟังก์ชันใหม่ใน PR ผมจะลอง search คำหลักของมันในโปรเจกต์ก่อน ใช้เวลาไม่ถึงนาที แต่ช่วยลด duplicated logic ได้เยอะ

3. Error ถูกจัดการ หรือถูกซ่อน

ข้อนี้คือจุดที่ผมเจอปัญหาบ่อยที่สุดในโค้ดที่ AI เขียน

AI ชอบเขียน try/catch ครอบไว้แทบทุกที่ ดูผ่านๆ เหมือนรอบคอบดี แต่พอเปิดดูข้างใน หลายครั้ง catch แค่ log แล้ว return ค่าว่างกลับไป เช่นคืน array เปล่าเมื่อเรียก API ไม่สำเร็จ

ผลคือเวลา API ล่มจริง หน้าจอจะแสดงว่า "ไม่พบข้อมูล" แทนที่จะแจ้งว่าระบบมีปัญหา ผู้ใช้เข้าใจผิด ทีม support ก็ไม่รู้ว่าต้องแจ้งใคร และ alert ก็ไม่ดังเพราะไม่มี error หลุดออกมาให้เห็น ปัญหาแบบนี้หาต้นเหตุยากกว่าโค้ดที่ crash ไปเลยหลายเท่า

ผมจึงอ่านทุก catch block ใน PR แล้วถามตัวเองว่า ถ้าบรรทัดนี้ทำงานจริงตอนตีสอง คนที่ on-call จะรู้ไหมว่าเกิดอะไรขึ้น

Trick: ค้นคำว่า catch, default, fallback และ ?? ใน diff แล้วอ่านเฉพาะส่วนนั้นอีกรอบ ค่า default ที่ดูสมเหตุสมผล มักเป็นที่ซ่อนบั๊กที่ดีที่สุด

4. Test ที่เขียนมา ทดสอบอะไรจริงๆ

PR ที่ AI ช่วยเขียนมักมาพร้อม test จำนวนมาก coverage สูง ทุกตัวเป็นสีเขียว ซึ่งดูน่าประทับใจครับ

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

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

ใครอยากเห็นภาพรวมว่า AI กำลังเปลี่ยนวิธีทดสอบซอฟต์แวร์อย่างไร อ่านต่อได้ที่ AI Testing: ตัวเปลี่ยนเกมที่หลายคนมองข้าม

5. Dependency ที่เพิ่มเข้ามามีอยู่จริงและยังดูแลอยู่หรือไม่

ข้อสุดท้ายเกี่ยวกับ security โดยตรง

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

ทุกครั้งที่ไฟล์ package.json หรือ lock file เปลี่ยน ผมจะเปิดดูทุก package ใหม่ว่ามีผู้ดูแลจริง อัปเดตล่าสุดเมื่อไหร่ และจำเป็นต้องเพิ่มเข้ามาหรือไม่ หลายครั้งพบว่างานนั้นใช้ library ที่มีอยู่แล้วในโปรเจกต์ก็ทำได้

สรุป Checklist

ข้อตกลงหนึ่งข้อที่ผมอยากให้ทุกทีมมี

นอกจาก 5 ข้อข้างบน มีอีกเรื่องที่ผมคิดว่าสำคัญกว่าทุก checklist คือ คนที่เปิด PR ต้องอธิบายได้ทุกบรรทัดที่ตัวเองส่งมา

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

อีกเรื่องที่ช่วยได้มากคือการแบ่ง PR ให้เล็กลง AI ทำให้การเขียนโค้ดทีละ 2,000 บรรทัดง่ายมาก แต่ไม่มีใครรีวิว 2,000 บรรทัดได้อย่างตั้งใจ ถ้าแบ่งเป็น PR ละสองสามร้อยบรรทัด คนรีวิวจะมีโอกาสเห็นปัญหามากขึ้น และการ revert ก็ง่ายขึ้นด้วย

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

ถ้าทีมของใครมีวิธีรีวิวโค้ดจาก AI ที่ได้ผล แชร์กันได้นะครับ แล้วพบกันใหม่ครับ

บทความที่เกี่ยวข้องจาก PRIMO Tech-a-Break

• "Vibe Coding" เทรนด์ใหม่ เมื่อ Developer ไม่ได้เขียนโค้ดเอง
• ใช้ AI ในการเขียนโค้ดทุกวัน… คุณรู้หรือไม่ว่าคุณอยู่ในระดับนักพัฒนาซอฟต์แวร์ระดับใด?
• คุณยังเป็น Dev อยู่ไหม ในวันที่ AI Credits หมด

ติดตามคอนเทนต์ใหม่ๆ ได้ทางช่องทางเหล่านี้