เหตุผลที่ Greg Foster ผู้พัฒนา Graphite สนใจเรื่องนี้
- เขาเริ่มโปรเจ็กต์ Graphite จากแรงบันดาลใจที่ได้จากเครื่องมือภายในของ Facebook
- หลังจากเพื่อนร่วมงานที่เคยอยู่ Facebook แนะนำเกี่ยวกับ Mercurial และเวิร์กโฟลว์ "stacked diffs" เขาจึงตัดสินใจนำแนวคิดนี้มาใช้สำหรับนักพัฒนาบน GitHub และสุดท้ายก็สร้าง CLI ที่นำไอเดียจาก Hg มาผสานเข้ากับ Git
- แล้วทำไม Facebook จึงเลือกใช้ Mercurial แทน Git และสร้างเวิร์กโฟลว์แบบคัสตอมบนมัน?
- Google ก็ไม่ได้ใช้ Git เช่นกัน แต่กรณีนั้นเป็นเพราะงานวิศวกรรมของ Google นำหน้า Git ไปมากกว่า 5 ปี
- ตรงกันข้าม Facebook ก่อตั้งในปี 2004 ซึ่งเป็นช่วงเวลาใกล้เคียงกับที่ Git ถูกสร้างขึ้น และเมื่อ Facebook เริ่มพิจารณาเครื่องมือควบคุมซอร์สโค้ดอย่างจริงจัง Git ก็ได้รับความนิยมมากกว่า Mercurial แล้ว
- ถ้าอย่างนั้นทำไม Facebook ถึงไม่ใช้ Git?
- เขาเชื่อว่าถ้า Facebook เลือกรับ Git มาใช้และมีส่วนร่วมกับมันในช่วงต้นทศวรรษ 2010 โลกวิศวกรรมซอฟต์แวร์อาจแตกต่างออกไป
- Git อาจใช้งานง่ายขึ้น และรองรับ Stacked Changes ได้แบบเนทีฟ
- บริษัทอย่าง Uber และ Pinterest ที่ก่อตั้งโดยพนักงานยุคแรกของ Facebook ก็คงใช้ Git และ GitHub เป็นระบบควบคุมซอร์สแทน Mercurial ทำให้อีโคซิสเต็มในช่วง 10 ปีที่ผ่านมาแตกกระจายน้อยลง
- แต่ Facebook ไม่ได้ยึด Git ไว้สำหรับโมโนรีโปหลักของตน แต่หันไปรับ Mercurial มาใช้สำหรับการจัดการเวอร์ชัน และค่อย ๆ เพิ่มเครื่องมือแบบคัสตอมทับลงไป
- เขาพบบทความ Scaling Mercurial at Facebook ที่โพสต์โดย Facebook
- แม้จะเป็นบทความเมื่อ 10 ปีก่อน และต่อมาเขาได้คำตอบผ่านวิดีโอ YouTube หลายชิ้นว่า "เป็นเพราะประสิทธิภาพ"
- แต่เขาอยากเจาะลึกกว่านั้น และอยากรู้มุมคิดของผู้มีอำนาจตัดสินใจในเวลานั้น จึงไปถามวิศวกรสองคนที่เคยมีส่วนร่วมในโปรเจ็กต์ย้ายไปใช้ Mercurial
- เนื้อหานี้คือการสรุปจากบทสนทนาแบบไม่เป็นทางการกับพวกเขา
เหตุผลที่ Facebook เลิกใช้ Git และย้ายไป Mercurial
- Facebook เคยใช้ Git ในช่วงแรก แต่เมื่อขนาดโค้ดเบสใหญ่ขึ้นราวปี 2012 ก็เริ่มเจอปัญหาด้านประสิทธิภาพ
- กระบวนการ "stat-ing" ของไฟล์ใน Git กลายเป็นคอขวด ทำให้คำสั่งพื้นฐานของ Git ใช้เวลารันเกิน 45 นาที
- ผู้ดูแล Git ไม่ค่อยให้ความร่วมมือกับปัญหารีโปขนาดใหญ่ของ Facebook และแนะนำให้แยกรีโปออกแทน
ทางเลือกที่ถูกพิจารณา
- ในปี 2012 ทางเลือกแทน Git มีไม่มากนัก โดย Facebook เคยพิจารณาโซลูชันปิดซอร์สอย่าง Perforce แต่มีปัญหาทางเทคนิค
- Mercurial มีประสิทธิภาพใกล้เคียงกับ Git แต่มีสถาปัตยกรรมที่สะอาดกว่าและขยายต่อได้ง่ายกว่า
- ทีมของ Facebook เข้าร่วม hackathon ของ Mercurial และประทับใจกับความสามารถในการขยายระบบรวมถึงความเปิดกว้างของชุมชน
การย้ายทั้งองค์กรวิศวกรรม
- เพื่อโน้มน้าวส่วนที่เหลือของบริษัท ทีม Facebook ใช้เวลาทำ mapping ระหว่างคำสั่งและเวิร์กโฟลว์ของ Git กับ Mercurial พร้อมเปิดรับฟังความกังวลของนักพัฒนา
- กระบวนการย้ายเป็นไปอย่างรอบคอบ และท้ายที่สุด Facebook ก็เปลี่ยนไปใช้ Mercurial
- Facebook ยังมีส่วนช่วยปรับปรุงประสิทธิภาพของ Mercurial และทำให้การรีวิวโค้ดแบบขนานเป็นไปได้ผ่าน "stacked diffs"
ข้อคิดส่งท้าย
- เรื่องนี้ย้ำเตือนว่า "การตัดสินใจทางเทคนิคครั้งสำคัญจำนวนมากไม่ได้ถูกขับเคลื่อนด้วยเทคโนโลยี แต่ถูกขับเคลื่อนด้วยผู้คน"
- Facebook เลือก Mercurial ไม่ใช่เพราะมันมีประสิทธิภาพดีกว่า Git แต่เพราะการร่วมมือกับผู้ดูแล Mercurial เปิดกว้างมากกว่า
- ในกระบวนการโน้มน้าวทั้งองค์กรวิศวกรรม สิ่งสำคัญไม่ใช่ว่าเทคโนโลยีหนึ่งเหนือกว่าอีกเทคโนโลยีหนึ่ง แต่คือ "การสื่อสารอย่างรอบคอบ"
- และยังตอกย้ำว่า "การสื่อสารและความมีน้ำใจ" เป็นคุณค่าที่สำคัญในโลกของเครื่องมือสำหรับนักพัฒนา
2 ความคิดเห็น
ทำให้นึกถึงคำที่คนรู้จักเคยพูดไว้ว่า "ถ้าจะโน้มน้าวลูกค้า ต้องเป็นเหมือนไม้เกาหลังให้ได้"
ไม่จำเป็นต้องคมเกินไป ไม่จำเป็นต้องเร็วเกินไป ไม่จำเป็นต้องสบายเกินไป และไม่จำเป็นต้องแพงเกินไป ขอแค่เกาในจุดที่เขาอยากให้เกาได้พอดี นั่นแหละคือบริการที่ลูกค้าต้องการ 555
ผมคิดว่าเพราะ Git ถูกสร้างขึ้นโดย Linus Torvalds เพื่อจัดการซอร์สโค้ดของ Linux จึงน่าจะมีบางส่วนที่ประนีประนอมกันไม่ได้อยู่พอสมควร
ใจความของข้อสรุปช่วงท้ายฟังดูราวกับว่า Git เป็นสิ่งที่ไม่ดี เพราะไม่รับฟังความต้องการของ Facebook เอง และไม่ได้ให้ความสำคัญกับการสื่อสารกับความเป็นมิตร แต่ผมคิดว่าโดยสรุปแล้วก็แค่แนวทางและความชอบของทั้งสองฝ่ายต่างกันในหลายด้านเท่านั้น
ถ้ามองกลับกัน Facebook ก็ยังมีทางเลือกที่จะยอมรับและนำแนวทางการแยก repository ที่ Git แนะนำไปปฏิบัติได้เช่นกัน เพียงแต่มันเป็นความเป็นมิตรในแบบที่พวกเขาไม่ต้องการเท่านั้นเอง