Found on Internet

คัดลอก code/คำแนะนำจากเน็ตมาใช้ production ทันทีโดยไม่พิจารณา

ปัญหาคืออะไร

Found on Internet คือการนำคำแนะนำหรือ code sample จากอินเทอร์เน็ต — Stack Overflow, blog post, README ของ repo แปลกหน้า, หรือแม้แต่คำตอบจาก AI chatbot — มา วางลงใน code production ทันทีโดยไม่พิจารณาผลกระทบ ไม่ตรวจสอบว่ามันเหมาะกับบริบทของระบบตัวเองหรือไม่ ไม่เข้าใจว่าทำไม code นั้นถึงทำงาน และไม่ทดสอบก่อนว่าใช้ได้จริงในสภาพแวดล้อมของตัวเอง

จริงอยู่ที่อินเทอร์เน็ตเป็นแหล่งความรู้มหาศาลและเป็นเครื่องมือเร่งความเร็วในการพัฒนาที่ทรงพลัง แต่การเผยแพร่บนอินเทอร์เน็ตไม่ใช่เรื่องยาก และคำตอบส่วนใหญ่ก็ไม่ผ่านกระบวนการ peer review แบบเดียวกับงานวิชาการหรือ code review ภายในทีม คำตอบที่ได้ vote สูงบน Stack Overflow อาจเขียนขึ้นเมื่อหลายปีก่อน ใช้ library version เก่า หรือแก้ปัญหาคนละบริบทกับที่เรากำลังเจอ ก่อนเชื่อถือควรพิจารณาแหล่งที่มา และลองใช้ใน non-production ก่อน (ดู Read the Manual และ Cunningham’s Law)

แนวคิดนี้ใกล้เคียงกับสิ่งที่ชุมชนเรียกว่า Cargo Cult Programming — การคัดลอก code หรือโครงสร้างโปรแกรมมาใช้โดยไม่เข้าใจว่าทำไมมันถึงทำงาน เพียงเพราะ “ทำแบบนี้แล้วมันเคยได้ผล” คำนี้มาจากคำว่า cargo cult ในมานุษยวิทยา ซึ่งชุมชนบนเกาะแปซิฟิกหลังสงครามโลกครั้งที่ 2 สร้างรันเวย์จำลองและวิทยุไม้เพื่อ “เรียก” เครื่องบินขนส่งสินค้าให้กลับมา โดยเลียนแบบรูปแบบภายนอกโดยไม่เข้าใจกลไกที่แท้จริงเบื้องหลัง — เหมือนโปรแกรมเมอร์ที่ copy code มาโดยไม่รู้ว่ามันทำอะไรจริง ๆ

ทำไมถึงดูน่าใช้

เร็ว — เสิร์ชแล้ว copy-paste ใช้เวลาไม่กี่วินาที เทียบกับการอ่านเอกสาร ทำความเข้าใจปัญหา แล้วเขียนเอง
ดูน่าเชื่อถือ — คำตอบมี upvote เยอะ, comment ยืนยันว่า “ใช้ได้”, หรือมาจาก repo ที่มี star สูง ทำให้รู้สึกว่าปลอดภัยที่จะเชื่อ
แก้ปัญหาเฉพาะหน้าได้จริง — ในหลายกรณี code ที่ copy มาก็ทำงานได้ตามที่ต้องการ อย่างน้อยก็ในตอนที่ทดสอบผิวเผิน
แรงกดดันเรื่องเวลา — ภายใต้ deadline การหาทางลัดที่ “ดูเหมือนใช้ได้” ย่อมน่าดึงดูดกว่าการค่อย ๆ เรียนรู้และออกแบบเอง (ดู Calendar Coder)
ยุค AI ยิ่งเร่งปัญหานี้ — chatbot สร้าง code ที่ syntax ถูกต้อง อ่านลื่น ให้ความมั่นใจสูง แต่ก็สามารถพาผู้ใช้หลงทางไปในทิศทางที่ไม่เหมาะกับบริบทได้เหมือนกัน เพียงแต่เร็วกว่าและดูน่าเชื่อถือกว่าเดิม

ทำไมถึงเป็นปัญหา

ไม่ผ่านการรีวิว — คำตอบบนอินเทอร์เน็ตส่วนใหญ่ไม่มีกระบวนการ peer review ที่เข้มงวด แม้ upvote สูงก็ไม่ได้แปลว่า code ปลอดภัยหรือถูกต้องสำหรับทุกบริบท
ช่องโหว่ความปลอดภัยแพร่กระจายได้จริง — งานวิจัยของ Fraunhofer AISEC พบว่าใน app Android กว่า 1.3 ล้าน app ที่มี code เกี่ยวกับความปลอดภัยจาก Stack Overflow ราว 97.9% มี code ที่ไม่ปลอดภัยอย่างน้อยหนึ่งจุด และงานวิจัยอีกชิ้นพบว่า code snippet ที่มีช่องโหว่เพียง 69 ชิ้นจาก Stack Overflow ได้แพร่กระจายไปยัง GitHub repository กว่า 2,800 repo
บริบทไม่ตรงกัน — code ตัวอย่างมักเขียนขึ้นเพื่อสาธิตแนวคิด ไม่ใช่เพื่อ production ใช้ library คนละ version คนละ framework หรือละเลย edge case, error handling, การจัดการ resource ที่ระบบจริงต้องมี
สร้างหนี้ทางเทคนิคที่มองไม่เห็น — เมื่อไม่เข้าใจว่า code ทำงานอย่างไร การ debug, maintain, หรือขยายในอนาคตจะยากขึ้นมาก เพราะไม่มีใครในทีมอธิบายได้ว่าทำไมมันถึงเป็นแบบนี้
ปัญหาเรื่อง license และการอ้างอิงแหล่งที่มา — code ที่ copy มาอาจมี license ที่ไม่เข้ากันกับ project หรือละเมิดลิขสิทธิ์โดยไม่รู้ตัว
False sense of security — เพราะ code “รันได้” และผ่าน test ผิวเผิน ทีมจึงเข้าใจผิดว่ามันถูกต้อง ทั้งที่ยังไม่ได้ตรวจสอบ correctness หรือ security อย่างจริงจัง

ตัวอย่าง

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

// พบใน "answer" เก่าบนอินเทอร์เน็ต แล้ว copy มาใช้ทันที
// ไม่มีใครในทีมรู้ว่า MD5 ถูกพิสูจน์แล้วว่ามีช่องโหว่ collision
// และไม่เหมาะกับการ hash รหัสผ่านมาตั้งแต่ปี 2005
public class UserAccountService
{
    public string HashPassword(string plainTextPassword)
    {
        using var md5 = System.Security.Cryptography.MD5.Create();
        byte[] bytes = System.Text.Encoding.UTF8.GetBytes(plainTextPassword);
        byte[] hash = md5.ComputeHash(bytes);
        return Convert.ToHexString(hash);
        // ไม่มี salt, ไม่มี work factor, hash เร็วเกินไปสำหรับ brute-force ป้องกัน
    }
}

ปัญหา: code นี้ “ใช้งานได้” ในความหมายที่มัน compile และคืน hash ที่ดูสมเหตุสมผล แต่ไม่มีใครในทีมตรวจสอบว่า MD5 ไม่เหมาะกับการเก็บรหัสผ่าน ไม่มี salt ทำให้เสี่ยงต่อ rainbow table attack และคำนวณเร็วเกินไปจนโดน brute-force ได้ง่าย — เป็นตัวอย่างคลาสสิกของช่องโหว่ที่แพร่จาก Stack Overflow ไปสู่ production จริง

ทางแก้และการ refactor

แนวทางแก้ไม่ใช่การห้ามใช้ทรัพยากรจากอินเทอร์เน็ต แต่คือการใช้อย่างมีวิจารณญาณ:

อ่านเอกสารทางการก่อน — ตรวจสอบว่ามี built-in API หรือ library ที่ผ่านการรับรองอยู่แล้วหรือไม่ (ดู Read the Manual)
เข้าใจก่อนใช้ — อย่า copy code ที่อธิบายไม่ได้ว่าทำงานอย่างไร ถ้าอธิบายให้เพื่อนร่วมทีมฟังไม่ได้ ก็ยังไม่พร้อมจะ merge
ตรวจสอบวันที่และบริบท — คำตอบเก่าอาจอิงกับ version library หรือแนวทางที่ล้าสมัยไปแล้ว
ทดสอบใน non-production ก่อน — ลองใน sandbox, ผ่าน code review, และเขียน automated test ก่อนปล่อยเข้า production
ใช้ library มาตรฐานที่ได้รับการดูแลและตรวจสอบด้านความปลอดภัย แทนการเขียนเองจาก snippet ที่ไม่รู้ที่มา

// ใช้ API มาตรฐานที่ผ่านการตรวจสอบ ออกแบบมาสำหรับ hash รหัสผ่านโดยเฉพาะ
// เข้าใจได้ว่าทำไมถึงปลอดภัย: adaptive work factor + salt อัตโนมัติ
using Microsoft.AspNetCore.Identity;

public class UserAccountService
{
    private readonly PasswordHasher<User> _passwordHasher = new();

    public string HashPassword(User user, string plainTextPassword)
    {
        // PasswordHasher ใช้ PBKDF2 พร้อม salt แบบสุ่มและ iteration count ที่ปรับได้
        // เป็นส่วนหนึ่งของ ASP.NET Core Identity ที่ได้รับการรีวิวและดูแลโดยทีม .NET
        return _passwordHasher.HashPassword(user, plainTextPassword);
    }

    public bool VerifyPassword(User user, string hashedPassword, string providedPassword)
    {
        var result = _passwordHasher.VerifyHashedPassword(user, hashedPassword, providedPassword);
        return result == PasswordVerificationResult.Success;
    }
}

ก่อนนำเข้า production ทีมควรถามคำถามพื้นฐานเสมอ: code นี้มาจากไหน ทำไมมันถึงทำงาน มันเหมาะกับบริบทของเราหรือไม่ และมีทางเลือกที่ผ่านการตรวจสอบมากกว่านี้หรือไม่

flowchart TD
    Search[เจอ code ตัวอย่างบนอินเทอร์เน็ต]
    Understand{เข้าใจว่าทำไมมันทำงานไหม}
    Source{ตรวจสอบแหล่งที่มาและความทันสมัยแล้วหรือยัง}
    Sandbox[ทดลองใน non-production ก่อน]
    Review[ผ่าน code review และ automated test]
    Prod[นำเข้า production]
    Rework[ศึกษาเพิ่มหรือหาทางเลือกอื่น]

    Search --> Understand
    Understand -->|ไม่| Rework
    Understand -->|ใช่| Source
    Source -->|ยัง| Rework
    Source -->|แล้ว| Sandbox
    Sandbox --> Review
    Review --> Prod
    Rework --> Search

Found on Internet

ปัญหาคืออะไร

ทำไมถึงดูน่าใช้

ทำไมถึงเป็นปัญหา

ตัวอย่าง

ทางแก้และการ refactor

ที่เกี่ยวข้อง

แหล่งอ้างอิง

Found on Internet

ปัญหา​คือ​อะไร

ทำไม​ถึง​ดู​น่า​ใช้

ทำไม​ถึง​เป็น​ปัญหา

ตัวอย่าง

ทาง​แก้​และ​การ refactor

ที่​เกี่ยวข้อง

แหล่ง​อ้างอิง

ปัญหาคืออะไร

ทำไมถึงดูน่าใช้

ทำไมถึงเป็นปัญหา

ทางแก้และการ refactor

ที่เกี่ยวข้อง

แหล่งอ้างอิง