Home | Blog | Guide

Utafutaji wa Zana Nyingi: Msimbo si Mahali Pafaayo

Maamuzi mengi ya wasanidi programu yapo nje ya msimbo. Hivi ndivyo unavyojenga utafutaji kati ya Slack, Linear, GitHub, na Notion.

By Ellis Keane · 2026-03-17

Msimbo wako ni mahali pasipo na manufaa zaidi kutafuta kwa nini uamuzi ulifanywa.

Najua hilo linasikika kinyume chake. Tunatumia miaka kujifunza bendera za ripgrep, kusanidi utafutaji wa IDE, kukariri mifumo ya regex – na hakuna kinachosaidia wakati swali si "kazi hii iko wapi?" bali "kwa nini tulichagua mbinu hii badala ya njia tatu mbadala tulizozijadili?". Jibu la swali la pili karibu kamwe halipo kwenye msimbo. Lipo kwenye uzi wa Slack wa miezi minne iliyopita, kwenye maoni ya Linear yaliyozikwa chini ya masasisho ya hali, kwenye hati ya Notion ambayo mtu alianza na hakuwahi kuimaliza, na kwenye mapitio ya PR ambapo mjadala wa kweli ulifanyika katika jibu la jibu la jibu.

Hiyo ndiyo tatizo la utafutaji wa zana nyingi kwa wasanidi – muktadha wa maamuzi umegawanywa kati ya zana bila njia moja ya maswali. Tuna utafutaji unaofanya kazi vizuri ndani ya kila zana – utafutaji wa Slack ni wa kutosha, utafutaji wa msimbo wa GitHub ni bora, Linear ina vichujio kwa kila kitu – lakini hakuna kinachotafuta kwenye zote. Maamuzi yaliyounda usanifu wako yanaishi mahali tano tofauti, na unatarajiwa kukumbuka mahali pa kutazama.

Sawa, basi – hivi ndivyo unavyojenga utafutaji wa zana nyingi na unachokiwa nacho tayari. Hakuna zana mpya zinazohitajika (vizuri, karibu – nitataja moja mwishoni kabisa, lakini hii inafanya kazi bila yake).

Muundo wa Uamuzi Uliotawanyika

Niruhusu nipitie kitu maalum. Mwaka uliopita, tulikuwa tukiamua kama kutumia BullMQ au Temporal kwa foleni yetu ya kazi. Hapa ndipo uamuzi huo ulipoishi kweli kweli:

Slack (#engineering): Nyuzi tatu tofauti kwa siku mbili. Ya kwanza ilikuwa kiungo ambacho mtu alishiriki kwa chapisho la blogu la Temporal. Ya pili ilikuwa mjadala kuhusu kama tulihitaji utekelezaji wa kudumu. Ya tatu (wiki moja baadaye, kituo tofauti) ilikuwa mtu akiuliza "subiri, tuliamulia foleni hiyo?".
Linear: Suala lenye kichwa "Tathmini chaguzi za foleni ya kazi" na maoni sita, ikiwa ni pamoja na jedwali la kulinganisha ambalo mmoja wa wahandisi wetu alitumia mchana mzima kuandika.
GitHub: Maelezo ya PR kwa utekelezaji wa BullMQ yalisema "kama ilivyojadiliwa" bila viungo hata kimoja kwa mahali ilipojadiliwa.
Notion: Rekodi ya uamuzi wa usanifu iliyokamilika nusu iliyoshughulikia faida za Temporal lakini haikuwahi kusasishwa na uchaguzi wa mwisho.
Google Docs: Kumbukumbu za mkutano kutoka kwa simu ambapo tulipofanya uamuzi halisi, zimezikwa kwenye nukta za orodha kati ya vipengele viwili visivyohusiana vya ajenda.

Zana tano. Uamuzi mmoja. Na kama ungekuwa umetafuta zana moja yoyote, ungeipata kipande – kamwe si picha nzima. PR inakuambia tulichochagua. Nyuzi za Slack zinakuambia tuliyoyafikiri. Suala la Linear linakuambia maelewano. Hati ya Notion inakuambia nusu ya mantiki. Kumbukumbu za mkutano zinakuambia wakati ilipomalizika.

Hii si ya kawaida. Hii ni, kwa njia fulani, hali ya sanaa ya jinsi timu za uhandisi zinavyofuatilia maamuzi mwaka 2026. Tuna AI inayotengeneza msimbo na injini za utafutaji zinazoorodhesha mtandao wote, lakini kugundua kwa nini timu yako ilichagua BullMQ badala ya Temporal kunahitaji kuangalia programu tano na kutumainia kwamba kumbukumbu ya mtu itashikilia.

Kinachofanya Utafutaji wa Zana Nyingi Kuwa Mgumu kwa Wasanidi

Si tatizo la API – kila zana tunayotumia ina API ya utafutaji nzuri kabisa. Tatizo ni la ajabu zaidi:

Umbo tofauti la data. Slack inarudisha ujumbe wenye alama za wakati na vitambulisho vya kituo. Linear inarudisha masuala yenye hali na lebo. GitHub inarudisha ahadi, PR, na mechi za msimbo katika muundo tofauti kabisa wa majibu. Kuunganisha hizi katika ratiba thabiti kunahitaji uratibu ambao hakuna anayejisumbua kuijenga (kwa sababu, kwa uaminifu, ni aina ya kazi ambayo haionekani kwenye maonyesho ya sprint).

Ugawanyifu wa muktadha. Ujumbe wa Slack usemao "tuende na chaguo B" hauna maana bila uzi ulioainisha chaguzi A, B, na C. Lakini utafutaji wa Slack inarudisha ujumbe mmoja mmoja, si mikunjo ya mazungumzo. Unapata hitimisho bila mantiki.

Mwelekeo wa wakati. Mchakato wa uamuzi mara nyingi huchukua siku au wiki, na mapumziko ambapo hakuna kilichotokea kwa sababu kila mtu alikuwa amezama kwenye kazi nyingine. Utafutaji wa neno kuu unaweza kuleta mwanzo na mwisho wa mazungumzo huku ukikosa katikati muhimu, tu kwa sababu maneno tofauti yalitumiwa katika hatua tofauti.

Utafutaji wa zana nyingi kwa wasanidi si tatizo la API – kila zana ina endpoint ya utafutaji nzuri kabisa. Ni tatizo la muktadha: maamuzi yametawanyika kwenye zana katika muundo usiooana, yamegawanywa na mikunjo ya mazungumzo, na kutenganishwa na mwelekeo wa wakati. Utafutaji wa neno kuu hupata vipande; muktadha uliounganishwa peke yake hupata picha nzima.

Kujenga Utafutaji wa Zana Nyingi na Unachokiwa Nacho

Hapa ndipo sehemu ya vitendo. Kwa zana tatu au nne zenye utafutaji wa kusoma tu, tarajia nusu siku kupata MVP inayofanya kazi – nyingi ya hilo ikitumika kwenye usanidi wa uthibitishaji na uratibu wa majibu badala ya mantiki ya utafutaji yenyewe.

Sanidi Ufikiaji wa API

Utahitaji tokeni kwa kila zana:

Slack: Tokeni ya mtumiaji yenye wigo wa search:read (mbinu za utafutaji za Slack zinahitaji tokeni za mtumiaji, si tokeni za boti – unda kupitia ukurasa wa programu za Slack API)
Linear: Ufunguo wa API wa kibinafsi kutoka Mipangilio, kisha API
GitHub: PAT yenye kina na ufikiaji wa kusoma kwenye hazina zako
Notion: Tokeni ya muunganisho wa ndani kutoka Mipangilio, kisha Miunganisho

Hati ya Maswali ya Mashabiki

Mfumo wa msingi ni rahisi kiasi cha kutia aibu – tuma swali moja la utafutaji kwa kila API na kukusanya matokeo:

```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()); } ```

Kila kazi ya search* hufunika API husika. Kwa Slack, hiyo ni search.messages. Kwa Linear, ni swali la GraphQL dhidi ya sehemu za utafutaji. Kwa GitHub, ni endpoint ya utafutaji wa REST. Kwa Notion, ni endpoint ya utafutaji yenye kigezo cha query.

Ratibu na Ondoa Nakala

Sehemu ngumu si utafutaji – ni kufanya matokeo kuwa ya manufaa. Utataka:

Ratibu alama za wakati kati ya zana (Slack hutumia enzi za Unix, Linear hutumia mifuatano ya ISO, GitHub hutumia ISO yenye vipengele vya eneo la saa)
Panga matokeo yanayohusiana – ikiwa uzi ule ule wa Slack unaonekana mara tatu kwa sababu ujumbe mitatu ulilingana, ufikie matokeo moja yenye URL ya uzi
Panga kwa umuhimu – API nyingi zinarudisha alama zao za umuhimu, lakini haziwezi kulinganishwa kati ya zana. Heuristic rahisi: mechi kamili za neno kuu kwenye vichwa hupangwa juu ya mechi za mwili, na matokeo mapya zaidi hupangwa juu ya ya zamani kwa umuhimu sawa

Funika katika CLI

Natumia Commander.js kwa hili (hasa kwa mazoea, lakini chochote kitafanya kazi):

```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... ```

Matokeo kumi na manne, yamepangwa kwa wakati, kutoka zana nne. Unaweza kuona mkondo mzima wa uamuzi mahali pamoja: hati ya Notion ilianzishwa kwanza, kisha mjadala wa Slack ulitokea, kisha suala la Linear liliundwa kwa ajili ya ufuatiliaji, na hatimaye wiki moja baadaye PR ilifika.

Kuifanya Bora Kweli Kweli

Toleo la msingi hapo juu linafanya kazi, lakini lina baadhi ya makingo yanayokasirisha. Hivi ndivyo unavyoweza kuiboresha:

Upanuzi wa uzi wa Slack. Unapopata ujumbe unaofanana, pata uzi mzima na conversations.replies. Ujumbe unaofanana unaweza kuwa "ndiyo, tuende na BullMQ" – hauna manufaa bila ujumbe 40 wa awali wa mjadala. Onyesha kipande cha uzi, si ujumbe unaofanana tu.

Maoni ya mapitio ya PR. API ya utafutaji ya GitHub haionyeshi maoni ya mapitio unapotafuta PR – utahitaji wito tofauti kwa endpoint ya mapitio ya ombi la kuvuta ili kuyapata. Hapo ndipo mjadala wa kweli wa kiufundi unaishi.

Viungo vya nyuma. Unapopata suala la Linear, angalia kama ujumbe wowote wa Slack una URL ya suala hilo. Utafutaji wa Slack unasaidia vichujio vya has:link vikijumuishwa na maneno makuu. Hii hualibua mjadala wa kawaida uliofanyika karibu na ufuatiliaji rasmi.

Hifadhi ya akiba. Kama timu yako inazalisha maudhui mengi (na ya nani haizalishi?), utafikia haraka mipaka ya kiwango. Hifadhi matokeo ndani ya kompyuta yenye TTL ya dakika 30 – maamuzi mengi ya kihistoria hayabadiliki hivyo haraka.

Utafutaji wa Maandishi Unaposimama

Hapa nitakuwa mkweli kuhusu mipaka. Utafutaji wa neno kuu kati ya zana hufanya kazi kwa mbali ya ajabu, kisha hufikia ukuta.

Ukuta huu ni huu: maamuzi hubadilika. Uzi wa Slack kuhusu "foleni za kazi" unaweza kamwe kutaja "BullMQ" kwa jina – badala yake, mtu alishiriki kiungo, mtu mwingine alisema "ninapenda chaguo linaloungwa na Redis", na mtu wa tatu alisema "nakubaliana, tuende nacho." Utafutaji wako wa "BullMQ" unakosa uzi mzima kwa sababu neno hilo halikutumika kamwe. Watu katika uzi walijua "chaguo linaloungwa na Redis" kulimaanisha nini. Utafutaji wako haujui.

Hii ni tatizo la grafu kwa msingi, si tatizo la maandishi. Unachohitaji kweli kweli ni: "nionyeshe kila kitu kilichounganishwa na uamuzi uliosababisha PR #289." Hiyo inamaanisha kuelewa kwamba PR inarejelea suala la Linear, ambalo liliundwa baada ya mjadala wa Slack, ambao ulianzishwa kwa sababu mtu alisoma hati ya Notion. Miunganisho ni ya wazi – wanadamu waliifanya kwa kunakili URL na kusema "kama ilivyojadiliwa" – na utafutaji wa neno kuu hauwezi kuizalisha upya.

Unaweza kutatua hili kwa sehemu kwa kufuata viungo. Changanua URL kutoka ujumbe wa Slack, maelezo ya PR, na maoni ya Linear. Jenga orodha rahisi ya jirani: uzi huu wa Slack unaunganisha na suala hili la Linear, ambalo linarejelewa katika PR hii. Kisha mtu anapotafuta, unaweza kupanua matokeo ili kujumuisha vitu vilivyounganishwa hata kama havifanani na neno kuu.

Mbinu hiyo ya orodha ya jirani ni kimsingi grafu ya maarifa ya awali – na hapo ndipo thamani halisi ya utafutaji wa zana nyingi kwa wasanidi inaishi. Si katika kupata ujumbe mmoja mmoja, bali katika kufuata uzi wa uamuzi kote kwenye kila zana iliyoguswa. Ni zaidi ya "usimamizi wa maarifa kwa wasanidi" kuliko "utafutaji" – kuelewa jinsi taarifa inavyotiririka kati ya zana zako ili uweze kujenga upya muktadha unapohitajika.

Tatizo la Matengenezo (na Mkato)

Mbinu ya hati inafanya kazi vizuri kwa miezi mitatu, kisha mtu hubadilisha nafasi ya kazi ya Slack, au Linear husasisha mpango wake wa GraphQL, au unaongeza zana mpya na hakuna anayekumbuka kusasisha hati ya utafutaji. Nimejenga hili sawasawa mara mbili na kuliachana mara mbili (ambayo labda inasema zaidi kuhusu kujitolea kwangu kwa matengenezo kuliko kuhusu mbinu yenyewe).

Kama unataka utafutaji wa zana nyingi kwa wasanidi ambao unabaki wa kisasa bila kulindwa, ndivyo zana kama Sugarbug zinavyojengwa – hudumisha grafu ya maarifa kiotomatiki na kuweka miunganisho hai zana zako zinapobadilika. Lakini toleo la DIY hapo juu ni la manufaa kweli kweli ikiwa uko tayari kulidumisha.

Acha kutafuta kwenye zana tano tofauti. Sugarbug hujenga grafu ya maarifa ili uweze kupata uamuzi wowote, mjadala, au ahadi mahali pamoja.

Q: Ninawezaje kutafuta kwenye zana nyingi za wasanidi mara moja? A: Unaweza kujenga utafutaji mwepesi wa zana nyingi kwa kuchanganya API ya kila zana – search.messages ya Slack, issueSearch ya Linear, na endpoint ya utafutaji wa msimbo wa GitHub – katika hati moja inayotuma maswali na kuchanganya matokeo kwa alama ya wakati. Mifano ya msimbo hapo juu itakusaidia kuanza katika mchana mmoja. Changamoto kuu si utafutaji wenyewe bali kuunganisha muundo tofauti wa majibu katika ratiba thabiti.

Q: Je, Sugarbug hutoa utafutaji wa zana nyingi kwa wasanidi? A: Ndiyo. Sugarbug hukusanya ishara kutoka Linear, GitHub, Slack, Figma, Notion na zana nyingine kwenye grafu ya maarifa, ili uweze kutafuta uamuzi au majadiliano na kupata kila uzi, suala, na ahadi iliyounganishwa mahali pamoja. Hushughulikia uratibu, uondoaji wa nakala, na ufuatiliaji wa viungo kiotomatiki – sehemu zinazofanya mbinu ya DIY kuwa dhaifu baada ya muda.

Q: Kwa nini siwezi kupata maamuzi ya usanifu kwenye msimbo wangu? A: Kwa sababu maamuzi mengi hufanyika kwenye nyuzi za Slack, maoni ya Linear, hati za Notion, na mapitio ya PR – si kwenye msimbo wenyewe. Msimbo hurekodi matokeo ya uamuzi (kazi ipo, maktaba ilichaguliwa), lakini mantiki, maelewano, na njia mbadala zilizojadiliwa zimetawanyika kwenye zana za mawasiliano. git blame inakuambia nani alibadilisha mstari na lini, lakini si kwa nini walichagua mbinu hiyo badala ya njia mbadala.

Q: Je, Sugarbug inaweza kubadilisha hati za ADR kwa ajili ya kufuatilia maamuzi? A: Sugarbug haibadilishi ADR, lakini hunasa maamuzi ambayo hayawahi kufikia ADR. Timu nyingi huandika ADR kwa takriban 10% ya maamuzi yao ya usanifu – mengine huyeyuka kwenye nyuzi za Slack na maoni ya PR. Sugarbug huyaibua kwa kuunganisha mazungumzo na mabadiliko ya msimbo yaliyotokana nayo, ili upate ufuatiliaji wa maamuzi kwa asilimia 90 iliyobaki bila kubadilisha mtiririko wa kazi wa mtu yeyote.