Home | Blog | Guide

Geliştiriciler İçin Araçlar Arası Arama: Kod Yanlış Yer

Geliştirici kararlarının çoğu kodun dışında yaşar. Slack, Linear, GitHub ve Notion genelinde araçlar arası aramanın nasıl kurulacağını öğrenin.

By Ellis Keane · 2026-03-17

Kod tabanınız, bir kararın neden alındığını aramak için en az kullanışlı yerdir.

Bunun geriye doğru gittiğini biliyorum. Ripgrep flag'lerini öğrenmek, IDE aramasını yapılandırmak, regex kalıplarını ezberlemek için yıllar harcıyoruz – ve soru "bu fonksiyon nerede?" değil de "tartıştığımız üç alternatife karşın bu yaklaşımı neden seçtik?" olduğunda bunların hiçbirinin faydası yok. İkinci sorunun yanıtı neredeyse hiç kodda değil. Dört ay önceki bir Slack konusunda, durum güncellemelerinin altına gömülmüş bir Linear yorumunda, birinin başlayıp hiç bitirmediği bir Notion belgesinde ve gerçek tartışmanın bir yanıtın yanıtının yanıtında gerçekleştiği bir PR incelemesinde.

İşte geliştiriciler için araçlar arası arama sorunu bu – karar bağlamı, birleşik bir sorgu yolu olmaksızın araçlara dağılmış durumda. Her araç içinde iyi çalışan bir arama var – Slack'in araması fena değil, GitHub'ın kod araması mükemmel, Linear'ın her şey için filtreleri var – ama bunları aşan bir arama yok. Mimarinizi şekillendiren kararlar beş farklı yerde ve hangi yere bakmanız gerektiğini hatırlamanız bekleniyor.

Peki – zaten sahip olduklarınızla araçlar arası aramayı nasıl kurabileceğinizi anlatalım. Yeni araç gerekmez (neredeyse – sonunda bir tanesinden bahsedeceğim, ama bu onsuz da çalışır).

Dağınık Bir Kararın Anatomisi

Somut bir şeyi ele alalım. Geçen yıl, iş kuyruğumuz için BullMQ mi yoksa Temporal mı kullanacağımıza karar veriyorduk. İşte bu kararın gerçekte nerede yaşadığı:

Slack (#engineering): İki gün boyunca üç ayrı konu. Birincisi, birinin Temporal blog gönderisine paylaştığı bir bağlantıydı. İkincisi, dayanıklı yürütmeye ihtiyaç duyup duymadığımıza dair bir tartışmaydı. Üçüncüsü (bir hafta sonra, farklı kanal) birisinin "bekle, kuyruk meselesine karar verdik mi?" diye sormasıydı.
Linear: "İş kuyruğu seçeneklerini değerlendir" başlıklı bir konu ve altı yorum; mühendislerimizden birinin yarım gün yazarak hazırladığı bir karşılaştırma tablosu dahil.
GitHub: BullMQ uygulaması için "konuşulduğu gibi" yazan ve nerede konuşulduğuna dair sıfır bağlantı içeren bir PR açıklaması.
Notion: Temporal'ın artılarını kapsayan ancak nihai seçimle hiç güncellenmemiş yarım kalmış bir mimari karar kaydı.
Google Docs: Kararı gerçekten aldığımız çağrıdan toplantı notları; iki ilgisiz gündem maddesi arasındaki madde işaretlerine gömülmüş.

Beş araç. Bir karar. Ve herhangi bir araçta arama yapsaydınız, bir parça bulurdunuz – asla tam resmi değil. PR ne seçtiğimizi söyler. Slack konuları neleri değerlendirdiğimizi söyler. Linear konusu değerlendirmeleri söyler. Notion belgesi gerekçenin yarısını söyler. Toplantı notları nihayet karara varıldığı anı söyler.

Bu olağandışı değil. 2026'da mühendislik ekiplerinin kararları takip etme sanatının durumu bu. Kod üreten yapay zekamız ve tüm interneti dizinleyen arama motorlarımız var; ama ekibinizin neden Temporal yerine BullMQ seçtiğini bulmak beş uygulamayı kontrol etmeyi ve birinin hafızasının tutmasını umut etmeyi gerektiriyor.

Araçlar Arası Aramayı Geliştiriciler İçin Zorlaştıran Şey

Bu bir API sorunu değil – kullandığımız her araçta gayet iyi bir arama API'si var. Sorun bundan daha tuhaf:

Farklı veri şekilleri. Slack, zaman damgaları ve kanal kimliklerine sahip mesajlar döndürür. Linear, durumlar ve etiketlere sahip konular döndürür. GitHub, commit'leri, PR'ları ve kod eşleşmelerini tamamen farklı yanıt biçimlerinde döndürür. Bunları tutarlı bir zaman çizelgesinde birleştirmek, kimsenin yazmaya zahmet etmediği bir normalleştirme gerektirir (çünkü dürüstçe söylemek gerekirse sprint demolarında görünmeyen iş türü bu).

Bağlam parçalanması. "B seçeneğiyle gidelim" diyen bir Slack mesajı, A, B ve C seçeneklerini tanımlayan konu olmadan anlamsızdır. Ancak Slack'in araması konuşma yayları değil, bireysel mesajlar döndürür. Gerekçe olmadan sonucu bulursunuz.

Zamansal kayma. Karar süreci çoğunlukla günlere veya haftalara yayılır; herkesin başka işlere dalmış olduğu için hiçbir şeyin olmadığı boşluklarla birlikte. Anahtar kelime araması bir konuşmanın başını ve sonunu yüzeye çıkarabilir; ancak farklı aşamalarda farklı sözcükler kullanıldığı için hayati orta kısmı gözden kaçırabilir.

Geliştiriciler için araçlar arası arama bir API sorunu değil – her aracın gayet iyi bir arama endpoint'i var. Bu bir bağlam sorunudur: kararlar uyumsuz şekillerde araçlara dağılmış, konuşma yaylarıyla parçalanmış ve zamansal kaymayla ayrılmış durumda. Anahtar kelime araması parçaları bulur; yalnızca bağlantılı bağlam tam resmi bulur.

Elinizdekileri Kullanarak Araçlar Arası Arama Oluşturma

İşte pratik kısım. Yalnızca okuma aramasına sahip üç veya dört araç için, bir MVP'yi çalışır hale getirmek için yarım gün bekleyin – bunun büyük bölümü arama mantığının kendisinden çok kimlik doğrulama kurulumu ve yanıt normalleştirmesine harcanır.

API Erişimini Kurma

Her araç için token'lara ihtiyacınız var:

Slack: search:read kapsamına sahip bir kullanıcı token'ı (Slack'in arama yöntemleri bot token değil, kullanıcı token'ı gerektirir – Slack API uygulamaları sayfasından oluşturun)
Linear: Ayarlar menüsündeki API bölümünden kişisel API anahtarı
GitHub: Repolarınıza okuma erişimi olan ayrıntılı bir PAT
Notion: Ayarlar menüsündeki Bağlantılar bölümünden dahili entegrasyon token'ı

Fan-out Sorgu Betiği

Temel kalıp utanç verici derecede basit – aynı arama sorgusunu her API'ye gönderin ve sonuçları toplayın:

```typescript interface SearchResult { source: 'slack' | 'linear' | 'github' | 'notion'; title: string; snippet: string; url: string; timestamp: Date; }

async function crossToolSearch(query: string): Promise<SearchResult[]> { const results = await Promise.all([ searchSlack(query), searchLinear(query), searchGitHub(query), searchNotion(query), ]);

return results .flat() .sort((a, b) => b.timestamp.getTime() - a.timestamp.getTime()); } ```

Her search* fonksiyonu ilgili API'yi sarar. Slack için bu search.messages. Linear için arama alanlarına karşı bir GraphQL sorgusu. GitHub için REST arama endpoint'i. Notion için query parametresiyle arama endpoint'i.

Normalleştirme ve Tekilleştirme

Zor olan kısım arama değil – sonuçları kullanışlı hale getirmek. Şunları yapmak isteyeceksiniz:

Zaman damgalarını normalleştirin – araçlar genelinde (Slack Unix epoch kullanır, Linear ISO dizileri kullanır, GitHub saat dilimi uzaklıklı ISO kullanır)
İlgili sonuçları gruplandırın – üç mesaj eşleştiği için aynı Slack konusu üç kez görünüyorsa, bunları konu URL'siyle tek bir sonuçta birleştirin
Uygunluğa göre sıralayın – çoğu API kendi uygunluk puanlarını döndürür, ancak bunlar araçlar genelinde karşılaştırılamaz. Basit bir kural: başlıklardaki tam anahtar kelime eşleşmeleri, gövde eşleşmelerinin üzerinde yer alır; eşit uygunlukta daha yeni sonuçlar daha eskilerinin önüne geçer

CLI'ye Sarma

Bunun için Commander.js kullanıyorum (çoğunlukla alışkanlıktan, ama her şey işe yarar):

```bash $ cross-search "bullmq vs temporal"

Found 14 results across 4 tools:

[Slack] #engineering – 2025-11-14 "I've been comparing BullMQ and Temporal for the job queue..." https://myteam.slack.com/archives/C0X.../p17318...

[Linear] ENG-342 – 2025-11-15 "Evaluate job queue options – BullMQ vs Temporal" https://linear.app/myteam/issue/ENG-342

[GitHub] PR #289 – 2025-11-22 "feat: implement BullMQ job queue (as discussed)" https://github.com/myorg/myrepo/pull/289

[Notion] Architecture Decisions – 2025-11-13 "Job Queue Evaluation: Temporal vs BullMQ" https://notion.so/myteam/abc123... ```

Dört araç genelinde zamana göre sıralanmış on dört sonuç. Kararın tam yayını tek bir yerde görebilirsiniz: önce Notion belgesi başlatıldı, sonra Slack tartışması yaşandı, ardından takip için Linear konusu oluşturuldu ve son olarak bir hafta sonra PR geldi.

Gerçekten İyi Hale Getirme

Yukarıdaki temel sürüm çalışıyor, ancak bazı sinir bozucu kenar durumları var. Nasıl geliştireceğiniz:

Slack için konu genişletme. Eşleşen bir mesaj bulduğunuzda, tüm konuyu conversations.replies ile çekin. Eşleşen mesaj "tamam, BullMQ ile gidelim" olabilir – önceki 40 tartışma mesajı olmadan işe yaramaz. Yalnızca eşleşen mesajı değil, konunun bir özetini görüntüleyin.

PR inceleme yorumları. GitHub'ın arama API'si PR'ları aradığınızda inceleme yorumlarını yüzeye çıkarmaz – bunları almak için pull request incelemeleri endpoint'ine ayrı bir çağrı yapmanız gerekir. Gerçek teknik tartışma orada yaşar.

Geri bağlantılar. Bir Linear konusu bulduğunuzda, herhangi bir Slack mesajının o konunun URL'sini içerip içermediğini kontrol edin. Slack'in araması anahtar kelimelerle birleştirilmiş has:link filtrelerini destekler. Bu, resmi takip etrafında gerçekleşen gayri resmi tartışmayı yüzeye çıkarır.

Önbellekleme. Ekibiniz çok fazla içerik üretiyorsa (kimin üretmediği ki), hız sınırlarına hızla çarparsınız. Sonuçları 30 dakikalık bir TTL ile yerel olarak önbelleğe alın – geçmişteki kararların çoğu o kadar hızlı değişmez.

Metin Araması Başarısız Olduğunda

Burada sınırlamalar konusunda dürüst olacağım. Araçlar genelinde anahtar kelime araması şaşırtıcı derecede uzağa götürür, sonra bir duvara çarpar.

Duvar şu: kararlar gelişir. "İş kuyrukları" hakkındaki Slack konusu hiç "BullMQ" adını kullanmamış olabilir – bunun yerine biri bir bağlantı paylaştı, bir diğeri "Redis destekli seçeneği beğendim" dedi ve üçüncüsü "katılıyorum, onunla gidelim" dedi. "BullMQ" aramanız sözcük hiç kullanılmadığı için tüm konuyu kaçırır. Konudaki insanlar "Redis destekli seçeneğin" ne anlama geldiğini biliyordu. Aramanız bilmiyor.

Bu temelde bir metin sorunu değil, bir grafik sorunudur. Gerçekte istediğiniz şu: "PR #289'a yol açan kararla bağlantılı her şeyi göster." Bu, PR'ın bir Linear konusuna atıfta bulunduğunu, bunun bir Slack tartışmasından sonra oluşturulduğunu ve bunun birisinin bir Notion belgesini okumasıyla başladığını anlamak demektir. Bağlantılar örtük – insanlar URL'leri kopyalayarak ve "konuşulduğu gibi" diyerek bunları oluşturdu – ve bir anahtar kelime araması bunları yeniden inşa edemez.

Bağlantıları izleyerek bunu kısmen çözebilirsiniz. Slack mesajlarından, PR açıklamalarından ve Linear yorumlarından URL'leri ayrıştırın. Basit bir komşuluk listesi oluşturun: bu Slack konusu bu Linear konusuna bağlanıyor, bu PR'da atıfta bulunuluyor. Ardından biri arama yaptığında, anahtar kelimeyle eşleşmeseler bile bağlantılı öğeleri içerecek şekilde sonuçları genişletebilirsiniz.

Bu komşuluk listesi yaklaşımı özünde ilkel bir bilgi grafiği – ve geliştiriciler için araçlar arası aramanın gerçek değeri burada yatıyor. Bireysel mesajları bulmak değil, bir kararın ipliğini dokunduğu her araç genelinde takip etmek. Bu "arama"dan çok geliştirici bilgi yönetimi – bağlamı ihtiyaç duyduğunuzda yeniden oluşturabilmek için bilginin araçlarınız arasında nasıl aktığını anlamak.

Bakım Sorunu (ve Bir Kısayol)

Betik yaklaşımı yaklaşık üç ay boyunca harika çalışır, sonra biri Slack çalışma alanını değiştirir ya da Linear GraphQL şemasını günceller ya da yeni bir araç eklersiniz ve kimse arama betiğini güncellemeyi hatırlamaz. Bu şeyi tam olarak iki kez kurdum ve iki kez terk ettim (bu muhtemelen yaklaşımın kendisinden çok bakıma olan bağlılığım hakkında daha fazla şey söylüyor).

Bakım yapmadan güncel kalan geliştiriciler için araçlar arası arama istiyorsanız, Sugarbug gibi araçlar bunun için yapıldı – bilgi grafiğini otomatik olarak korur ve araçlarınız değiştikçe bağlantıları canlı tutar. Ancak yukarıdaki kendin yap sürümü, bakımını yapmaya hazırsanız gerçekten kullanışlıdır.

Beş aracı ayrı ayrı aramayı bırakın. Sugarbug, herhangi bir karar, tartışma veya commit'i tek bir yerde bulabilmeniz için bilgi grafiğini oluşturur.

Q: Birden fazla geliştirici aracında aynı anda nasıl arama yapabilirim? A: Her aracın API'sini – Slack'in search.messages, Linear'ın issueSearch ve GitHub'ın kod arama endpoint'ini – sorguları dağıtıp sonuçları zaman damgasına göre birleştiren tek bir betiğe ekleyerek hafif bir araçlar arası arama oluşturabilirsiniz. Yukarıdaki kod örnekleri sizi bir öğleden sonra başlatacak. Asıl zorluk aramanın kendisi değil, farklı yanıt biçimlerini tutarlı bir zaman çizelgesinde normalleştirmektir.

Q: Sugarbug geliştiriciler için araçlar arası arama sağlıyor mu? A: Evet. Sugarbug, Linear, GitHub, Slack, Figma, Notion ve diğer araçlardan gelen sinyalleri bir bilgi grafiğine alır; böylece bir karar veya tartışmayı arayabilir ve bağlı her konuyu, sorunu ve commit'i tek bir yerde bulabilirsiniz. Normalleştirme, tekilleştirme ve bağlantı takibini otomatik olarak yönetir – kendin yap yaklaşımını zamanla kırılgan hale getiren kısımları.

Q: Neden mimari kararları kod tabanımda bulamıyorum? A: Çünkü çoğu karar Slack konularında, Linear yorumlarında, Notion belgelerinde ve PR incelemelerinde gerçekleşir – kodun kendisinde değil. Kod bir kararın sonucunu kaydeder (fonksiyon var, kütüphane seçildi); ancak gerekçe, değerlendirmeler ve tartışılan alternatifler iletişim araçlarınıza dağılmış halde yaşar. git blame size kimin bir satırı ne zaman değiştirdiğini söyler, ama neden o yaklaşımı alternatiflere tercih ettiklerini değil.

Q: Sugarbug karar takibi için ADR belgelerinin yerini alabilir mi? A: Sugarbug ADR'lerin yerini almaz; ancak hiç ADR'ye girmemiş kararları yakalar. Çoğu ekip mimari seçimlerinin yalnızca yaklaşık %10'u için ADR yazar – geri kalanı Slack konularında ve PR yorumlarında çözülür. Sugarbug, konuşmaları ürettikleri kod değişikliklerine bağlayarak bunları yüzeye çıkarır; böylece kimsenin iş akışını değiştirmeden diğer %90 için karar takibini elde edersiniz.