127 commit'lik bir sürüm aslında nedir

Bu blog yazısının, GeekBye v1.7.0'daki her şeyi sıralayan bir versiyonu var — yeniden tasarlanmış bir ana ekran, bir kalibrasyon akışı, katlanabilir bir kenar çubuğu, yeni ayarlar ve böyle uzayıp giden bir liste. Doğru olurdu ve size hiçbir şey öğretmezdi. Çünkü 127 commit'lik bir sürümün dürüst hikâyesi liste değildir. Şekildir.

İşte şekil bu. Yüz yirmi yedi commit, yüz yirmi yedi küçük şey gibi kulağa gelir. Neredeyse hiçbir zaman öyle değildir. v1.7.0, yaklaşık on bir gün boyunca uzun ömürlü dallarda paralel olarak inşa edilen, sonunda birbirine örülen iki büyük özellikti. Büyük bir sürümü anlamak, bu iki ipliği anlamak demektir — ve bir şeyi yanlış noktada inşa edip uçuşun ortasında geri sökmek zorunda kaldığımız o tek yeri.

İplik bir: kalibrasyon

İlk iplik kalibrasyondu — iletişim becerilerinizin yapay zekâ destekli bir sesli değerlendirmesi. Yapay zekâ bir "kariyer koçu" ile canlı bir görüşme başlatırsınız, yapılandırılmış bir dizi aşamadan geçersiniz (ısınma, davranışsal, teknik iletişim, baskı altında tepki, hedef belirleme) ve sonunda altı boyutta puanlanırsınız: özgüven, netlik, belirginlik, katılım, soğukkanlılık, ilgililik. Alt katmanda somut konuşma metriklerini de ölçer — konuşma hızınız, dolgu sözcük sıklığınız, duraklamalarınızın stratejik mi yoksa tereddütlü mü okunduğu.

Çıktı bir not değil, bir başlangıç noktasıdır. Kalibrasyon; güçlü yönlerinizi, gelişim alanlarınızı ve — en önemlisi — pratiğe başlamanız için önerilen bir zorluk seviyesini üretir. Ürünün sizinle nerede buluşması gerektiğini kalibre eder. Her beceri; bir özet, somut bir öneri ve örnek olarak kendi görüşmenizden gerçekten alıntılanmış bir cümle içeren, açılıp genişleyen bir geri bildirim kartı olarak geri döner. Pratik deneyiminin geri kalanının üzerine inşa edildiği özellik budur.

İplik iki: bambaşka bir pencere

İkinci iplik bir premium yeniden tasarımdı — ve buna yeniden tasarım demek onu küçümsemek olur. Mevcut ekranların bir yüzey değişimi değildi; aslında altı açık aşamada inşa edilmiş bir ikinci uygulama penceresiydi: katlanabilir, Notion tarzı bir kenar çubuğu, eski oturum listesinin yerini alan bir başlık açılır menüsü, geçmiş ve içerik yolu (breadcrumb) içeren tarayıcı tarzı navigasyon ve Ana Ekran, Profiller, Toplantılar ve Ayarlar'ın premium yeniden inşaları.

İki büyük özellik. 127 commit aslında buydu. Ve bunları yayınlamanın en zor kısmı ikisinden herhangi birini yazmak değildi — örgüydü. İki dal birbirine bağımlıydı; biri diğerinin içine birleştirildi ve kalibrasyon dalı, yeniden tasarım altında hareket ederken senkronizasyondan çıkmamak için main dalını dört ayrı kez çekmek zorunda kaldı. Commit sayısı büyük bir sürümün maliyeti değildir. Uzun ömürlü dallar ve entegrasyon sırası maliyettir.

Okumaya değer kısım: kalibrasyonu yanlış yerde inşa ettik

İşte hata, ve iyi bir hata çünkü çok yaygın.

GeekBye'ın kesin bir mimari kuralı var: tüm yapay zekâ işlemleri backend'de yaşar. İstemci, bir sunucuyla konuşan ince bir kabuktur. Herkes bunu biliyordu.

Ve yine de kalibrasyon önce istemcinin yerel veritabanında inşa edildi. Özel bir tablo, bir veritabanı migrasyonu, 254 satırlık bir repository, IPC işleyicileri ve 515 satırlık bir değerlendirme sorusu bankası — hepsi kullanıcının makinesinde yaşıyordu. Çalışıyordu. Aynı zamanda tüm uygulamanın üzerine kurulu olduğu sözleşmeyi sessizce ihlal ediyordu.

Üç gün sonra tek bir commit, hepsini backend'e taşımak için sekiz dosyada 680 satır sildi; burada kalibrasyon verileri düzgün bir sunucu tarafı modeline dönüştü ve soru mantığı ile puanlama bir sunucu meselesi haline geldi. Başka bir commit, 515 satırlık istemci soru bankasını tamamen sildi. Diff neredeyse komik: bir ekleme, altı yüz seksen silme.

Kimse 680 satırlık atılacak kod yazmaya niyetlenmedi. Bu hep olduğu gibi oldu: istemci kestirmesi tam oradadır, yerelde prototip yapmak daha hızlıdır ve "sonra backend'e taşırız" zararsız hissettirir. Ama mimariniz tek doğruluk kaynağının nerede yaşadığını zaten söylüyorsa, onu başka bir yerde inşa etmek bir kestirme değildir — kendinize önceden planladığınız yeniden yapılan iştir. Akılda kalan ders: yerel sürümü ayağa kaldırmak daha hızlı olsa bile, sözleşmenin söylediği yere, ilk seferinde koyun.

Yalnızca entegrasyonun bulabileceği hata

Bir makbuz daha, çünkü bu büyük sürümlerin imza niteliğindeki başarısızlık biçimidir. Kalibrasyon ve yeni navigasyon birbirine bağlanıp gerçekten çalışmaya başladığında, uygulama belirgin bir sebep olmadan bir istek limitini — HTTP 429'ları — tetiklemeye başladı.

Sebep saf entegrasyondu. Kalibrasyon durumu bileşen düzeyinde çekiliyordu, dolayısıyla her navigasyon onu yeniden çekiyordu — ve hataları ortaya çıkarmak için geliştirmede efektleri kasıtlı olarak iki kez çağıran React'in strict mode'u bunu tekrar ikiye katladı. Sonuç, sunucunun istek sınırlayıcısını tetiklemeye yetecek kadar ekran değişimi başına dört ila sekiz özdeş kalibrasyon isteğinin ateşlenmesiydi. Düzeltme, çekme işlemini mount sırasında birkaç çağrıya konsolide etti.

Bu hatayı yalnızca kalibrasyonu test ederek ya da yalnızca navigasyonu test ederek bulamazdınız. Yalnızca dikişte var olur — bağımsız olarak doğru olan iki özelliğin buluştuğu yerde. Büyük bir sürümün aldığı vergi budur: son adım özellikleri inşa etmek değildir, yalnızca ikisi nihayet aynı odada olduğunda kırılan her şeyi keşfetmektir.

Büyük bir sürümün öğrettiği üç şey

1. 127 commit'lik bir sürüm, yüz küçük tema değil, iki ya da üç büyük temadır. İplikleri bulun. İş — ve risk — sayıda değil, bunların birbirine nasıl örüldüğünde yaşar.
2. Tek doğruluk kaynağını, sözleşmenin söylediği yere, ilk seferinde koyun. Kalibrasyonu istemciden backend'e taşırken 680 satır sildik. Yerel kestirme, önceden planladığınız yeniden yapılan iştir; mimari cevabı size zaten söyledi.
3. Entegrasyon, izolasyonun yapamadığı başarısızlıkları ortaya çıkarır. 429 fırtınası, iki doğru özellik arasındaki dikişte yaşadı ve yalnızca birlikte çalıştıklarında ortaya çıktı. Yalnızca özellik başına test değil, bir entegrasyon turu için bütçe ayırın.

Bu, çok daha büyük ölçekte yeniden anlatacağımız bir hikâyenin v1 döneminden bir kuzenidir — bkz. bir versiyon 2'nin gerçekte neler gerektirdiği: dürüst durumların 206 commit'i (v2.0.0); burada aynı "büyük bir sayı aslında birkaç büyük fikirdir" gerçeği, tüm v2 yeniden yazımı boyunca kendini gösterir. v1 hikâyesindeki bir önceki bölüm için, canlı bir raporu titremeden nasıl akıtırsınız (v1.6.13); ve tüm yay için, yazılımı kusursuzluğa kadar yayınlamanın anatomisi.