- ทั้งทีม Zed จัดการประชุมประจำสัปดาห์ภายในเอดิเตอร์ Zed โดยใช้สภาพแวดล้อมการทำงานร่วมกันที่มีการแชร์หน้าจอและแก้ไขร่วมกันแบบเรียลไทม์
- Zed คือโค้ดเอดิเตอร์ที่ออกแบบมาโดยมีเป้าหมายคือ การตอบสนองแบบไร้ความหน่วง, อินเทอร์เฟซที่ไม่รบกวนสมาธิ, และ การทำงานร่วมกันที่เป็นธรรมชาติเหมือนอยู่ในสำนักงาน
- ด้วย สถาปัตยกรรมบนพื้นฐาน CRDT จึงรับประกันการแก้ไขร่วมกันแบบไร้ความขัดแย้งและมีความหน่วงต่ำ พร้อมทั้ง เริ่มทำงานร่วมกันได้ทันทีด้วยการยืนยันตัวตนผ่าน GitHub เท่านั้น
- แผงการทำงานร่วมกันประกอบด้วยพื้นที่สำหรับการประชุมทั้งบริษัท พื้นที่ตามโปรเจกต์ และพื้นที่โฟกัสส่วนบุคคล จนเกิดเป็น โครงสร้างสำนักงานเสมือน
- ด้วยโครงสร้างนี้ ทีม Zed จึงสามารถประชุม พัฒนา และสื่อสารทั้งหมดภายใน Zed ได้โดยไม่ต้องมีสำนักงานจริง พร้อมมุ่งสู่ สภาพแวดล้อมการพัฒนาแบบมัลติเพลเยอร์แห่งอนาคต
โครงสร้างการทำงานร่วมกันภายใน Zed
- ทีม Zed Industries จัดการประชุมทั้งบริษัททุกวันจันทร์ตอนเที่ยง และทุกขั้นตอนจะถูก แชร์แบบเรียลไทม์ภายในเอดิเตอร์ Zed
- ผู้เข้าร่วมสามารถแก้ไขและบันทึกตารางประจำสัปดาห์ ตัวชี้วัดสำคัญ และฟีดแบ็กจากผู้ใช้ได้พร้อมกัน
- การที่เคอร์เซอร์หลายตัวแก้ไขไฟล์เดียวกันพร้อมกันจะแสดงให้เห็นแบบเรียลไทม์
- เป้าหมายหลักของ Zed ถูกนิยามไว้ 3 อย่างคือ การตอบสนอง, สมาธิ, และ การทำงานร่วมกัน
- การทำงานร่วมกันไม่ใช่แค่ฟีเจอร์ธรรมดา แต่ถูกออกแบบให้เป็น DNA หลักของผลิตภัณฑ์
รากฐานทางเทคนิคของฟีเจอร์การทำงานร่วมกัน
- Zed ใช้โครงสร้าง CRDT (Conflict-free Replicated Data Type) เพื่อให้การแก้ไขทั้งหมดถูกรวมเข้าด้วยกันโดยไม่มีความขัดแย้ง
- ไม่ว่าจะมีความหน่วงของเครือข่ายหรืออยู่คนละที่ ก็จะมาบรรจบที่สถานะเดียวกัน
- แม้มีหลายคนแก้ไขพร้อมกัน ก็ยังคงประสิทธิภาพไว้ได้โดยไม่ลดลง
- สามารถทำงานร่วมกันได้เพียงล็อกอินด้วยบัญชี GitHub โดยไม่ต้องติดตั้งส่วนขยายเพิ่มเติมหรือแชร์ลิงก์
- มีฟีเจอร์โทรด้วยเสียงและแชร์หน้าจอในตัว จึงสื่อสารกันได้โดยไม่ต้องพึ่งเครื่องมือภายนอก
- ระบบการทำงานร่วมกันนี้คือ โครงสร้างพื้นฐานสำคัญที่ทีม Zed สร้างขึ้นเพื่อใช้โดยตรงในกระบวนการพัฒนาของตัวเอง
แผงการทำงานร่วมกันและโครงสร้างช่อง
- แผงการทำงานร่วมกันประกอบด้วย พื้นที่เสมือนแบบอิง ‘Channel’
- ช่องต่าง ๆ ถูกจัดเป็นโครงสร้างลำดับชั้น และสามารถสร้างช่องแม่-ลูกได้
- แต่ละช่องมีฟีเจอร์ อวาตาร์ผู้เข้าร่วม, โน้ต, การควบคุมเสียง, และ การแชร์หน้าจอ
- ช่องสามารถตั้งค่าเป็นสาธารณะ (🛜) หรือจำกัดสิทธิ์ (#️⃣) ได้ และมีระบบสิทธิ์ Guest / Member / Admin
- ผู้ใช้สามารถคลิกอวาตาร์ของสมาชิกทีมคนอื่นเพื่อสลับไปยัง การติดตามเคอร์เซอร์หรือการดูหน้าจอ ได้
สำนักงานเสมือนที่ Zed สร้างขึ้น
- ‘สำนักงาน’ ของทีม Zed ก็คือแผงการทำงานร่วมกันนั้นเอง ซึ่งประกอบด้วยพื้นที่สำหรับการพูดคุยทั้งบริษัท การทำงานร่วมกันตามโปรเจกต์ และพื้นที่โฟกัสส่วนบุคคล
- พื้นที่ประชุมทั้งบริษัท
- ในช่อง
this week จะใช้สำหรับทบทวนแผนประจำสัปดาห์และตัวชี้วัด
- ในช่อง
retrospectives จะมีการรีโทรสเปกทีฟทุก ๆ 6 สัปดาห์ และโหวตเลือกสิ่งที่ทำได้ดีรวมถึงสิ่งที่ควรปรับปรุง
- ในช่อง
demos ทุกวันศุกร์สมาชิกทีมจะสาธิตฟีเจอร์หรือผลการแก้บั๊กแบบเรียลไทม์
- พื้นที่ตามโปรเจกต์
- แต่ละโปรเจกต์ (
git 1.0, edit predictions v2, delta db, cloud เป็นต้น) มีช่องเฉพาะของตัวเอง
- ในโน้ตของช่องจะสรุปสมาชิกทีม เป้าหมาย ลิงก์ GitHub ที่เกี่ยวข้อง และความคืบหน้าไว้
- ช่องย่อยถูกใช้เป็นพื้นที่ประชุมสำหรับคอมโพเนนต์ย่อยต่าง ๆ
- บางช่อง เปิดสาธารณะเพื่อให้ผู้ใช้ภายนอกเข้าดูได้
- พื้นที่โฟกัสส่วนบุคคล
- ภายใต้ช่อง
people สมาชิกแต่ละคนจะสร้างช่องย่อยเป็นชื่อของตนเองและใช้เป็นพื้นที่ทำงานส่วนตัว
- สิ่งนี้ทำหน้าที่เป็นสัญญาณว่าอยู่ใน “โหมดโฟกัส” และหากจำเป็นเพื่อนร่วมงานก็สามารถแวะเข้ามาได้อย่างอิสระ
- บทความบล็อกนี้ก็ถูกเขียนร่างขึ้นในช่อง
blog ส่วนตัวของผู้เขียน
ทิศทางและวิสัยทัศน์ในอนาคต
- ฟีเจอร์การทำงานร่วมกันในปัจจุบันคือ รากฐานที่ทำให้ Zed Industries สามารถดำเนินงานอยู่ภายใน Zed ได้
- ในระยะยาว เป้าหมายคือ สภาพแวดล้อมการทำงานร่วมกันอย่างต่อเนื่องที่การสนทนา การแก้ไข และอินไซต์เชื่อมโยงกับโค้ด
- ในอดีตเคยมุ่งเน้นไปที่ฟีเจอร์ตามคำขอของผู้ใช้ (เครื่องมือเอเจนต์, การดีบัก, การรองรับ Windows·Git ฯลฯ) แต่
ตอนนี้กลับมาโฟกัสอีกครั้งที่ การยกระดับความสมบูรณ์ในฐานะเครื่องมือพัฒนาแบบมัลติเพลเยอร์
- ฟีเจอร์การทำงานร่วมกันนี้ปัจจุบันอยู่ใน เวอร์ชันอัลฟา และ เปิดให้ผู้ใช้ทุกคนใช้ฟรี
- มีให้ดาวน์โหลดสำหรับ macOS, Windows, Linux และกำลัง เปิดรับสมัครนักพัฒนา
1 ความคิดเห็น
ความคิดเห็นบน Hacker News
ชอบทิศทางที่ Zed กำลังมุ่งไป แต่หงุดหงิดที่ ความเสถียรของฟีเจอร์การแก้ไขพื้นฐาน ยังไม่พอ
ถ้าไฟล์ถูกแก้จากภายนอก จะไม่สะท้อนในหน้าต่างโปรเจกต์หรือ git diff และในสภาพแวดล้อมแบบคอนเทนเนอร์ ฟีเจอร์ AI ก็พัง
ACP ก็ดูเท่มาก แต่ในการใช้งานจริงกลับไม่สะดวกกว่า CLI ส่วนใหญ่
ตอนนี้เลยกลับไปใช้ NeoVIM อีกครั้ง ถ้า Zed เสถียรกว่านี้ค่อยว่าจะลองใหม่
ประเด็นที่เกี่ยวข้อง: github.com/zed-industries/zed/issues/38109
ณ ปี 2025 ตอนนี้ก็ยังมีวิธีอื่นอีกมากในการจัดชุดเครื่องมือที่ทำซ้ำได้โดยไม่ทำให้ระบบสกปรก
เดโม Agentic editing ก่อนหน้านี้น่าสนใจดี แต่ตอนนี้เครื่องมือ CLI มีประสิทธิภาพกว่ามาก
ปกติฉันทำงานด้วย Claude code - plan mode แล้วค่อยมาแก้ในเอดิเตอร์ การมี AI รวมอยู่หรือไม่จึงไม่ใช่เรื่องใหญ่แล้ว
เวลาเปิดดูไฟล์ล็อกขนาดใหญ่ไม่สะดวกมาก ถ้าเป็นเอดิเตอร์ ฟังก์ชันการแก้ไขควรต้องมาก่อน
แต่ก็ชอบตรงที่แก้ไขผลลัพธ์จากการค้นหาแบบทั้งระบบได้ทันที
การพูดคุยที่เกี่ยวข้อง: github.com/zed-industries/zed/discussions/26344
อยากลองใช้ฟีเจอร์การทำงานร่วมกันมาก แต่ต้อง self-host ได้
ถ้าข้อมูลโปรเจกต์ต้องผ่านเซิร์ฟเวอร์ของ Zed ในสภาพแวดล้อมองค์กรก็คงไม่ผ่านถ้าไม่มี SLA
อ้างอิง: github.com/zed-industries/zed/issues/8260#issuecomment-1965463519
ไม่อยากให้ IDE มี เครื่องมือสื่อสารหรือฟีเจอร์มัลติเพลเยอร์
มันเป็นพื้นที่ที่ใช้เพื่อโฟกัส เลยไม่อยากเอาอะไรที่ดึงสมาธิเข้ามา
รู้สึกว่าคุณภาพของ Zed ดีกว่าเครื่องมือ remote pair programming อื่น ๆ
เกณฑ์ในการเลือก IDE ของฉันคือ ความขยายต่อได้และความยืดหยุ่น มากกว่าความสมบูรณ์แบบ
แทบไม่ได้ทำ pair programming เลย และมีแค่ตอนเจอบั๊กหนัก ๆ เท่านั้นที่ต้องแชร์
สมัคร Zed Pro อยู่ และชอบ ฟีเจอร์เอเจนต์แบบรวมในตัว
แต่สำหรับทีมขนาดเล็ก ทิศทางแบบ “เครื่องมือสำหรับสร้างเครื่องมือ” ที่ทีม Zed กำลังไล่ตามอาจไม่จำเป็นนัก
สิ่งที่ฉันต้องการคือ ประสบการณ์สำรวจ ทำความเข้าใจ และแก้ไขโค้ดที่เบาและเร็ว
มากกว่าการรองรับ Swift หรือ Kotlin ฉันต้องการ UI ที่ดูแผงไดเรกทอรีและแผง outline พร้อมกันได้ มากกว่า
โค้ดเอดิเตอร์บนคลาวด์ที่บริษัทควบคุม ทำให้รู้สึกไม่สบายใจ
โดยเฉพาะถ้ามาในรูปแบบที่รวมเครื่องมือร่วมงานอย่าง Zoom หรือ Slack ยิ่งไม่อยากได้
คนที่ปฏิเสธ IDE เชิงพาณิชย์ทั้งหมดก็คงเป็นเสียงส่วนน้อย
การโทษ Electron สำหรับปัญหาประสิทธิภาพของ Atom ดูเหมือน การปัดความรับผิดชอบ
VSCode ก็สร้างบน Electron แต่เร็วกว่าเยอะ เช่นเดียวกับเบราว์เซอร์ทั้งหลาย
นั่นจึงทำให้เกิดความต่างด้านประสิทธิภาพ
เทคโนโลยีเว็บนั้นยอดเยี่ยม แต่ในแง่ประสิทธิภาพก็มีข้อจำกัดชัดเจน
ฟีเจอร์การทำงานร่วมกันขนาดใหญ่ของ Zed น่าสนใจ แต่แค่จินตนาการถึง การเขียนโค้ดแบบกลุ่มเรียลไทม์ ก็รู้สึกกดดันแล้ว
มันอาจให้ทั้งฟีดแบ็กทันทีและ แรงกระตุ้นด้านประสิทธิภาพ
ตราบใดที่องค์กรไม่ได้บังคับ ก็อาจพัฒนาไปเป็นพาราไดม์ใหม่ได้
มีประสิทธิภาพกว่าการแชร์หน้าจอมาก
จินตนาการถึงสภาพแวดล้อมที่ทุกคนแก้ไขได้แบบเรียลไทม์โดยไม่มี version control
สามารถสร้างวงจรฟีดแบ็กที่รวดเร็วได้ผ่าน Feature Toggle และ การ deploy แบบ hot-swap
บทความที่เกี่ยวข้อง: martinfowler.com/articles/feature-toggles.html
ฟีเจอร์ต่าง ๆ น่าสนใจ แต่ในทางปฏิบัติคงไม่ได้ใช้บ่อยนัก
ทำให้นึกถึงสมัยก่อนที่เคยใช้ PabloDraw ให้หลายคนช่วยกันทำ ANSI art พร้อมกัน
เคยลองฟีเจอร์ร่วมงานของ VSCode เหมือนกัน แต่ด้วยนโยบายบริษัทก็มีข้อจำกัดเรื่อง self-host เยอะ
อยากให้เซิร์ฟเวอร์ collaboration ถูก ทำให้เป็นมาตรฐานแบบ LSP เพื่อให้ใช้ร่วมกับหลาย IDE ได้
หวังว่าจะทำงานร่วมกับผู้ใช้ VSCode ได้ด้วย
ทีม Zed อาจไม่ได้รู้สึกว่าเป็นปัญหาเพราะใช้กันภายใน แต่จำเป็นต้องมี ความเข้ากันได้ข้ามเอดิเตอร์ต่างชนิด
ถ้าใครยังจำ แพ็กเกจ teletype ของ Atom ได้ ก็คงนึกถึงประวัติของการแก้ไขร่วมกันขึ้นมา
จุดเริ่มต้นนั้นย้อนกลับไปถึง Hydra และ SubEthaEdit ในช่วงต้นยุค 2000
รอบนี้ดูเหมือนว่าจุดขายใหม่คือการแชร์ในระดับองค์กร
ลิงก์ที่เกี่ยวข้อง: วิกิของ SubEthaEdit, Apple Design Awards 2003
มันถูกนำเสนอไว้ใน “The Mother of All Demos” ด้วย
ช่วงหลังมานี้ เทคโนโลยี CRDTs โตเต็มที่ขึ้น ทำให้การทำงานร่วมกันแบบเรียลไทม์เสถียรกว่ามาก
อ้างอิง: The Mother of All Demos, บทความ CRDT ของบล็อก Zed
ตอนนี้กลับรู้สึกว่าโอกาสของนวัตกรรมแบบ “ทำได้ไม่ยาก” เริ่มน้อยลงเรื่อย ๆ
ความพยายามของ Zed ก็น่าชื่นชม แต่ทรัพยากรการพัฒนาที่ต้องใช้ในการสร้างเอดิเตอร์ยุคถัดไปนั้นสูงขึ้นมาก
ดีใจที่ทุกวันนี้มันยังคงเป็นแอปฟรีอยู่