ทำผลลัพธ์ที่ดีด้วย Claude Code

 (dzombak.com)
45 คะแนน โดย GN⁺ 2025-08-09 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp
  • ในช่วงไม่กี่เดือนที่ผ่านมา ได้ทดลองใช้ LLM programming agents หลายตัว และพบว่า Claude Code เป็นเครื่องมือที่น่าพอใจที่สุด
  • ด้วย Claude Code จึงสามารถสร้างโปรแกรมและโปรเจ็กต์ได้ราว 12 รายการ ภายในเวลาอันสั้น และทำงานที่ปกติคงไม่ได้เริ่มเพราะข้อจำกัดด้านเวลาได้
  • ปัจจัยสำคัญในการใช้งานให้ได้ผลคือ การเขียนสเปกให้ชัดเจน, การจัดเตรียมเอกสารที่มีโครงสร้างโปรเจ็กต์ วิธี build และ lint, การขอให้ AI รีวิวโค้ดของตัวเอง และการใช้ global agent guide แบบปรับให้เข้ากับตนเอง
  • เนื่องจากโค้ดที่ AI เขียนมักอาจ ไม่ถูกต้องหรือไม่มีประสิทธิภาพ จึงต้องตรวจทานโค้ดและ test case ทั้งหมดด้วยตนเองเสมอ และหากการทดสอบยังไม่พอ ก็ต้องเพิ่มเองหรือให้ AI เขียนแล้วตรวจซ้ำอีกครั้ง
  • ภาคผนวกที่เผยแพร่เป็น global agent guide มี แนวทางการพัฒนาอย่างละเอียด เช่น แผนการ implement แบบเป็นขั้นตอน, test-driven development, ปรัชญาที่เน้นความเรียบง่าย ความชัดเจน และการใช้งานได้จริง, มาตรฐานคุณภาพ และกระบวนการแก้ปัญหา

ประสบการณ์และผลลัพธ์จากการใช้ Claude Code

  • ในช่วงหลายเดือนที่ผ่านมา ได้ทดลองใช้ LLM programming agents หลายตัว และโดยเฉพาะอย่างยิ่งพบว่าประสบการณ์การใช้ Claude Code ดีที่สุด
  • แม้จะไม่ได้ไร้ปัญหาเสียทีเดียว แต่ก็สามารถทำโปรแกรมและโปรเจ็กต์ได้มากกว่า 12 รายการในเวลาอันสั้น
  • หากไม่มี Claude Code ก็คงแทบเป็นไปไม่ได้ที่จะทำงานทั้งหมดนี้ให้เสร็จภายในช่วงเวลาเดียวกัน
  • หลายงานเป็นโปรเจ็กต์ที่คงไม่ได้ลองเริ่มด้วยซ้ำ เพราะใช้เวลามากเกินไป

กลยุทธ์การใช้งาน Claude Code

  • เขียนสเปกให้ชัดเจน
    • ก่อนเริ่มโปรเจ็กต์ ให้จัดทำเอกสารความต้องการและบริบทให้ชัดเจนเพื่อส่งต่อให้เอเจนต์
    • วิธีนี้ช่วยกำหนดทิศทางและขอบเขตของการเขียนโค้ดให้ชัดเจน
  • จัดทำเอกสารโครงสร้างโปรเจ็กต์
    • เตรียมเอกสารที่รวมวิธีรัน build, lint และ test
    • ทำให้เอเจนต์สำรวจ codebase และทำงานได้อย่างมีประสิทธิภาพมากขึ้น
  • ขอให้เอเจนต์รีวิวโค้ด
    • ให้ Claude Code รีวิวโค้ดที่สร้างขึ้นเองโดยตรง เพื่อค้นหาจุดปรับปรุงหรือบั๊กที่ไม่คาดคิด
  • ใช้ global guide ส่วนตัว
    • ใช้ ~/.claude/CLAUDE.md ซึ่งบรรจุกฎส่วนตัว เช่น แนวทางการแก้ปัญหา, การใช้ TDD, การรักษาความเรียบง่ายและความชัดเจน, การจำกัดจำนวนครั้งที่ลอง (3 ครั้ง) เพื่อคงกระบวนการพัฒนาให้สม่ำเสมอ

การตรวจสอบโค้ดที่ LLM เขียน

  • โค้ดที่ AI สร้างมักมีปัญหาอย่าง ข้อผิดพลาดเชิงตรรกะ, ประสิทธิภาพลดลง, หรือ การทดสอบไม่สมบูรณ์
  • ผู้เขียนตรวจทานโค้ดทั้งหมดแบบ manual และยืนยันการทำงานด้วยตนเอง
    • เพิ่ม test case ที่ขาดไปด้วยตนเอง
    • หรือให้ AI เขียน แล้วตรวจทานโค้ดและการทดสอบอีกครั้ง
  • ในสภาพแวดล้อมการทำงานแบบมืออาชีพ เมื่อชื่อของตนอยู่ใน PR ก็เน้นย้ำว่า ความรับผิดชอบต่อคุณภาพขั้นสุดท้ายเป็นของตัวเอง

ประเด็นสำคัญของ “global” agent guide ส่วนตัว

คู่มือนี้จัดการผ่านไฟล์ ~/.claude/CLAUDE.md

  • ปรัชญาและหลักการสำคัญ

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

  • นิยามของความเรียบง่าย

    • ฟังก์ชันและคลาสมีหน้าที่เดียว
    • หลีกเลี่ยงการทำ abstraction เร็วเกินไป
    • ลดความซับซ้อน และมุ่งสู่โค้ดที่ไม่ต้องอธิบายเพิ่มเติม

  • กระบวนการทำงาน

    • 1. วางแผนและกำหนดขั้นตอน:
      • งานที่ซับซ้อนให้แบ่งเป็น 3~5 ขั้น แล้วบันทึกไว้ใน IMPLEMENTATION_PLAN.md
      • ระบุเป้าหมายของแต่ละขั้น, เกณฑ์ความสำเร็จ, test case และสถานะความคืบหน้า
    • 2. ลำดับการ implement:
      • ทำความเข้าใจ → เขียน test (red) → implement ขั้นต่ำสุด (green) → refactor → commit
    • 3. ประเมินใหม่หลังลองครบ 3 ครั้ง:
      • เมื่อไม่สำเร็จ ให้บันทึกสิ่งที่ลอง, ข้อผิดพลาด และสาเหตุ
      • สำรวจทางเลือก (2~3 แนวทาง)
      • ทบทวนการออกแบบพื้นฐานหรือการแยกปัญหาใหม่
      • ลองใช้แพตเทิร์นหรือฟีเจอร์อื่น

  • มาตรฐานทางเทคนิค

    • ให้ความสำคัญกับ composition และใช้ dependency injection
    • ใช้ interface เพื่อให้ทดสอบได้ง่าย
    • data flow แบบ explicit
    • แนะนำ TDD และห้ามปิดการทดสอบ

  • กฎคุณภาพโค้ด

    • ทุก commit ต้อง compile สำเร็จ, test ผ่าน, มีการทดสอบสำหรับฟีเจอร์ใหม่ และเป็นไปตาม code style
    • ก่อน commit ให้รัน formatter และ linter, รีวิวการเปลี่ยนแปลงด้วยตนเอง และเขียน commit message ที่อธิบายว่า “ทำไม”

  • การจัดการข้อผิดพลาด

    • fail fast พร้อมข้อความที่เฉพาะเจาะจง
    • ให้ context ที่จำเป็นต่อการ debugging
    • จัดการ exception ในระดับที่เหมาะสม และห้ามกลบข้อยกเว้น

  • เกณฑ์การตัดสินใจ

    • 1. ความง่ายในการทดสอบ
    • 2. ความอ่านง่ายที่ยังเข้าใจได้แม้ผ่านไป 6 เดือน
    • 3. ความสอดคล้องกับแพตเทิร์นของโปรเจ็กต์
    • 4. ความเรียบง่าย
    • 5. ความง่ายต่อการเปลี่ยนแปลง

  • การผสานเข้ากับโปรเจ็กต์

    • วิเคราะห์ฟีเจอร์ที่คล้ายกันอย่างน้อย 3 รายการ
    • ใช้แพตเทิร์นและไลบรารีเดิมซ้ำ
    • ใช้ test utility เดียวกัน
    • หากจะนำเครื่องมือใหม่เข้ามา ต้องมีเหตุผลที่หนักแน่น

  • quality gate

    • test ทั้งหมดต้องผ่าน
    • ปฏิบัติตามกฎของโปรเจ็กต์
    • ไม่มีคำเตือนจาก linter
    • commit message ชัดเจน
    • การ implement สอดคล้องกับแผน
    • TODO ต้องมีหมายเลข issue

  • แนวทางการทดสอบ

    • ทดสอบโดยยึด พฤติกรรม ไม่ใช่การ implement
    • ถ้าเป็นไปได้ให้มี assertion เดียวต่อหนึ่งการทดสอบ
    • ใช้ชื่อที่ชัดเจนเพื่ออธิบาย scenario
    • ใช้ test utility เดิมซ้ำ
    • การทดสอบต้องเป็น deterministic

  • สิ่งที่ห้ามอย่างเด็ดขาด

    • bypass hook ด้วย --no-verify
    • ปิดการทดสอบ
    • commit โค้ดที่ compile ไม่ได้
    • คาดเดาโดยไม่มีการตรวจสอบ

  • สิ่งที่ต้องทำเสมอ

    • commit แบบค่อยเป็นค่อยไป
    • อัปเดตเอกสารอย่างต่อเนื่อง
    • เรียนรู้จาก implementation เดิม
    • หากล้มเหลว 3 ครั้ง ให้ประเมินแนวทางใหม่

โครงการโอเพนซอร์สที่สร้างด้วย Claude Code

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

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น