2 puan yazan GN⁺ 2024-07-26 | 1 yorum | WhatsApp'ta paylaş
  • Haystack, PR’nin konuşma geçmişini ve değişikliklerini birlikte okuyarak yalnızca gerçekten insan muhakemesi gerektiren değişiklikleri inceleyicilere yönlendiren bir kod inceleme aracı olarak sunuluyor
  • Temiz PR’leri otomatik birleştirip riskli PR’leri seçilecekler olarak sınıflandırarak, “human code review time to zero”ya yakın bir akışı hedefliyor
  • Örnek PR, tenancyInit() ve cacheWarmup() işlemlerini Promise.all() ile paralelleştirerek soğuk başlatmayı yaklaşık 4 saniyeden 2,4 saniyeye düşürdü, ancak geçmişte verilmiş yürütme sırası kararını geri aldı
  • Haystack, konuşma geçmişinde cacheWarmup’ın tenancyInit sonrasında çalışması gerektiğine dair gerekçeyi buluyor ve sandbox’ta 50 başlatmanın 31’inde çökme olduğunu doğruluyor
  • Sorunlu PR, ilk sırayı belirleyen @mayaya iletiliyor; bozulan tasarım kararı ve başarısızlık sonucu PR’ye eklenerek inceleme karar süresi azaltılıyor

PR incelemelerini otomatik seçen akış

  • Haystack, tüm PR’lerin konuşma geçmişini ve değişikliklerini okuyup risk düzeyini değerlendiriyor
  • Riskli PR’leri uçtan uca çalıştırarak doğruluyor ve yalnızca insan muhakemesi gerektiğinde inceleyiciyi sürece dahil ediyor
  • Ekranda Haystack’in 16 PR’yi seçtiği görülüyor
    • TypeScript, JavaScript, C, Python, Ruby, Go, C++ gibi çeşitli dillerde PR’ler listeleniyor
    • Her PR analyzing durumunda gösteriliyor

Riskli değişiklik örneği: servis bootstrap’ini paralelleştirme

  • Örnek PR platform#3120 feat: parallelize service bootstrap, servis bootstrap aşamalarını paralelleştiren bir değişiklik
  • Mevcut kod önce tenancyInit()i çalıştırıyor, ardından cacheWarmup()ı sıralı olarak çalıştırıyor
  • Değiştirilen kod iki işi Promise.all([tenancyInit(), cacheWarmup()]) ile aynı anda çalıştırıyor
  • PR açıklamasına göre soğuk başlatma yaklaşık 4 saniyeye kadar uzamıştı; paralelleştirmeden sonra yaklaşık 2,4 saniyeye düştü
  • Mevcut testlerin tamamı geçtiği için dışarıdan onaylaması kolay bir performans iyileştirmesi gibi görünüyor

Konuşma geçmişinde ortaya çıkan tasarım kararı

  • Haystack, PR’nin arkasındaki geçmişi okuyarak değişikliğin geçmiş bir tasarım kararını geri aldığını tespit ediyor
  • @maya, cacheWarmup’ın boş yapılandırma okumaması için önce tenancyInit’in tamamlanması gerektiğini belirtmişti
  • Test paketinde bu yürütme sırasını doğrulayan bir madde bulunmadığından regresyon testlerden geçiyor
  • Haystack review, PR’ye şu bilgileri ekliyor
    • Konuşma geçmişinde kalan karar
    • Mevcut PR’nin fiilen değiştirdiği davranış
    • Testlerin neden geçtiği

Çalıştırma doğrulaması ve başarısızlık sonucu

  • Haystack, kodu okumakla yetinmeyip değişikliği doğrudan çalıştırıyor
  • Konuşma geçmişi testlerde bulunmayan bir zamanlama yarış koşuluna işaret edince, servisi sandbox’ta 50 kez başlatıyor
  • 50 denemenin 31’inde cacheWarmup, tenancyInit tamamlanmadan önce boş yapılandırmayı okuyor
  • Bunun sonucunda servis ilk istekte istisna fırlatıp çöküyor
  • Haystack QA, çalıştırma gerekçesini, yapılan testi ve kırılan noktayı PR’de birlikte gösteriyor

İnsan incelemesi gereken nokta

  • Haystack bu PR’yi otomatik birleştirmiyor; bunun yerine ilk yürütme sırasını belirleyen @mayanın sürece dahil edilmesini öneriyor
  • PR’de bozulan tasarım kararı ve başarısız başlatma sonuçları birlikte gösteriliyor
  • İnceleme ekranı “Request review”, “Chat with @maya”, “Doesn’t need review” gibi seçenekler sunuyor
  • Haystack’in akışı, çoğu PR’yi otomatik birleştirmeye ve örnekteki gibi yalnızca riskli değişiklikleri doğru kişiye yönlendirmeye odaklanıyor

1 yorum

 
GN⁺ 2024-07-26
Hacker News görüşleri
  • Yapay zeka özelliklerinden pek emin değilim ama kanvas üzerinde kodla çalışmak ve akış diyagramı UI’ını birlikte kullanmak fikri uzun zamandır istediğim bir şeydi.
    Çoğunlukla veri işleme yapıyorum ve pipeline’ları açıklamak ya da kendim anlamak için sık sık akış diyagramları çiziyorum.
    Bu yönde bir geliştirme UI’ı, CS mezunu olmayan kişilerin oluşturduğu, başa çıkması zor codebase’lerle uğraşmak için iyi olabilir.

    • LabView gibi araçları mı düşünüyorsunuz?
      https://www.ni.com/en/shop/labview.html
    • Java’da BlueJ’nin yaptığına benzer bir şey mi?
    • Karşılaşılan sorunun veri akışını görselleştirmek mi, yoksa kontrol akışını görselleştirmek mi olduğunu merak ediyorum.
    • Aynı kanvas içinde diyagram ve kodu birlikte eskizleyebilmek harika olurdu.
      Görsel dokümantasyonun çok daha kolaylaşacağını düşünüyorum.
  • Gerçekten harika. Bir metoda ya da bildirime giderken tüm dosyayı tanımın bulunduğu yere kadar kaydırılmış bir yan sekmede açmak yerine, yalnızca ilgili kod parçalarını göstermesi hoşuma gitti.
    Bir metodun çağrıldığı yerlerle tanımını karşılaştırmam gerektiği için okumakta olduğum metodu sık sık kaybediyorum; bu da epey sinir bozucu.
    Metodu yanda “sabitleyip”, sabitlenmiş görünümde yanlışlıkla tüm dosyayı kaydırmadan göz gezdirebilmek güzel.
    Kısa süre denedim; ne yazık ki oldukça fare merkezliydi ve başka bir metodun içindeki metodu takip ettikçe yönetmem gereken çok fazla yüzen pencere oluştu.
    Hangi pencerenin “ebeveyn” pencere olduğunu takip edebilmek için oklar ya da çizgiler olursa bir tür akış diyagramı oluşturmak kolaylaşırdı.
    Kişisel olarak eksik bulduğum yanları var ama bu alanda farklı bir düşünme biçimi görmek sevindirici; başarılı olmasını dilerim.

    • Neden hoşuna gittiğini anlıyorum ama uzun vadede net etkisinin negatif olabileceğini düşünüyorum.
      Kodda neyin nerede olduğunu bir ölçüde bilmenin faydalı olduğuna inanıyorum.
      Bir projede yıllarca çalışıp da sadece küçük parçalar üzerinden çalıştığınız için dosyaların aslında ne yaptığını bilmez hâle gelmeniz mümkün değil mi?
    • Edebi programlama bunu tek boyutta, yani dikey kaydırma yöntemiyle uygular ve iki görünüm sunar.
      Yorumlar ve metnin karıştığı özgün kaynak kodu ile biçimlendirilmiş metin ve gezinme için hyperlink’ler içeren, güzel dizilmiş kod görünümü vardır.
      http://literateprogramming.com/
    • Evet, klavyeyle daha kolay gezinebilir hâle getirmek için çalışma gerekiyor.
      “Ebeveyn pencere”nin referans noktası olarak ne hayal ettiğini merak ediyorum.
      Belirli bir pencereyi anchor olarak mı belirlemek istiyorsun, yoksa böyle bir anchor’ı bir heuristik’in bulmasını mı istiyorsun, bilmek isterim.
  • Lansman için tebrikler. Ben bugünlerde tamamen ters yöne gidiyorum; odaklanma ve ADHD eğilimleri nedeniyle oradan oraya atlayıp bunalma hâlimi azaltmaya yardımcı oluyor.
    Tek pencere, her şeyi minimize etmek ve en önemlisi ağaç gezintisini kaldırmak.
    Bir dosyaya gitmem gerekiyorsa Intellij’in son kullanılanlar menüsünü kullanıyorum ya da dosya marker’larına atlıyorum.
    Bu, dosya marker’larını hatırlamam ve oraya gitme niyetimin olması gerektiği anlamına geliyor. Vim kısayolları için IdeaVim eklentisini kullanıyorum.
    Benim için bu yöntem programlamayı çok daha odaklı ve keyifli hâle getiriyor.
    Çoklu ekrandan geniş ekrana geçip sonra yeniden tek ekrana dönme değişimimin bir parçası.
    Bahsedilen türden büyük ve olgun codebase’lerde ise LLM’i yol gösterici olarak kullanıyorum.

    • Bunu nasıl kullanıyorsunuz? Büyük ve olgun codebase derken ne büyüklüğü kastediyorsunuz, onu da merak ediyorum.
      Benim deneyimime göre LLM’ler tek bir dosyada bile epey hata ve varsayım yapıyor.
    • Anlıyorum. LLM’i nasıl yol gösterici olarak kullandığını merak ediyorum.
      Benim deneyimimde, LLM’e bir özelliğin akışının nerede olduğunu sorduğumda giriş noktasını iyi çıkarıyor ama ayrıntıları çoğu zaman kendim çözmek zorunda kalıyorum; bazen de ilgili ama aradığım yerden farklı bir yeri gösteriyor.
  • İlginç. Birkaç notum var.
    Obsidian’da “Canvas” adlı benzer bir özellik var; o iş akışına bakmaya değer.
    Benim için bağımsız bir araç olarak işe yaramaz; Idea eklentisi olarak gerekli.
    En sevmediğim kısım layout oluşturmak. Bir Git patch’i ya da hata düzeltmesini alıp ona uygun layout’u oluşturan bir AI olsa iyi olurdu.
    Layout paylaşımı çok kolay olmalı.
    Git geçmişini başka bir boyut olarak entegre etmek iyi olurdu. Editörün içinde diff ve blame gösterimleri de olsa güzel olur.
    AI eğitiminde kullanılabilecek veri, yani Git commit’leri var.
    Debugging de başka bir boyut olarak entegre edilmeli; profiler verileri de entegre edilse iyi olur.

    • Demo videosuna bakınca bağımsız değil, VSCode içinde çalışıyor gibi görünüyor.
      Orada sunulanları aynen almış oluyorsunuz.
      Idea ailesi araçlarını kullanıyorsanız şimdilik bir yol yok gibi görünüyor.
    • Araç iyi görünüyor ve iş için denemek istiyorum. Android/Kotlin olduğu için IDEA entegrasyonuna bir oy daha.
  • Uzun zamandır böyle bir şeyi denemek istiyordum. Güncellemeleri almanın bir yolu var mı?
    Özellikle ilk denemede bile olsa AI özelliklerini kapatma seçeneğini bekliyorum
    Bir fonksiyonun içine yakınlaşıp dosyanın geri kalanını gizleme özelliği özellikle hoşuma gitti. Böyle bir şeyi istediğim anların sayısı şaşırtıcı derecede fazlaydı
    Tek bir dosya içinde şu anda üzerinde çalıştığım fonksiyonları kolayca yana sürükleyip bırakarak, tek dosyayı sanal olarak yeniden düzenlemek için de kullanılabilir gibi görünüyor
    Düzenleme arayüzünün ötesinde, editörün içinde görselleştirme için çok fırsat olduğunu düşünüyorum
    Kendi kodum ile üçüncü taraf bağımlılıkların etkileşimi, kodumun bağımlılık/çağrı grafiği ya da bunun bir bölümü, sınıf veya modül düzeyinde bağımlılık grafiği, nesne içi çağrı grafiğine doğru derinleşen iç içe çağrı grafikleri mümkün
    Tüm bu durumlarda görselleştirme ile düzenleme arasında sorunsuz geçiş yapabilmek, bu aracın hedeflediği şey gibi görünen killer feature
    Editöre grafikler girdiği anda kod değişiklik sıklığı heatmap’i, kod performansı heatmap’i, değişken kullanım takibi gibi daha fazla ilginç görselleştirme mümkün olur
    https://adamtornhill.com/articles/crimescene/codeascrimescen...
    Son olarak, The Programmer's Brain’i okumadıysanız en azından bu podcast’i dinlemeniz iyi olur
    https://se-radio.net/2021/06/episode-462-felienne-on-the-pro...
    Beynimizin çalışma biçimiyle ilgili çok sayıda editör fikri var, ama bunların editörlerde iyi desteklendiğini henüz görmedim
    Zaten o yönde bir adım atmışsınız; belki daha fazla fırsat vardır

    • Ne yazık ki güncellemelere kaydolmak için henüz akıllıca bir yöntem oluşturmadık
      En iyi yolu düşüneceğim ve sonunda güncellemeleri doğrudan ürünün içinden göndereceğiz
      Şu anda copilot opt-out özelliğini ekliyoruz
      Buradaki fikirler güzel ve birkaçını birlikte tartışmak isterim. Sizin için uygunsa e-posta/DM göndereceğim
      Genel olarak birçok kişiyle konuşmak istiyoruz; feedback@haystackeditor.com adresinden geri bildirim alabiliriz
  • Fonksiyondan fonksiyona, dosyadan dosyaya ve sonra geri dönerek gezinme biçimini gerçekten sevdim
    Daha kullanışlı olması için tarayıcı geçmişi gibi bir gezinme geçmişi penceresi olsa iyi olurdu
    Dosyalar ve fonksiyonlar arasında hareket ederken bir liste gösterse; açık pencereler arasında zahmetle arama yapmadan ileri geri gidebilsek ya da gezinme geçmişindeki herhangi bir noktaya doğrudan atlayabilsek güzel olurdu
    Burada bahsettiğim gezinme geçmişi, düzenleme geçmişinden tamamen ayrı
    Düzenlemede geri al/yinele, gezinme geçmişinde ileri geri hareket ettirmemeli; tersi de aynı şekilde
    Elbette gezinme geçmişinde ileri geri gitmek için klavye kısayolları olabilir

    • İyi fikir. Bunu en iyi nasıl uygulayabileceğimizi düşüneceğim
  • Harika. Code Bubbles ile ilgili: https://dl.acm.org/doi/abs/10.1145/1753326.1753706

    • Evet, Bubbles harika. Özellikle minimap kavramını beğeniyorum
  • “Kodunuzu saklamıyor veya loglamıyoruz. Gezinme amaçlı copilot’un girdisi olarak kod parçalarını Open AI’a gönderiyoruz. Yakında bunu devre dışı bırakma seçeneği ekleyeceğiz.”
    O seçenek gelince bakmak isterim

    • Mac’te gezinme amaçlı copilot opt-out özelliğini ekledik
      Komut paletini (CMD+SHIFT+P) açıp “Opt out of navigational copilot” komutunu kullanabilirsiniz
      Windows/Linux desteği de yakında gelecek
      Verileri Open AI’a yalnızca var olmayan bir fonksiyonun çağrıldığına dair bir tanılama olduğunda gönderdiğimizi de not etmek isterim
    • Ben de aynı tepkiyi verdim. Böyle araçların geliştirilmesini desteklemek isterim, ama daha doğrudan bir yöntem tercih ederim
    • Katılıyorum. Baştan itibaren opt-in olmalıydı
    • Mevcut haliyle şirkette denemek zor görünüyor
  • Tuval tabanlı editör (Code Bubbles), geleneksel sekme tabanlı editör (Eclipse) ve tasarladığım carousel tabanlı editörün (Patchworks) gezinme sürelerini karşılaştıran bir makale yayımladım
    Tuvalin fazla özgürlük sunduğu sonucuna vardık
    https://austinhenley.com/pubs/Henley2014CHI_Patchworks.pdf

    • İlginç. IDE’nin mekânsal yerleşimi üzerine pek derinlemesine düşünmemiştim
      Geriye bakınca VS Code’da da artık sekmeleri kullanmıyorum. Çünkü açık dosya sayısı çok fazla
      Sadece tek seferde bir dosyaya bakıyorum; geçmem gerektiğinde Cmd-P ile arıyorum ya da son dosyalar arasında geziniyorum
      İyi çalışıyor ama dosya/dizin adlarını sürekli aklımda tutmam gerekiyor
    • Makaleyi sadece biraz okudum ama Eclipse ile ilgili tartışmaya bakınca, katılımcılar onu çok sekmeli bir editör gibi kullanmak yerine IDE gibi kullansalardı çok daha verimli olurlardı gibi geliyor
      Bir metodu bulmak, alfabetik sıralı bir outline görünümü olsaydı çok daha az sorun olurdu
    • Gerçekten ilginç. Grid ile tuval arasında kararsız kalmıştım ama pratikte gezinmenin daha kolay olduğunu düşündüğüm için tuvali seçtim
      Sizin için uygunsa konuşmak isterim; e-posta göndereceğim
    • İlginç. Patchworks, benim Doom Emacs’i yapılandırma biçimime bir ölçüde benziyor
      Birden fazla çalışma alanına yayılmış 4-6 kod paneli tutup SPC TAB sayı ile geçiş yapıyorum
    • Harika analiz. Benim için ister tuval tabanlı ister carousel tabanlı olsun, çok büyük kod tabanlarıyla çalışırken her zaman önemli miktarda bilişsel veriyi zihnimde tutma yükünü azaltıyor
      Aracı düzgün kullanmak için yeterli widescreen de fiilen gerekli
      Esas nokta, dosyaları dikey değil yatay yönde ele almaya alışmak
      Bu dikey düşünme biçimi, ilk Hello World’ü yazma şeklimize epey derinden kök salmış durumda
  • Lansman için tebrikler. Harika ve iyi uygulanmış bir araç gibi görünüyor; denemeyi sabırsızlıkla bekliyorum.
    Eskiden beri istediğim ve birkaç kez elle yapmayı da denediğim, ama paylaşılabilir bir biçime dönüştüremediğim bir özellik aklıma geliyor: kod yolunu tek bir script ya da kaynak dosyası olarak açıp dökme işlevi.
    Bir breakpoint gibi bir şey ayarlayıp “unravel” düğmesine bastığımda, o noktaya kadar gerçekleşen tüm işlemleri gösteren tek bir dosya kalsın isterdim.
    İdeal olarak o dosyanın tek bir script olarak çalıştırılabilmesi daha da iyi olur.
    Özünde bu, adım adım debugger’ın sunduğu görünüme benziyor; ancak birden fazla dosyaya ve birden fazla katmana başvurmak yerine, her şeyi baştan sona tek bir dosyanın içinde görmek istiyorum.

    • Buna neden ihtiyaç var? Hangi sorunu çözmeye çalışıyorsunuz? İstenen sonuç nedir?
      İnsanlar gereksinimler, parametreler ve sonuçlar yerine belirli uygulama ayrıntılarına odaklandığında, aktarım sırasında pek çok şeyin kaybolduğunu düşünüyorum.
      Bu uygulamayı neden istediğinizi, hangi işlevi ya da amacı yerine getirmesi gerektiğini merak ediyorum.