35 puan yazan xguru 2024-03-12 | 2 yorum | WhatsApp'ta paylaş

Graphite geliştiricisi Greg Foster neden bununla ilgilendi?

  • Graphite projesini Facebook’un dahili araçlarından ilham alarak başlattı
  • Facebook çıkışlı çalışma arkadaşları Mercurial ve "stacked diffs" iş akışını anlattıktan sonra, bunu GitHub geliştiricileri için hayata geçirmeye karar verdi ve sonuçta Hg’nin fikirlerini Git’e entegre eden bir CLI oluşturdu
  • Peki Facebook neden Git yerine Mercurial’i benimseyip onun üzerine özel bir iş akışı kurdu?
  • Google da Git kullanmıyor, ancak bunun nedeni Google’ın mühendisliğinin Git’ten 5 yıldan fazla ileride olması
  • Buna karşılık Facebook, Git’in ortaya çıktığı dönemle benzer bir zamanda, 2004’te kuruldu ve Facebook’un kaynak kontrol araçlarını ciddi biçimde değerlendirdiği sırada Git, Mercurial’den daha popülerdi
  • O halde Facebook neden Git kullanmıyor?
  • Ona göre Facebook Git’i benimseyip 2010’ların başında katkıda bulunsaydı, mühendislik dünyası farklı olabilirdi
    • Git daha kullanıcı dostu olabilir ve yerel olarak Stacked Changes desteği kazanmış olabilirdi
    • İlk Facebook çalışanlarının kurduğu Uber ve Pinterest gibi şirketler de kaynak kontrol için Mercurial yerine Git ve GitHub kullanır, böylece son 10 yılda daha az parçalanmış bir ekosistem oluşabilirdi
  • Ancak Facebook, (ana monorepo’su için) Git’te kalmadı. Bunun yerine sürüm kontrolü için Mercurial’i benimsedi ve onun üzerine aşamalı olarak özelleştirilmiş araçlar ekledi
    • Facebook’ta yayımlanan Scaling Mercurial at Facebook yazısını keşfetti
    • Bu 10 yıl önce yazılmış bir yazıydı ve sonrasında birkaç YouTube videosu üzerinden "cevap performanstı" sonucuna ulaştı
    • Ancak daha derine inip o dönemde karar veren kişilerin düşüncelerini duymak istedi ve Mercurial geçiş projesine katılmış iki mühendise sordu
    • Onlarla yaptığı gayriresmî konuşmalar üzerinden bu içeriği derledi

Facebook’un Git’i bırakıp Mercurial’e geçmesinin nedeni

  • Facebook başlangıçta Git kullanıyordu, ancak 2012 civarında kod tabanının ölçeği büyüyünce performans sorunları yaşamaya başladı
  • Git’in dosya "stat-ing" süreci darboğaz yarattı ve temel Git komutlarının çalışması 45 dakikadan uzun sürmeye başladı
  • Git bakımcıları, Facebook’un devasa depo sorunları konusunda iş birliğine açık değildi ve bunun yerine deponun bölünmesini önerdi

Değerlendirilen alternatifler

  • 2012’de Git’e alternatif çok fazla değildi; Facebook, Perforce gibi kapalı kaynak çözümleri değerlendirdi ama teknik sorunlar vardı
  • Mercurial, Git’e benzer performansa sahipti ancak daha temiz bir mimari ve daha iyi genişletilebilirlik sunuyordu
  • Facebook ekibi bir Mercurial hackathon’una katıldı ve Mercurial’in genişletilebilirliği ile topluluğun açıklığından etkilendi

Tüm mühendislik organizasyonunun geçişi

  • Facebook ekibi, şirketin geri kalanını ikna etmek için Git ve Mercurial arasındaki komutları ve iş akışlarını eşledi, ayrıca geliştiricilerin kaygılarını dinlemek için zaman ayırdı
  • Geçiş süreci dikkatli şekilde yürütüldü ve sonunda Facebook Mercurial’e geçti
  • Facebook, Mercurial’in performansını iyileştirmeye katkıda bulundu; ayrıca "stacked diffs" ile kod incelemelerinin paralelleştirilmesini mümkün kıldı

Son düşünceler

  • Bu hikâye, "pek çok büyük teknik kararın teknoloji tarafından değil insanlar tarafından yönlendirildiğini" hatırlatıyor
  • Facebook, Mercurial’i Git’ten daha hızlı olduğu için değil, Mercurial bakımcılarıyla iş birliği daha açık olduğu için seçti
  • Tüm mühendislik organizasyonunu ikna etme sürecinde, bir teknolojinin diğerinden daha üstün olmasından çok "düşünceli iletişim" önemliydi
  • "İletişim ve nezaket"in geliştirici araçları dünyasında önemli değerler olduğunu vurguluyor

2 yorum

 
kmc0722 2024-03-13

Bir tanıdığın söylediği "Müşteriyi ikna etmek için sırt kaşıma çubuğu olmalısın" sözü aklıma geliyor.

Ne fazla keskin, ne fazla hızlı, ne fazla konforlu, ne de fazla pahalı olması gerekiyor; tam istenen yeri kaşıyabiliyorsa, müşterinin istediği hizmet de odur haha

 
cosine20 2024-03-13

Git, Linus Torvalds tarafından Linux kaynak kodunu yönetmek için geliştirildiği için, muhtemelen belli ölçüde taviz verilemeyecek noktaları vardı diye düşünüyorum.
Son bölümdeki ana fikir, sanki Git Facebook’un kendi taleplerine kulak asmadığı, iletişim ve kullanıcı dostuluğuna önem vermediği için kötüymüş gibi geliyor; ama bence mesele, çeşitli açılardan yalnızca eğilimlerinin birbirinden farklı olmasıydı.
Tersinden bakarsak, Facebook’un Git’in önerdiği depo bölme yaklaşımını kabul edip uygulama seçeneği de vardı. Sadece onların istemediği türden bir kullanıcı dostuluğuydu.