Vì sao Greg Foster, nhà phát triển của Graphite, quan tâm đến điều này
- Anh ấy bắt đầu dự án Graphite sau khi được truyền cảm hứng từ các công cụ nội bộ của Facebook
- Sau khi các đồng nghiệp từng làm ở Facebook giới thiệu về Mercurial và quy trình làm việc "stacked diffs", anh quyết định mang nó đến cho các nhà phát triển GitHub, và cuối cùng đã tạo ra một CLI tích hợp các ý tưởng của Hg vào Git
- Vì sao Facebook lại chọn Mercurial thay vì Git và xây dựng một quy trình làm việc tùy biến trên đó?
- Google cũng không dùng Git, nhưng đó là vì kỹ thuật của Google đã đi trước Git hơn 5 năm
- Trong khi đó, Facebook được thành lập vào năm 2004, gần cùng thời điểm Git ra đời, và vào lúc Facebook bắt đầu nghiêm túc đánh giá các công cụ kiểm soát mã nguồn thì Git còn phổ biến hơn Mercurial
- Vậy tại sao Facebook không dùng Git?
- Theo anh, nếu Facebook áp dụng Git và đóng góp cho nó vào đầu những năm 2010 thì thế giới kỹ thuật có lẽ đã khác
- Git có thể đã thân thiện với người dùng hơn và hỗ trợ Stacked Changes một cách nguyên bản
- Các công ty như Uber và Pinterest do những nhân viên đầu tiên của Facebook tạo ra cũng có thể đã dùng Git và GitHub làm công cụ quản lý mã nguồn thay vì Mercurial, từ đó tạo nên một hệ sinh thái bớt phân mảnh hơn trong 10 năm qua
- Nhưng Facebook đã không gắn bó với Git cho monorepo mặc định của mình. Thay vào đó, họ chọn Mercurial để quản lý phiên bản và dần bổ sung các công cụ tùy chỉnh lên trên nó
- Anh tình cờ thấy bài viết Scaling Mercurial at Facebook trên blog kỹ thuật của Facebook
- Đây là một bài viết từ 10 năm trước, và sau đó qua vài video YouTube anh nhận được câu trả lời kiểu "vì hiệu năng"
- Nhưng anh muốn đào sâu hơn và nghe suy nghĩ của những người ra quyết định vào thời điểm đó, nên đã hỏi hai kỹ sư từng tham gia dự án di chuyển sang Mercurial
- Nội dung này được anh tổng hợp lại từ các cuộc trò chuyện không chính thức với họ
Vì sao Facebook từ bỏ Git và chuyển sang Mercurial
- Ban đầu Facebook dùng Git, nhưng khoảng năm 2012 khi quy mô codebase tăng lên, họ bắt đầu gặp vấn đề hiệu năng
- Quá trình "stat-ing" file của Git trở thành nút thắt cổ chai, khiến thời gian chạy các lệnh Git cơ bản kéo dài hơn 45 phút
- Các maintainer của Git không hợp tác nhiều trong việc xử lý vấn đề kho mã quy mô lớn của Facebook, mà thay vào đó khuyến nghị chia nhỏ repository
Các phương án thay thế đã được cân nhắc
- Vào năm 2012, không có nhiều lựa chọn thay thế Git; Facebook có cân nhắc các giải pháp mã nguồn đóng như Perforce nhưng gặp vấn đề kỹ thuật
- Mercurial có hiệu năng tương tự Git, nhưng sở hữu kiến trúc gọn gàng hơn và khả năng mở rộng tốt hơn
- Nhóm của Facebook đã tham gia một hackathon của Mercurial và rất ấn tượng với khả năng mở rộng cũng như sự cởi mở của cộng đồng Mercurial
Di chuyển toàn bộ tổ chức kỹ thuật
- Để thuyết phục phần còn lại của công ty, nhóm Facebook đã ánh xạ các lệnh và quy trình làm việc giữa Git và Mercurial, đồng thời dành thời gian lắng nghe những lo ngại của các nhà phát triển
- Quá trình chuyển đổi được tiến hành cẩn trọng, và cuối cùng Facebook đã chuyển sang Mercurial
- Facebook đã đóng góp để cải thiện hiệu năng của Mercurial, đồng thời cho phép song song hóa code review thông qua "stacked diffs"
Suy nghĩ kết lại
- Câu chuyện này nhắc lại rằng "nhiều quyết định kỹ thuật lớn không do công nghệ dẫn dắt mà do con người dẫn dắt"
- Facebook chọn Mercurial không phải vì nó vượt trội Git về hiệu năng, mà vì sự hợp tác với các maintainer của Mercurial cởi mở hơn
- Trong quá trình thuyết phục toàn bộ tổ chức kỹ thuật, điều quan trọng không phải là một công nghệ vượt trội hơn công nghệ kia, mà là "giao tiếp có suy nghĩ"
- Nó nhấn mạnh rằng "giao tiếp và sự tử tế" là những giá trị quan trọng trong thế giới công cụ phát triển
2 bình luận
Tôi chợt nhớ đến câu mà một người quen từng nói: "Muốn thuyết phục khách hàng thì phải trở thành cái gãi lưng cho họ"
Không cần quá sắc bén, không cần quá nhanh, không cần quá tiện, cũng không cần quá đắt; chỉ cần gãi đúng chỗ họ muốn là đó chính là dịch vụ mà khách hàng mong muốn thôi haha
Vì Git được Linus Torvalds tạo ra để quản lý mã nguồn Linux, nên tôi nghĩ hẳn đã có những điểm ở mức độ nào đó không thể thỏa hiệp.
Ý chính của phần kết nghe cứ như Git tệ vì đã không lắng nghe các yêu cầu của Facebook và không coi trọng giao tiếp cùng sự thân thiện, nhưng theo tôi thì đơn giản chỉ là hai bên khác nhau về khuynh hướng ở nhiều mặt mà thôi.
Nghĩ theo chiều ngược lại, Facebook vẫn còn lựa chọn chấp nhận và thực hiện cách phân chia repository mà Git khuyến nghị. Chỉ là đó không phải kiểu thân thiện mà họ mong muốn.