แก้เครื่องมือก่อน

 (ochagavia.nl)
1 คะแนน โดย GN⁺ 2026-02-23 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ระหว่างไล่ตาม บั๊กในไลบรารีโอเพนซอร์ส เกิดปัญหาที่ ดีบักเกอร์ไม่ทำงาน
  • แม้โค้ดจะถูกรันแล้ว แต่กลับเกิดอาการที่ breakpoint ถูกมองข้าม จึงพยายามหาปัญหาด้วยวิธีอื่น
  • มีการลองวินิจฉัยแบบอ้อม ๆ เช่น เพิ่ม log output แต่ก็ไม่ได้ข้อมูลเชิงลึกตามที่ต้องการ
  • สุดท้ายเมื่อ แก้ข้อผิดพลาดในการตั้งค่าดีบักเกอร์ ก็สามารถสังเกตการทำงานของโปรแกรมได้อย่างละเอียด และใช้ข้อมูลนั้นแก้บั๊กได้สำเร็จ
  • จากประสบการณ์ที่มัวแต่จดจ่อกับการแก้ปัญหาจน มองข้ามข้อบกพร่องของเครื่องมือเอง ผู้เขียนจึงเน้นว่านักพัฒนาควรแก้เครื่องมือก่อน เพื่อให้แก้ปัญหาได้อย่างมีประสิทธิภาพ

ปัญหาที่เกิดขึ้นระหว่างวินิจฉัยบั๊ก

  • ระหว่างค้นหา บั๊กในไลบรารีโอเพนซอร์ส ที่ดูแลอยู่ พบว่าดีบักเกอร์มีอาการข้าม breakpoint
    • แน่ชัดว่าโค้ดรันถึงบรรทัดนั้นแล้ว แต่ โปรแกรมกลับทำงานจนจบโดยไม่หยุด
    • เพราะมัวโฟกัสกับการแก้ปัญหา จึงมองข้ามปัญหาของดีบักเกอร์และลองใช้วิธีอื่นแทน
  • มีการลองแก้โค้ดและ วินิจฉัยด้วยการเพิ่ม log แต่ก็ไม่ได้ข้อมูลที่มีประโยชน์

การแก้ดีบักเกอร์และการแก้ปัญหา

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

สิ่งที่ตระหนักและบทเรียน

  • ตระหนักถึงความย้อนแย้งที่ความมุ่งมั่นจะแก้บั๊กกลับทำให้ มองข้ามปัญหาของเครื่องมือ
  • ได้สัมผัสด้วยตัวเองว่า หากเครื่องมือทำงานไม่ถูกต้อง ประสิทธิภาพในการแก้ปัญหาจะลดลง
  • สิ่งที่นักพัฒนาต้องมีคือ นิสัยตรวจสอบและแก้เครื่องมือก่อนตัวปัญหา
  • ปิดท้ายด้วยประโยค “Fix your tools” เพื่อย้ำเตือนโปรแกรมเมอร์ทุกคนถึงความสำคัญของเครื่องมือ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-02-23
ความคิดเห็นจาก Hacker News

  • ทำงานมานาน 30 ปีแล้ว แต่ช่วงนี้ เครื่องมือพัฒนามันพังเกินไปจริงๆ
    เขียนโค้ดบน Linux ด้วย Clio และบั๊กก็แย่ลงเรื่อยๆ มาหลายปีแล้ว
    ตอนนี้ก็ได้แต่ปล่อยผ่านแบบ “ถ้ามันใช้ไม่ได้ก็ช่างมัน” ชีวิตมันสั้นเกินกว่าจะมีเวลามัวไปแก้โค้ดของคนอื่น

  • พอพยายามจะแก้ปัญหา ก็สุดท้ายมักจะตกไปอยู่ใน ‘yak shaving’
    คือพอจะจัดการปัญหาเล็กๆ งานจุกจิกยิบย่อยก็จะต่อเนื่องกันไม่จบไม่สิ้น
    ดูวิดีโอที่เกี่ยวข้องได้ที่นี่

    • สถานการณ์แบบนี้ไม่มีคำตอบตายตัว
      บางครั้งการจัดระเบียบเครื่องมือกับไลบรารีก็ทำให้ผลิตภาพพุ่งขึ้นมาก แต่อีกบางครั้งแค่ ฮาร์ดโค้ด เดินหน้าต่อกลับเร็วกว่า
      AI ช่วยปรับแต่งเครื่องมือได้ก็จริง แต่ขณะเดียวกันขอบเขตก็ใหญ่ขึ้น สุดท้ายก็ยังใช้เวลาเท่าเดิมไปกับการจัดการเครื่องมือ
      ท้ายที่สุดแล้วมันคือปัญหา การผัดวันประกันพรุ่งเชิงอารมณ์ (procrastination) ไม่อยากคิดเรื่องโครงสร้างภาพรวมเลยเอาแต่แก้จุดเล็กๆ ซ้ำไปมา หรือในทางกลับกันก็ผัดเรื่องการออกแบบทั้งระบบแล้วไปหมกมุ่นกับรายละเอียดของเครื่องมือแทน
    • น่าเสียดายที่คนมักเข้าใจ ‘yak shaving’ ว่าเป็นแค่การเสียเวลาเปล่า
      จริงๆ แล้วมันก็เป็นกระบวนการรับมือกับ แรงเสียดทานและความไม่สะดวกที่จำเป็น ด้วย
      แต่ก็ควรคอยตรวจสอบเสมอว่าความไม่สะดวกนั้นจำเป็นจริงไหม
      การลงทุน 10~15 นาทีเพื่อทำงานซ้ำๆ ให้เป็นอัตโนมัติหรือให้สั้นลง เท่ากับเป็นการซื้อเวลาในอนาคต
    • วิดีโอก็เป็นอย่างที่คาดไว้ แต่ก็ยังตลกอยู่ดี
    • ยังทำให้นึกถึง XKCD 349 ด้วย
    • ที่เรื่องแบบนี้เกิดขึ้นก็เพราะเครื่องมือถูกปล่อยทิ้งไว้จนพังกันหมดแล้ว
      สุดท้ายแล้ว หนี้ทางเทคนิค ยังไงก็ต้องจ่ายคืนสักวัน จึงควรสร้างนิสัยค่อยๆ จ่ายไปทีละนิด

  • งานวิศวกรรมสุดท้ายแล้วก็คือกระบวนการ ลับขวาน อย่างต่อเนื่อง
    ผมชอบแนวคิดของ Kent Beck ที่ว่า “ทำให้การเปลี่ยนแปลงเป็นเรื่องง่ายก่อน แล้วค่อยทำการเปลี่ยนแปลงที่ง่าย”

    • ได้รับมอบหมายให้ปรับปรุงโค้ดที่ไม่เคยเห็นมาก่อน แต่โค้ดมันเละมากจนสุดท้ายตัดสินใจเริ่มจาก รีแฟกเตอร์ ก่อน
      การปรับปรุงโค้ดให้ดีขึ้นให้ความรู้สึกคุ้มค่ามากกว่าการแค่เพิ่มฟีเจอร์เสียอีก
    • แนวทางนี้ยังไม่ค่อยมีใน AI-based coding
      AI ไม่ได้รู้สึกว่าแปลกอะไรแม้จะเขียนโค้ดแบบเดิมซ้ำหลายครั้ง จึงไม่ค่อยมีการจัดโครงสร้างหรือใช้ซ้ำ
    • การลับขวานตั้งแต่แรกนาน 4 ชั่วโมงอาจไม่มีประสิทธิภาพก็ได้
      ในความเป็นจริง การกลับมาลับใหม่ตอนที่มันเริ่มทื่อระหว่างทำงานน่าจะสมเหตุสมผลกว่า
    • ในการเขียนโปรแกรมอาจชอบ ‘ขวาน’ (เครื่องมือมินิมอลอย่าง vim) แต่เวลาโค่นต้นไม้จริงๆ ก็อดคิดไม่ได้ว่า เลื่อยยนต์ ดีกว่ามาก
    • เพื่อนร่วมงานส่วนใหญ่ทำงานกันแบบ ใช้ท่อตัดต้นไม้
      พูดว่า “ตอนนี้ยุ่งอยู่ ไม่มีเวลาลับขวาน!” แล้วก็ทำงานแบบไร้ประสิทธิภาพต่อไป

  • ประโยคที่ว่า “ความอยากจะแก้บั๊กกลับทำให้มองไม่เห็น ความจริงที่ว่าควรแก้เครื่องมือก่อน” น่าประทับใจมาก
    ปรากฏการณ์นี้ก็ถูกพูดถึงในหนังสือ 『Why Greatness Cannot Be Planned』 ของ Kenneth Stanley ด้วย

  • เป็นคำแนะนำที่ยอดเยี่ยม ผมเองก็พยายามทำตามทุกวัน
    แต่คำแนะนำต่อจากนั้นที่ว่า “พอได้แล้ว เลิกแก้เครื่องมือ แล้วไปแก้ปัญหาจริง” กลับทำได้ไม่ค่อยดี

  • ผมก็เจอสถานการณ์แบบนี้บ่อย
    การแก้แรงเสียดทานเล็กๆ ช่วยประหยัดเวลาในภายหลังได้ แต่ก็มี กับดักที่ทำให้มัวแต่แตะเครื่องมือไม่รู้จบ
    สิ่งที่ยากจริงๆ คือการรู้ว่าเมื่อไรควรบอกว่า “เท่านี้ก็พอแล้ว” แล้วเดินหน้าต่อ

  • เครื่องมือคือสิ่งที่ให้ ผลคูณของความพยายาม
    แต่การหาสมดุลระหว่าง ‘yak shaving’ กับงานทำมือที่ไม่จำเป็นนั้นยากมาก
    ถ้าตั้งใจจะใช้เครื่องมือเดิมในระยะยาว แม้การปรับปรุงเพียง 1% ก็มีผลสะสมมาก จนอาจต้องเอนเอียงไปทาง yak shaving มากกว่าที่คิด

  • บทเรียนที่ใหญ่ที่สุดคือ เครื่องมือแบบ all-in-one ส่วนใหญ่มักไม่ค่อยดี
    สำหรับคอนเทนต์ไปป์ไลน์ ผมลองใช้ no-code tools อย่าง Make, Airtable และ n8n มาหมดแล้ว แต่พอเกินขนาดหนึ่งไปทุกอย่างก็พัง
    สุดท้ายการ เรียก API เองด้วย Python script กลับเสถียรกว่ามาก
    ทางแก้จริงๆ ไม่ใช่การซ่อมเครื่องมือที่ซับซ้อน แต่คือการ เปลี่ยนไปใช้เครื่องมือที่เรียบง่ายและโปร่งใส

    • ยังไม่เคยใช้เครื่องมืออย่าง n8n เลย เลยสงสัยว่ามีกรณีที่มันดีกว่า Python ไหม
    • เพราะแบบนี้ผมถึงชอบ Airflow มากจริงๆ

  • การใช้ดีบักเกอร์ดูการไหลของโค้ดโดยตรง มีประโยชน์มาก
    เข้าใจได้ตรงไปตรงมามากกว่าการวิเคราะห์แบบสถิตเสียอีก

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

  • ถ้าชอบบทความแบบนี้ ก็อยากล้อเล่นว่า อย่าติดตั้ง Emacs เด็ดขาด