วันที่หัวแล่น ต่อให้ปัญหาซ้อนกันหลายชั้น เราก็ยังมองออกว่าต้องแก้ตรงไหน แต่ไม่มีใครหัวแล่นได้ทุกวัน

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

เส้นแบ่งนี้มาจากบทความสองชิ้นบน seangoedecke.com ของ Sean Goedecke ซึ่งเขียนต่อกันเป็นชุด

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

รถ Formula 1 เร็วที่สุดในสนาม แต่ขับฝ่ารถติดไม่ได้

ต้นทางแบ่งคนสองแบบนี้จากอาการตอนเจอปัญหาที่แก้ไม่ได้ในทันที คนแบบแรกจะดิ้นและฝืน รอแสงสว่างวาบที่เคยมาเอง คนแบบหลังมีกระบวนการค่อยๆ แกะปัญหาทีละขั้น

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

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

คนหัวไวมักสะดุดกับปัญหาแรกที่หาทางลัดไม่เจอ

ปัญหานั้นไม่ต้องยาก แค่มองแล้วไม่เห็นทางลัดทันทีก็พอ

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

อาการนี้ไม่ได้แปลว่าไม่เก่ง แค่ยังไม่เคยฝึกทักษะการค่อยๆ แกะปัญหา เพราะที่ผ่านมาไม่ต้องใช้ ทักษะนี้ฝึกได้ด้วยสามขั้นต่อไปนี้

ขั้นแรก หยุดมือให้ได้ก่อน แล้วคิดแบบสโลว์โมชัน

สิ่งที่ตรงข้ามกับการคิดให้ชัดไม่ใช่การคิดผิด แต่คือการลองไปเรื่อยๆ จนบังเอิญเจอคำตอบ ต้นทางจึงแนะนำให้เริ่มจากไม่ทำอะไร หายใจ แล้วค่อยคิดไล่ปัญหาทีละส่วน

คำว่า "คิดแบบสโลว์โมชัน" ไม่ได้มาจากวงการซอฟต์แวร์ แต่มาจากอาจารย์ที่ปรึกษาของผู้เขียนต้นทางสมัยเรียนโทด้านปรัชญา อาจารย์ชอบบอกให้ค่อยๆ ไล่ความคิดเหมือนดูภาพสโลว์โมชัน

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

ลองตั้งเวลาสักสามนาทีแล้วห้ามแตะคีย์บอร์ด เขียนลงกระดาษว่าตอนนี้เห็นอะไรอยู่ตรงหน้าบ้าง เวลาสามนาทีนี้ทำให้เห็นปัญหาทั้งหมด ไม่ใช่เห็นแค่ผลของสิ่งที่เพิ่งลองไป

ขั้นที่สอง ก่อนกดรันทุกครั้ง ทายผลให้เจาะจงที่สุด

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

ต้องทายให้เจาะจง อย่าบอกแค่ว่าจะเห็นข้อความแจ้งข้อผิดพลาด แต่ให้ระบุว่า error ตัวไหน ข้อความประมาณไหน มาจากไฟล์อะไร

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

ขั้นที่สาม ยืนบน invariants แล้วไล่ล้มของที่ยังเดาอยู่

ต้นทางเรียกข้อที่มั่นใจได้ว่าระบบทำแบบนั้นเกือบตลอดว่า invariants ถ้าคิดเป็นตัวเลข ข้อนี้จะจริงราว 99.99% ของเวลา

เวลาติดกับปัญหาชวนงง มักเป็นเพราะสมมติฐานบางข้อไม่จริง งานแรกไม่ใช่เดาว่าอะไรพัง แต่ต้องแยกสิ่งที่รู้แน่ออกมาก่อน แล้วค่อยตรวจข้อสันนิษฐานอื่นทีละข้อ ส่วน 403 กับ 401 ในตารางคือรหัสที่ระบบตอบกลับเมื่อคำขอไม่ผ่านเรื่องสิทธิ์

ช่องขวาคือประโยชน์ของวิธีนี้ เพราะช่วยตัดสิ่งที่ไม่ต้องค้นหาออกไปได้มากก่อนเปิดโค้ดสักไฟล์

มือใหม่เห็นข้อมูลเป็นพันชิ้นและคิดออกเป็นพันทาง ส่วนคนที่เชี่ยวชาญเห็นข้อมูลชิ้นที่ใช่เพียงชิ้นเดียว และคิดออกทางเดียวที่ถูก

ความเชี่ยวชาญในงานซอฟต์แวร์จึงเท่ากับความแม่นเรื่อง invariants งานสายนี้มีข้อเท็จจริงที่ใช้ตรวจสอบได้มากกว่าสายงานอื่นแทบทุกสาย เพราะระบบส่วนใหญ่ทำงานเหมือนเดิมเมื่อเงื่อนไขเหมือนเดิม

แต่สิ่งที่เรานับว่ารู้แน่ก็อาจผิดได้ บางระบบมีเงื่อนไขแปลกๆ จนจังหวะที่ระบบตอบกลับสำคัญพอๆ กับข้อมูลที่ส่งไป โปรแกรมที่ปิดแล้วอาจยังมีช่องเชื่อมต่อ (socket) ที่เก็บข้อมูลค้างไว้ ต้นทางบอกว่าการไล่บั๊กที่โหดที่สุดมักเริ่มตรงนี้

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

สั่ง AI แก้บั๊กรัวๆ คือการลองมั่วรุ่นที่เร็วขึ้น

บทความสองชิ้นนี้พูดถึงการไล่บั๊กทั่วไป ไม่พูดถึง AI เลย แต่อาการที่อธิบายไว้ย้ายมาเกิดกับคนที่สั่ง AI เขียนโค้ดได้แบบตรงๆ

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

การที่ AI แก้โค้ดเกินกว่าที่สั่งไม่ใช่เรื่องบังเอิญ งานวิจัยวัดแล้วว่าโมเดล AI ส่วนใหญ่ทำแบบนั้น อย่างที่เล่าไว้ใน บั๊กบรรทัดเดียวแต่ AI ส่งโค้ดแก้มา 300 บรรทัด

ก่อนพิมพ์คำสั่งรอบต่อไป ลองหยุดแล้วเขียนสามบรรทัดนี้

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

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

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

---

ที่มา:

• บทความ You don't have to be smart if you can think clearly จาก seangoedecke.com
• บทความ Thinking clearly about software จาก seangoedecke.com