1 คะแนน โดย GN⁺ 2024-02-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

เส้นทางอันไม่เหมือนใครของสตาร์ทอัพในมุมมองของ CEO

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

เหตุผลที่เราสร้างสิ่งนี้

  • Antithesis เป็นส่วนต่อเนื่องของเรื่องราวที่เริ่มต้นจากบริษัทก่อนหน้าชื่อ FoundationDB
  • เราต้องการสร้างฐานข้อมูลแบบกระจายที่ขยายระบบได้และทนทานต่อความขัดข้อง แต่ปัญหาที่ยากที่สุดคือการทดสอบมันและมั่นใจในความถูกต้อง
  • ปัญหาพื้นฐานของการพัฒนาซอฟต์แวร์คือ นักพัฒนาต้องรับมือกับสถานการณ์ที่คาดไม่ถึง

สิ่งที่เราสร้าง

  • ก่อนจะเขียนฐานข้อมูล เราได้เขียนระบบจำลองเครือข่ายแบบ event-driven ที่เป็น deterministic อย่างสมบูรณ์ขึ้นมาก่อน
  • เมื่อพบบั๊กผ่านระบบนี้ เราสามารถรันซ้ำด้วย random seed เดิมเพื่อไล่ตามบั๊กได้
  • FoundationDB เป็นฐานข้อมูลที่แทบไม่มีบั๊ก และแทบไม่มีบั๊กที่ลูกค้ารายงานเข้ามาเลย

สิ่งที่เราสร้าง

  • เราได้เขียน hypervisor เพื่อทำให้ซอฟต์แวร์ใด ๆ ก็ตามกลายเป็น deterministic ได้
  • แพลตฟอร์มนี้สามารถค้นหาบั๊กในซอฟต์แวร์และทำให้เกิดซ้ำได้อย่างสมบูรณ์แบบ
  • ปัจจุบันเรามุ่งเน้นที่การทดสอบ reliability และ fault tolerance ของ distributed systems

ติดต่อ?

  • เราอยากพูดคุยกับองค์กรที่ให้ความสำคัญกับ reliability ของ distributed systems และ productivity ด้านวิศวกรรม
  • หากมีคำถามหรือความคิดเห็น สามารถติดต่อได้ทาง TwitterX หรือ contact@antithesis.com

ความเห็นของ GN⁺

  • ประเด็นสำคัญที่สุดของบทความนี้คือ แนวทางการทดสอบแบบ deterministic ทำให้สามารถสร้างซอฟต์แวร์ที่เกือบสมบูรณ์แบบได้ ซึ่งช่วยเพิ่ม productivity ของทีมวิศวกรรมได้อย่างมากและลดเวลาที่ใช้ในการพบบั๊ก
  • แพลตฟอร์มที่ Antithesis นำเสนอมีศักยภาพในการเปลี่ยนกระบวนทัศน์ของการพัฒนาซอฟต์แวร์ และอาจส่งผลกระทบอย่างมากต่อชุมชนวิศวกรรม
  • บทความนี้นำเสนอแนวทางเชิงนวัตกรรมเพื่อก้าวข้ามข้อจำกัดของการทดสอบซอฟต์แวร์ ซึ่งเป็นข้อมูลที่น่าสนใจและมีประโยชน์อย่างยิ่งสำหรับผู้ที่ทำงานในแวดวงเทคโนโลยี

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

 
GN⁺ 2024-02-14
ความคิดเห็นใน Hacker News
  • ผลิตภาพของทีมวิศวกรรมเพิ่มขึ้น 50 เท่า

    • รู้สึกว่าแนวคิดเรื่อง "นักพัฒนา 10x" ถูกบิดความหมายจนกลายเป็นคนที่ทำงานสัปดาห์ละ 6.5 วัน วันละ 15 ชั่วโมง
    • ผลิตภาพ 10 เท่า (หรือ 50 เท่า) ที่แท้จริงมาจากคนที่ทำให้สิ่งซึ่งเคยคิดว่าเป็นไปไม่ได้เกิดขึ้นได้ และส่งมอบซอฟต์แวร์ได้เร็วขึ้นมาก
  • นี่คือบทเกริ่นนำที่ดีที่สุดที่ฉันเคยอ่าน

    • อธิบายพื้นฐานเกี่ยวกับผู้คนและสิ่งที่พวกเขาสร้างได้ดี
    • อธิบายว่าสิ่งที่กำลังสร้างอยู่ตอนนี้เป็นผลลัพธ์จากสิ่งที่เคยสร้างมาก่อน
    • ยังกล่าวถึงทีมที่ใช้งานไปแล้วด้วย (ซึ่งมีชื่อเสียงและมีระบบซับซ้อน)
    • ถ่ายทอดออกมาเป็นงานเขียนที่ดีและดึงดูดนักพัฒนา/ผู้ก่อตั้ง หน้าแลนดิ้งเพจก็ยอดเยี่ยม
  • นี่เป็นข้อเสนอที่ยอดเยี่ยม แต่คำว่า "พบทุกบั๊กแล้ว" จะจริงได้ก็ต่อเมื่อนิยามของบั๊กแคบมากเท่านั้น

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

    • ในความเป็นจริงมันดูเหมือนบริการคลาวด์ที่รัน integration test
    • ต้องหาวิธีดีพลอยไปยังสภาพแวดล้อมเฉพาะ และต้องเขียน integration test โดยใช้ไลบรารีเฉพาะ
    • สงสัยว่ามันจะช่วยค้นหาบั๊กที่สามารถหาได้อยู่แล้วด้วยสภาพแวดล้อมและ integration test ของตัวเองอย่างไร
  • ข้อสงสัยเกี่ยวกับชื่อ

    • สงสัยว่ามันเป็นแค่การดัดแปลงคำว่า 'Hypothesis' หรือมีความหมายเชิงชาญฉลาดว่าเป็นด้านตรงข้ามของการทดสอบแบบ property-based
  • ความสนใจในสาขานี้

    • ได้รู้ว่า FoundationDB ทำอะไรผ่านคู่มือการจำลอง sled
    • ใช้ madsim เพื่อเขียนบริการสไตล์ async/await และในการทดสอบก็แทนที่องค์ประกอบที่ไม่เป็นเชิงกำหนดทั้งหมดด้วย executor แบบกำหนดได้
    • การทดสอบแบบนี้เป็นเครื่องมือที่ทรงพลังมาก
  • การเขียนนั้นสนุกจริง ๆ

    • เป็นประสบการณ์การเขียนโปรแกรมที่เหมือนถูกล้อมด้วยโล่พลังที่ป้องกันทุกความผิดพลาด
    • ลบ dependency ทั้งหมดออก แล้วเขียน implementation ของ Paxos เองได้อย่างรวดเร็วมาก ไม่มีบั๊กเลย
  • นี่มันเหมือนจอกศักดิ์สิทธิ์เลยไม่ใช่หรือ?

    • ใช้แอปพลิเคชันเดิมได้ตามปกติและตรวจสอบเฉพาะ property
    • CPU และระบบปฏิบัติการที่ไม่เป็นเชิงกำหนดเป็นอุปสรรคมาโดยตลอด
    • การสร้างสแตกการประมวลผลแนวดิ่งทั้งหมดขึ้นใหม่แทบเป็นไปไม่ได้ จึงหลบปัญหานี้ด้วยการสร้าง deterministic simulator ความละเอียดสูง
  • เจอ Antithesis ที่งาน Strangeloop

    • เมื่อเทียบกับสถานะล่าสุดของการทำ automated fault injection ที่เคยใช้ตอนทำงานที่ Amazon แล้ว ผลิตภัณฑ์นี้ล้ำหน้าไปมาก
    • ติดตามกระบวนการตามรอยบั๊กที่พบใน Apache Spark สตรีมมิง
    • นึกภาพไม่ออกเลยว่าเครื่องมืออย่าง Antithesis จะสำคัญแค่ไหนในบริษัทที่สร้างระบบกระจายศูนย์
  • มีอยู่สามความคิด

    • เป็นไอเดียที่ยอดเยี่ยมและมาในเวลาที่เหมาะสม
    • มุ่งเป้าไปที่ตลาดเฉพาะกลุ่ม
    • ขอชื่นชมงานเขียนและเอกสารประกอบคุณภาพสูง