Redis array: เรื่องสั้นของกระบวนการพัฒนาที่ยาวนาน

 (antirez.com)
1 คะแนน โดย GN⁺ 2 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • งานพัฒนา ชนิดข้อมูล Array แบบใหม่ ของ Redis เริ่มต้นในช่วงต้นเดือนมกราคม และถูกส่งขึ้นเป็น PR ราว 4 เดือนถัดมา โดยในเดือนแรกมีการเขียนสเปกที่ครอบคลุมทั้งความจำเป็น โครงสร้าง C การแทนค่าแบบ sparse, ring buffer และความหมายของ array cursor สำหรับ ARINSERT
  • การออกแบบช่วงแรกถูกขัดเกลาร่วมกับ Opus และหลังจาก GPT 5.3 เปิดตัว ก็ใช้ Codex สำหรับทั้งงานออกแบบและพัฒนา พร้อมทบทวนจุดประนีประนอมและส่วนที่ออกแบบเกินความจำเป็นอย่างต่อเนื่องผ่านกระบวนการรับฟีดแบ็กกับ AI
  • การติดตั้งใช้งานถูกปรับให้การตั้งค่าอินเด็กซ์ขนาดใหญ่ เช่น ARSET myarray 293842948324 foo ทำงานได้โดยไม่ต้องจัดสรรหน่วยความจำขนาดมหาศาล และโครงสร้างข้อมูลภายในจะสลับไปมาระหว่าง super directory, dense directory แบบแบ่ง slice และรูปแบบ actual array slice ตามเงื่อนไข
  • แต่ละ slice รองรับได้โดยพื้นฐาน 4096 องค์ประกอบ และ ARSCAN กับ ARPOP สามารถสแกน array ที่มีอยู่เดิมได้ด้วยเวลาที่แปรผันตามจำนวนองค์ประกอบที่มีอยู่จริง ไม่ใช่ขนาดรวมของช่วงทั้งหมด
  • กรณีใช้งานที่นำไฟล์ Markdown ใส่ไว้ใน Redis array นำไปสู่การพัฒนา ARGREP โดยเลือกใช้ TRE สำหรับรองรับ regular expression และมีการสรุปกรณีใช้งานไว้ใน Redis PR #15162

การติดตั้งใช้งานและการทบทวน

  • ตั้งแต่เดือนที่สอง เริ่มติดตั้งใช้งานด้วยแนวทาง automatic programming และทบทวนโค้ดที่ถูกสร้างขึ้นอย่างต่อเนื่อง
  • แม้หลังจากที่การติดตั้งใช้งานทำงานได้แล้ว ก็ยังอ่านและทบทวนโค้ดทีละบรรทัด รวมถึง sparsearray.c และ t_array.c
  • แม้ AI จะช่วยให้มีการทดสอบจำนวนมาก แต่โค้ดที่ดูเหมือนทำงานได้บนผิวหน้าไม่ได้แปลว่าเป็นโค้ดที่เหมาะที่สุดเสมอไป จึงมีการค้นหาและแก้ไขทั้งความไม่มีประสิทธิภาพเล็ก ๆ และข้อผิดพลาดเชิงออกแบบ
  • หลายโมดูลถูกเขียนใหม่ทั้งแบบทำเองและแบบมี AI ช่วย และในเดือนที่สามก็มีการทำ stress test ด้วยวิธีที่หลากหลาย
  • ในงาน system programming คุณภาพสูง มนุษย์ยังคงต้องมีส่วนร่วมอย่างเต็มที่ แต่เมื่อมี AI ก็ช่วยเป็นตาข่ายนิรภัยสำหรับงานที่ชวนอ่อนล้า เช่น การเพิ่มการรองรับ 32 บิตและการทดสอบ รวมถึงการตรวจจับบั๊กที่เห็นได้ชัดในอัลกอริทึมที่ซับซ้อน
  • การเขียนสเปกขนาดใหญ่ในช่วงแรกเป็นหัวใจสำคัญของงานหลังจากนั้น และยังสำคัญต่อการทบทวนโค้ดทุกบรรทัดพร้อมแก้ไขส่วนที่ไม่สอดคล้องกัน

กรณีใช้งานและ regular expression

  • ระหว่างการทำโมเดลกรณีใช้งาน ผู้เขียนเริ่มนำไฟล์ Markdown ใส่ไว้ใน Redis array และสรุปได้ว่าไฟล์ลักษณะนี้เข้ากันได้ดีกับชนิดข้อมูล array
  • สิ่งนี้นำไปสู่การพัฒนา ARGREP เพื่อสร้างฐานความรู้ส่วนกลางบนไฟล์ Markdown ที่จำเป็นต่อการทำงานของเอเจนต์
  • สำหรับการรองรับ regular expression ได้เลือกใช้ TRE เพราะเมื่อใช้ regular expression ใน Redis ไม่ควรมีแพตเทิร์นที่ก่อปัญหาเชิงเวลาและพื้นที่อย่างผิดปกติ
  • TRE ไม่มีประสิทธิภาพมากในการจับคู่แพตเทิร์นที่มีประโยชน์อย่าง foo|bar|zap จึงมีการปรับแต่งด้วยความช่วยเหลือจาก GPT พร้อมแก้ไขประเด็นด้านความปลอดภัยที่อาจเกิดขึ้นบางส่วน และขยายการทดสอบเพิ่มเติม
  • กรณีใช้งานถูกสรุปไว้อย่างละเอียดใน Redis PR #15162 และนำไปสู่ข้อสรุปว่า Redis จำเป็นต้องมีชนิดข้อมูลที่อินเด็กซ์ตัวเลขเป็นส่วนหนึ่งของความหมาย
  • ผู้เขียนคาดหวังว่า Array PR จะได้รับการยอมรับในเร็ว ๆ นี้ และหวังว่าจะได้ใช้ประโยชน์จากกรณีใช้งานใหม่ ๆ พร้อมเปิดรับฟีดแบ็ก

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

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

 
GN⁺ 2 시간 전
ความเห็นจาก Hacker News

  • ขอทำให้ชัดเจนก่อนว่านี่คือสิ่งที่ ผู้สร้าง Redis หรืออย่างน้อยก็หนึ่งในนั้นเป็นคนทำ
    เขาไม่ใช่ “นักพัฒนาโดยเฉลี่ย” และถึงจะใช้ LLM ก็ยังใช้เวลา 4 เดือน
    ดังนั้นอย่าเอาเรื่องนี้ไปตีตรารับรองว่าตอนนี้สั่งให้นักพัฒนาทุกคนย้ายไปใช้ Claude Code, Codex หรือเครื่องมือเขียนโค้ด AI อื่น ๆ แบบเต็มตัวได้แล้ว
    โดยเฉพาะเป็นจุดที่ CEO สตาร์ทอัปทั่วไปควรอ่าน

    • ดูจะเป็นหลักฐานที่ค่อนข้างหนักแน่นว่าเมื่อ นักพัฒนามากประสบการณ์ ใช้ coding agent ได้อย่างชำนาญ ความเชี่ยวชาญของพวกเขาจะยิ่งถูกขยายออกไป
    • ส่วนที่บอกว่า “เขาไม่ใช่นักพัฒนาโดยเฉลี่ย และถึงจะใช้ LLM ก็ยังใช้เวลา 4 เดือน” นั้น ถ้าอ่านต้นฉบับจะต่างออกไปเล็กน้อย
      ในต้นฉบับเขาพูดว่า “ต่อให้ไม่มี LLM ก็น่าจะทำ implementation เองเสร็จได้ภายในราว 4 เดือนอยู่ดี สิ่งที่เปลี่ยนไปคือในช่วงเวลาเท่าเดิม ผมทำอะไรได้มากขึ้นมาก”
      กล่าวคือช่วงเริ่มต้นเดิมก็ประมาณ 4 เดือนอยู่แล้ว และ LLM ช่วยให้ทำงานได้มากขึ้นภายในเวลาเท่าเดิม
    • เขาอาจไม่ใช่คนทั่วไป แต่งานของเขาก็ไม่ใช่งานทั่วไปเหมือนกัน
      งานพัฒนาโดยเฉลี่ยมักใกล้เคียงกับ งาน plumbing และ CRUD มากกว่า

  • ตอนนี้วิธีที่ใช้อยู่เป็นแบบนี้
    ก่อนอื่นใช้ AI ช่วยเขียน เอกสารออกแบบระดับสูง เป็น Markdown จากนั้นให้โมเดลเดียวกันแต่ตัดบริบทออก หรือให้โมเดลอื่นมาวิพากษ์ เพื่อหาบั๊ก สิ่งที่ตกหล่น และช่องโหว่ ซึ่งพอกลับมาดูทีหลังมันมักจะหาเรื่องที่ควรเห็นได้ชัดเจอเสมอ
    จากนั้นก็ให้มันสรุปสิ่งที่ค้นพบ แล้วคัดลอกไปให้ AI ตัวแรกพร้อมถามความเห็น สร้างชุดการเปลี่ยนแปลงที่ตกลงกันได้แล้วนำไปใช้ จากนั้นทำ adversarial round-robin แบบนี้ต่อไปจนไม่มีโมเดลไหนเสนออะไรที่มีความหมายได้อีก
    หลังจากนั้นให้ AI ทำแผนงาน และเอาแผนนั้นไปวนแบบ adversarial ระหว่าง AI หลายตัวอีกที สุดท้ายก็ได้แผนที่ค่อนข้างแข็งแรง
    แล้วค่อยไปต่อที่แผน test case แบบ end-to-end เป็นต้น ขึ้นอยู่กับขนาดของระบบ ช่วงประมาณสิ้นวันแรก สิ้นสัปดาห์แรก หรือสิ้นเดือนแรก ก็จะพร้อมเริ่มเขียนโค้ด
    เมื่อมีโค้ดแล้ว ก็นำโค้ดนั้นพร้อมสเปกและแผนไปให้ AI ตัวอื่นตรวจหาบั๊ก สิ่งที่ขาด และช่องโหว่ เป็นการให้ AI หลักที่รับผิดชอบ implementation ถูกตรวจสอบโดย AI ตัวอื่นอย่างต่อเนื่อง
    แน่นอนว่ายังต้องอ่านโค้ดด้วยตัวเอง เพราะเคยเห็น AI พลาด รายละเอียดเก็บงานขั้นสุดท้ายเพื่อคุณภาพระดับส่งมอบจริง

    • ในวาทกรรมเรื่อง AI เราชอบพูดกันราวกับว่าเราได้เปิด กระบวนทัศน์การพัฒนาแบบไร้การกำกับดูแล แบบใหม่ขึ้นมา แต่จริง ๆ แล้วมันแทบจะเหมือนวิธีที่ Google สร้างโค้ดมาตลอด 10 ปี เพียงแต่แทนที่จะใช้มนุษย์ที่มีระดับความน่าเชื่อถือแตกต่างกัน ก็เปลี่ยนมาใช้ AI
      ไม่ได้พูดเชิงเสียดสี งานของผมเองก็มี workflow แบบเดียวกันโดยแก่นแท้ และก็ไม่ได้จะหัวเราะเยาะ Google ด้วย ตรงกันข้าม สิ่งที่อยากบอกคือมันไม่ได้ใหม่อะไรเลย
      AI เร่งทั้ง workflow ที่มีประสิทธิภาพและ workflow ที่ไม่มีประสิทธิภาพอย่างมหาศาล ทำให้เราเห็นได้เร็วขึ้นมากว่าอะไรเวิร์กและอะไรไม่เวิร์ก แทบจะเป็นแบบเรียลไทม์
    • อยากรู้ว่าวิธีนี้ เร็วหรือช้าแค่ไหน เมื่อเทียบกับการลงมือเขียนโค้ดเองโดยตรง
    • การพัฒนาแบบ spec-driven ลักษณะนี้คือจุดต่างหลักของ AWS Kiro: https://kiro.dev/docs/specs/
      เขาบอกว่าใช้ agent อื่นด้วย เลยอยากรู้ว่าเห็นผลกับการ code review ที่ให้ agent อื่นมาช่วย polish ส่วนที่ยังไม่เรียบร้อยหรือไม่ เพื่อนร่วมงานของผมเชื่อเรื่องนี้มาก แต่ส่วนตัวยังสงสัยอยู่ว่าถ้าไม่มี reviewer ที่เป็นมนุษย์แล้วจะคุ้มค่าจริงไหม
      วิธี “ถาม AI ตัวอื่น” แบบนี้ อาจจะอธิบายด้วยแนววิภาษวิธีแบบภาวะตั้งต้น-ภาวะตรงข้าม-ภาวะสังเคราะห์ได้เหมาะกับงาน applied computer science มากกว่าก็ได้: https://en.wikipedia.org/wiki/Dialectic#Criticisms

  • ต่อให้ antirez เป็นคนเขียนเอง การรีวิวโค้ด 22,000 บรรทัด จากชุดฟีเจอร์ระดับนี้พร้อมคำอธิบาย PR ขั้นต่ำก็ดูเหมือนฝันร้ายอยู่ดี
    พอจะเข้าใจแล้วว่าทำไมโอเพนซอร์สใหญ่ ๆ อย่าง Postgres ถึงพัฒนากันผ่าน mailing list เพราะมันเปิดให้คุยการตัดสินใจด้านการออกแบบระหว่างทางกับชุมชน แยกฟีเจอร์ที่เกี่ยวข้องเป็นแพตช์ย่อย รีวิวแบบค่อยเป็นค่อยไป และเว้นช่วงระหว่างการรีลีสได้

    • ตัวโค้ดมีทั้งหมด 5,000 บรรทัด รวมคอมเมนต์
      sparse array 2,000 บรรทัด
      คำสั่ง t_array และ implementation ชั้นบนอีก 2,000 บรรทัด
      โค้ด AOF/RDB ราว 500 บรรทัด
      ที่เหลือคือเทสต์ คำอธิบายคำสั่ง JSON และไลบรารี TRE ใต้ deps
    • Postgres กับ Redis เป็นโปรเจกต์ที่ต่างกันมากทั้งในเชิงลักษณะ ประวัติ วิธีการมีส่วนร่วม และทีมพัฒนา
      อันที่จริงฟีเจอร์หลักของ Redis แทบทั้งหมดเป็นงานที่ผู้เขียนสร้างขึ้นคนเดียว
      แถม reviewer ก็เข้าใจงานนี้ดีและได้รับค่าตอบแทนเหมาะสมด้วย

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

    • ผมมักพูดว่า AI คือ เป็ดยางสำหรับ rubber duck programming ที่ผมอยากได้มาตลอด
    • มีบางโปรเจกต์ที่ผมพัฒนาแทบไม่ต้องดูโค้ดเลย โดยผมถือครองแนวคิด อัลกอริทึม และไอเดีย คอยให้คำถามกับคำใบ้ โดยเฉพาะเป็นเจ้าของทิศทางผลิตภัณฑ์
      แต่ Redis ยังไม่ใช่แบบนั้น ถ้าวันหนึ่งสิ่งนี้เป็นไปได้กับ server software วิธีพัฒนาแบบทุกวันนี้ก็คงจบลง
      ฟีเจอร์ การแก้ไข และการสั่งสมประสบการณ์ยังมีคุณค่าอยู่ ดังนั้นตัวโปรเจกต์และ repository จะยังคงอยู่ แต่บทบาทของโปรแกรมเมอร์จะคล้ายกับบทบาทที่ Linus มีต่อ kernel มาจนถึงตอนนี้มาก
      ในบางโปรเจกต์อย่างเอนจินอนุมาน DeepSeek v4 เราก็เริ่มทำงานกันในลักษณะนั้นแล้ว

  • array/regex น่าสนใจมาก และประสบการณ์ที่ใช้ LLM ขยายขีดความสามารถก็ชวนติดตามมากเช่นกัน มีคนจำนวนมากที่กำลังลองทำอะไรคล้าย ๆ กันเงียบ ๆ ในหลายโปรเจกต์
    แค่คำว่า vibe coding และกระแสตีกลับต่อมัน ยังอธิบายวิธีทำงานแบบนี้ได้ไม่ดีพอ

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

  • สรุปคือ ตอนนี้ Redis ไว้ใจไม่ได้แล้ว
    จะมีใครทำฟอร์กที่ไม่มี LLM ไหม?

  • use case ที่ยกมาบางส่วนทำด้วย ZSET ไม่ได้หรือ? มุมมองด้านประสิทธิภาพผมเข้าใจ แต่เหมือนว่าน่าจะทำ optimization การจัดเก็บของ ZSET สำหรับค่าที่หนาแน่นได้แบบเลือกใช้ คล้ายกับที่ array ใช้ sparse representation แบบเลือกใช้ โดยไม่ต้องเพิ่ม API surface ใหม่
    ส่วนองค์ประกอบ regex ก็น่าสนใจ แต่เหมือนอย่างที่มีคนพูดไว้ตรงนี้ว่า มันเป็นฟังก์ชันที่ตั้งฉากกับโครงสร้างข้อมูล array มากกว่า กล่าวคือใช้กับโครงสร้างอื่นก็ได้ แบบนี้น่าจะเหมาะกับการทำผ่าน Lua scripting มากกว่าไหม? ถ้า performance ของ Lua เป็นปัญหา ก็น่าจะมีวิธีทำให้ OP ถูก abstract ไว้เพื่อเอาไปประกอบบนคำสั่งใด ๆ ที่คืนค่าเป็นช่วงของค่าได้
    ผมเคารพว่า Antirez เป็นผู้เชี่ยวชาญในด้านนี้ แต่ฟีเจอร์ชุดใหม่บางส่วนให้ความรู้สึกเหมือนแนวทางแก้ปัญหาที่มักเห็นในงานพัฒนาแบบขับเคลื่อนด้วย LLM คือสร้างฟีเจอร์ใหม่แทนที่จะปรับปรุงของเดิม และทำให้ฟีเจอร์ซับซ้อนเกินจำเป็น ทั้งที่การจัดองค์ประกอบร่วมกับฟีเจอร์อื่นอาจมีประสิทธิภาพกว่า

    • น่าเสียดายที่ไม่ได้เป็นแบบนั้น sorted set อยู่แทบจะคนละสุดของสเปกตรัมเลย แม้ในเชิงความหมายจะดูสะอาดดี แต่ก็สิ้นเปลืองมากเพราะเป็น การผสมระหว่าง skip list กับ array
      นอกจากนี้ ถ้า representation ภายในไม่ใช่ array ก็จะทำให้ range query และ ring buffer ทำงานได้ไม่มีทางมีประสิทธิภาพและความกะทัดรัดตามที่ต้องการ
      ในทางทฤษฎีเราทำอะไรก็ได้กับอะไรก็จริง แต่เราต้องแยกสิ่งที่แต่ละ API ทำได้ออกจากกัน เพื่อให้ใช้ use case เหล่านั้นไปออกแบบ implementation ภายในที่เหมาะที่สุดได้

  • สงสัยจะถาม antirez ว่าเคยลองทดลองให้มัน สร้างแบบ one-shot ไปยังโค้ดสุดท้ายเลยไหม? อยากรู้ว่า GEPA จะพาไปถึงจุดนั้นได้หรือเปล่า หรืออาจมีอะไรให้เรียนรู้จากวิธีชี้นำและการเขียนพรอมป์เพื่อดึงผลลัพธ์ที่ต้องการออกมา
    หรือไม่ข้อสรุปก็อาจเป็นแค่ว่าผู้ให้บริการโมเดลต้องจัดระเบียบข้อมูลฝึกให้ดีกว่านี้

  • ดูเหมือน Salvatore อยากผลักดันคำว่า Automatic Programming/Coding ให้แพร่หลายมากขึ้น (https://antirez.com/news/159)

    • https://en.wikipedia.org/wiki/Automatic_programming เป็นคำที่ได้รับการยอมรับในวิทยาการคอมพิวเตอร์ หมายถึงกลไกทุกแบบที่สร้างโค้ดอัตโนมัติจากคำอธิบายในระดับนามธรรมที่สูงกว่า
      แน่นอนว่า LLM นั้นพิเศษมากตรงที่ไม่เป็นเชิงกำหนดและมีขอบเขตกว้างจนน่าทึ่ง แต่ก็ไม่ได้แปลว่าคำนี้จะใช้ไม่ได้
    • ผมเองก็ย่อคำที่ใช้อธิบายสิ่งเดียวกันนี้ลงเรื่อย ๆ เพราะเมื่อเวลาผ่านไป เราจะทำงาน “แบบนั้น” บ่อยขึ้นมาก
      แต่บางทีถ้าย่อคำนี้เป็น auto-code อาจช่วยได้

  • การได้เห็นว่านักพัฒนาที่เก่งมาก ๆ ทุกวันนี้ปฏิสัมพันธ์กับ AI อย่างไรเป็นเรื่องน่าสนใจเสมอ
    @antirez: ช่วงท้ายโปรเจกต์ การเพิ่ม ความสามารถด้าน regex ซึ่งภายนอกดูเหมือนเป็นฟีเจอร์อีกก้อนที่แยกออกมา ทำให้รู้สึกแปลกนิดหน่อย ช่วยอธิบายเหตุผลของการตัดสินใจนั้นเพิ่มได้ไหม?

    • พอผมตระหนักว่า array เข้ากับไฟล์ข้อความได้ดีมาก ก็พบว่า use case จำนวนมากที่นึกออก มาติดอยู่ตรงที่ท้ายที่สุดแล้วก็ต้องการ grep กับไฟล์
      เลยเริ่มคิดว่าสิ่งที่เทียบเท่ากับ AROP สำหรับไฟล์คืออะไร และคำตอบก็คือ ARGREP
      หลังจากนั้นผมก็ใส่ทั้งการจับคู่แบบตรงตัวที่เร็วและการจับคู่ด้วย regex เพื่อให้เลือกใช้เครื่องมือที่เหมาะที่สุดตาม use case
      ต่อมาก็พบว่าในกรณีหลายสตริงที่เชื่อมด้วย OR ถ้า optimize regex ดี ๆ มันอาจเร็วกว่าได้ จึงปรับแต่ง TRE เฉพาะทางเพิ่มอีกเล็กน้อย