Ricerca multi-strumento: il codice è il posto sbagliato
La maggior parte delle decisioni degli sviluppatori vive fuori dal codice. Come costruire una ricerca multi-strumento su Slack, Linear, GitHub e Notion.
By Ellis Keane · 2026-03-17
La tua codebase è il posto meno utile dove cercare il motivo per cui è stata presa una decisione.
So che sembra illogico. Passiamo anni a imparare i flag di ripgrep, a configurare la ricerca nell'IDE, a memorizzare pattern regex – e niente di tutto ciò aiuta quando la domanda non è "dove si trova questa funzione?" ma "perché abbiamo scelto questo approccio rispetto alle tre alternative di cui avevamo discusso?" La risposta a questa seconda domanda quasi non è mai nel codice. È in un thread Slack di quattro mesi fa, in un commento Linear sepolto sotto aggiornamenti di stato, in un documento Notion che qualcuno ha iniziato e non ha mai finito, e in una revisione di PR dove il vero dibattito si è svolto in una risposta a una risposta a una risposta.
Questo è il problema della ricerca multi-strumento per gli sviluppatori – il contesto delle decisioni è suddiviso tra gli strumenti senza un percorso di query unificato. Abbiamo ricerche che funzionano bene all'interno di ogni strumento – la ricerca di Slack è discreta, la ricerca del codice di GitHub è eccellente, Linear ha filtri per tutto – ma nulla che cerchi tra tutti. Le decisioni che hanno plasmato la tua architettura vivono in cinque posti diversi, e ti si chiede di ricordare dove cercare.
Bene – ecco come costruire una ricerca multi-strumento con quello che hai già. Non servono nuovi strumenti (beh, quasi – ne menzionerò uno alla fine, ma questo funziona senza di esso).
L'anatomia di una decisione dispersa
Lasciami percorrere qualcosa di concreto. L'anno scorso stavamo decidendo se usare BullMQ o Temporal per la nostra coda di lavori. Ecco dove quella decisione viveva davvero:
- Slack (#engineering): Tre thread separati nell'arco di due giorni. Il primo era un link che qualcuno aveva condiviso a un post del blog di Temporal. Il secondo era un dibattito sull'eventuale necessità di durable execution. Il terzo (una settimana dopo, canale diverso) era qualcuno che chiedeva "aspetta, abbiamo deciso per la coda?"
- Linear: Una issue intitolata "Evaluate job queue options" con sei commenti, inclusa una tabella comparativa che uno dei nostri ingegneri aveva passato un pomeriggio a scrivere.
- GitHub: Una descrizione di PR per l'implementazione di BullMQ che diceva "as discussed" con zero link a dove era stato discusso.
- Notion: Un architecture decision record a metà che copriva i pro di Temporal ma non fu mai aggiornato con la scelta finale.
- Google Docs: Note di riunione di una chiamata dove avevamo effettivamente preso la decisione, sepolte in punti elenco tra due voci dell'ordine del giorno non correlate.
Cinque strumenti. Una decisione. E se avessi cercato in un singolo strumento, avresti trovato un frammento – mai il quadro completo. Il PR ti dice cosa abbiamo scelto. I thread Slack ti dicono cosa abbiamo considerato. La issue Linear ti dice i compromessi. Il documento Notion ti dice metà del ragionamento. Le note di riunione ti dicono il momento in cui è stato finalizzato.
Questo non è insolito. Questo è, in qualche modo, lo stato dell'arte di come i team di ingegneria tracciano le decisioni nel 2026. Abbiamo l'IA che genera codice e motori di ricerca che indicizzano l'intero internet, ma scoprire perché il tuo team ha scelto BullMQ rispetto a Temporal richiede di controllare cinque applicazioni e sperare che la memoria di qualcuno regga.
Cosa rende difficile la ricerca multi-strumento per gli sviluppatori
Non è un problema di API – ogni strumento che usiamo ha un'API di ricerca perfettamente funzionante. Il problema è più strano di così:
Forme di dati diverse. Slack restituisce messaggi con timestamp e ID di canale. Linear restituisce issue con stati ed etichette. GitHub restituisce commit, PR e corrispondenze di codice in formati di risposta completamente diversi. Unire tutto ciò in una cronologia coerente richiede una normalizzazione che nessuno si preoccupa di costruire (perché, onestamente, è il tipo di lavoro che non appare nelle demo degli sprint).
Frammentazione del contesto. Un messaggio Slack che dice "andiamo con l'opzione B" è privo di senso senza il thread che ha definito le opzioni A, B e C. Ma la ricerca di Slack restituisce messaggi singoli, non archi di conversazione. Trovi la conclusione senza il ragionamento.
Deriva temporale. Il processo decisionale si estende spesso per giorni o settimane, con lacune in cui non è successo nulla perché tutti erano concentrati su altri lavori. Una ricerca per parole chiave potrebbe far emergere l'inizio e la fine di una conversazione mancando la parte centrale cruciale, semplicemente perché parole diverse sono state usate in fasi diverse.
La ricerca multi-strumento per gli sviluppatori non è un problema di API – ogni strumento ha un endpoint di ricerca perfettamente funzionante. È un problema di contesto: le decisioni sono sparse tra gli strumenti in forme incompatibili, frammentate dagli archi di conversazione e separate dalla deriva temporale. La ricerca per parole chiave trova frammenti; solo il contesto connesso trova il quadro completo.
Costruire una ricerca multi-strumento con quello che hai
Ecco la parte pratica. Per tre o quattro strumenti con ricerca in sola lettura, aspettati mezza giornata per avere una versione MVP funzionante – la maggior parte del tempo spesa nella configurazione dell'autenticazione e nella normalizzazione delle risposte piuttosto che nella logica di ricerca vera e propria.
Configurare l'accesso API
Avrai bisogno di token per ogni strumento:
- Slack: Un token utente con scope
search:read (i metodi di ricerca di Slack richiedono token utente, non token bot – crea tramite la pagina delle app API Slack)
- Linear: Una chiave API personale da Impostazioni, poi API
- GitHub: Un PAT a granularità fine con accesso in lettura ai tuoi repository
- Notion: Un token di integrazione interno da Impostazioni, poi Connessioni
Lo script di query fan-out
Il pattern di base è imbarazzantemente semplice – inviare la stessa query di ricerca a ogni API e raccogliere i risultati:
```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()); } ```
Ogni funzione search* racchiude la rispettiva API. Per Slack, è search.messages. Per Linear, è una query GraphQL contro i loro campi di ricerca. Per GitHub, è l'endpoint di ricerca REST. Per Notion, è l'endpoint di ricerca con un parametro query.
Normalizzare e deduplicare
La parte complicata non è la ricerca – è rendere utili i risultati. Dovrai:
- Normalizzare i timestamp tra gli strumenti (Slack usa epoch Unix, Linear usa stringhe ISO, GitHub usa ISO con offset di fuso orario)
- Raggruppare i risultati correlati – se lo stesso thread Slack appare tre volte perché tre messaggi corrispondevano, collassarli in un unico risultato con l'URL del thread
- Classificare per rilevanza – la maggior parte delle API restituisce i propri punteggi di rilevanza, ma non sono comparabili tra gli strumenti. Una semplice euristica: le corrispondenze esatte di parole chiave nei titoli si classificano sopra le corrispondenze nel corpo, e i risultati più recenti si classificano sopra quelli più vecchi con pari rilevanza
Avvolgere in un CLI
Uso Commander.js per questo (soprattutto per abitudine, ma qualsiasi cosa funziona):
```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... ```
Quattordici risultati, ordinati per tempo, su quattro strumenti. Puoi vedere l'intero arco della decisione in un unico posto: il documento Notion è stato avviato per primo, poi è avvenuta la discussione su Slack, poi è stata creata la issue Linear per il tracciamento, e infine il PR è arrivato una settimana dopo.
Renderla davvero buona
La versione di base sopra funziona, ma ha alcuni angoli frustranti. Come migliorarla:
Espansione dei thread per Slack. Quando trovi un messaggio corrispondente, recupera l'intero thread con conversations.replies. Il messaggio corrispondente potrebbe essere "sì, andiamo con BullMQ" – non utile senza i 40 messaggi di dibattito precedenti. Mostra uno snippet del thread, non solo il messaggio corrispondente.
Commenti di revisione PR. L'API di ricerca di GitHub non fa emergere i commenti di revisione quando cerchi PR – avrai bisogno di una chiamata separata all'endpoint delle revisioni di pull request per recuperarli. È lì che vive la vera discussione tecnica.
Backlink. Quando trovi una issue Linear, controlla se qualche messaggio Slack contiene l'URL di quella issue. La ricerca di Slack supporta filtri has:link combinati con parole chiave. Questo fa emergere la discussione informale avvenuta attorno al tracciamento formale.
Caching. Se il tuo team genera molto contenuto (e quale team non lo fa), raggiungerai rapidamente i limiti di velocità. Metti in cache i risultati localmente con un TTL di 30 minuti – la maggior parte delle decisioni storiche non cambia così in fretta.
Quando la ricerca testuale si interrompe
Ecco dove sarò onesto sulle limitazioni. La ricerca per parole chiave tra gli strumenti ti porta sorprendentemente lontano, e poi sbatte contro un muro.
Il muro è questo: le decisioni si evolvono. Il thread Slack sulle "code di lavori" potrebbe non menzionare mai "BullMQ" per nome – invece, qualcuno ha condiviso un link, qualcun altro ha detto "mi piace l'opzione basata su Redis," e una terza persona ha detto "d'accordo, andiamo con quello." La tua ricerca di "BullMQ" manca l'intero thread perché la parola non è mai stata usata. Le persone nel thread sapevano cosa significava "l'opzione basata su Redis." La tua ricerca no.
Questo è fondamentalmente un problema di grafo, non di testo. Quello che vuoi davvero è: "mostrami tutto ciò che è connesso alla decisione che ha portato al PR #289." Ciò significa capire che il PR fa riferimento a una issue Linear, che è stata creata dopo una discussione su Slack, che è iniziata perché qualcuno aveva letto un documento Notion. Le connessioni sono implicite – gli esseri umani le hanno create copiando URL e dicendo "as discussed" – e una ricerca per parole chiave non può ricostruirle.
Puoi risolvere parzialmente questo seguendo i link. Analizza gli URL dai messaggi Slack, dalle descrizioni dei PR e dai commenti Linear. Costruisci una semplice lista di adiacenza: questo thread Slack si collega a questa issue Linear, che è referenziata in questo PR. Poi quando qualcuno cerca, puoi espandere i risultati per includere gli elementi collegati anche se non corrispondono alla parola chiave.
Quell'approccio a lista di adiacenza è essenzialmente un grafo della conoscenza rudimentale – ed è lì che vive il vero valore della ricerca multi-strumento per gli sviluppatori. Non nel trovare messaggi singoli, ma nel seguire il filo di una decisione attraverso ogni strumento che ha toccato. È meno "ricerca" e più gestione della conoscenza per sviluppatori – capire come le informazioni scorrono tra i tuoi strumenti in modo da poter ricostruire il contesto quando ne hai bisogno.
Il problema della manutenzione (e una scorciatoia)
L'approccio con script funziona brillantemente per circa tre mesi, e poi qualcuno cambia il workspace Slack, o Linear aggiorna il loro schema GraphQL, o aggiungi un nuovo strumento e nessuno ricorda di aggiornare lo script di ricerca. Ho costruito esattamente questa cosa due volte e l'ho abbandonata due volte (il che probabilmente dice più del mio impegno verso la manutenzione che dell'approccio stesso).
Se vuoi una ricerca multi-strumento per sviluppatori che rimanga aggiornata senza sorveglianza costante, è per questo che strumenti come Sugarbug sono stati costruiti – mantiene il grafo della conoscenza automaticamente e mantiene le connessioni vive man mano che i tuoi strumenti cambiano. Ma la versione DIY sopra è genuinamente utile se sei disposto a mantenerla.
Smetti di cercare in cinque strumenti separatamente. Sugarbug costruisce il grafo della conoscenza così puoi trovare qualsiasi decisione, discussione o commit in un unico posto.
Q: Come cerco contemporaneamente in più strumenti di sviluppo? A: Puoi costruire una ricerca multi-strumento leggera combinando l'API di ogni strumento – search.messages di Slack, issueSearch di Linear e l'endpoint di ricerca del codice di GitHub – in un unico script che distribuisce le query e unisce i risultati per timestamp. Gli esempi di codice sopra ti faranno iniziare in un pomeriggio. La sfida principale non è la ricerca in sé, ma normalizzare i diversi formati di risposta in una cronologia coerente.
Q: Sugarbug offre la ricerca multi-strumento per gli sviluppatori? A: Sì. Sugarbug acquisisce segnali da Linear, GitHub, Slack, Figma, Notion e altri strumenti in un grafo della conoscenza, così puoi cercare una decisione o una discussione e trovare ogni thread, issue e commit collegati in un unico posto. Gestisce la normalizzazione, la deduplicazione e il seguimento dei link automaticamente – le parti che rendono l'approccio DIY fragile nel tempo.
Q: Perché non riesco a trovare le decisioni architetturali nella mia codebase? A: Perché la maggior parte delle decisioni avviene in thread Slack, commenti Linear, documenti Notion e revisioni di PR – non nel codice stesso. Il codice registra il risultato di una decisione (la funzione esiste, la libreria è stata scelta), ma il ragionamento, i compromessi e le alternative discusse vivono sparsi tra i tuoi strumenti di comunicazione. Un git blame ti dice chi ha cambiato una riga e quando, ma non perché hanno scelto quell'approccio rispetto alle alternative.
Q: Sugarbug può sostituire i documenti ADR per il tracciamento delle decisioni? A: Sugarbug non sostituisce gli ADR, ma cattura le decisioni che non finiscono mai in un ADR. La maggior parte dei team scrive ADR per forse il 10% delle proprie scelte architetturali – il resto si dissolve in thread Slack e commenti di PR. Sugarbug li porta in superficie collegando le conversazioni alle modifiche del codice che hanno prodotto, così ottieni il tracciamento delle decisioni per l'altro 90% senza cambiare il flusso di lavoro di nessuno.