ডেভেলপারদের জন্য ক্রস-টুল সার্চ: তোমার কোডবেস ভুল জায়গা
বেশিরভাগ ডেভেলপার decision কোডের বাইরে থাকে। Slack, Linear, GitHub, আর Notion জুড়ে ক্রস-টুল সার্চ কীভাবে বানাবে, এখানে আছে।
By Chris Calo · 2026-03-17
তোমার কোডবেস হলো কোনো decision কেন নেওয়া হয়েছিল সেটা খোঁজার সবচেয়ে অকেজো জায়গা।
জানি, শুনতে উল্টো লাগছে। আমরা বছরের পর বছর ripgrep flag শিখি, IDE search configure করি, regex pattern মুখস্থ করি – আর কোনোটাই কাজে আসে না যখন প্রশ্ন "এই function কোথায়?" না, বরং "তিনটা alternative নিয়ে আলোচনা করে কেন আমরা এই approach বেছেছিলাম?" দ্বিতীয় প্রশ্নের উত্তর প্রায় কখনোই কোডে থাকে না। থাকে চার মাস আগের Slack thread-এ, status update-এর নিচে চাপা পড়া Linear comment-এ, কেউ শুরু করে শেষ করেনি এমন Notion doc-এ, আর PR review-তে যেখানে আসল তর্ক হয়েছিল reply-র reply-র reply-তে।
এটাই ডেভেলপারদের জন্য ক্রস-টুল সার্চ সমস্যা – decision context একাধিক টুলে ভাগ হয়ে আছে, কোনো unified query path নেই। প্রতিটা টুলের মধ্যে সার্চ ভালো কাজ করে – Slack-এর search decent, GitHub-এর code search excellent, Linear-এর সবকিছুর জন্য filter আছে – কিন্তু টুল জুড়ে সার্চ করার কিছু নেই। তোমার architecture shape দেওয়া decision পাঁচটা আলাদা জায়গায় থাকে, আর তোমার মনে রাখতে হয় কোন জায়গায় খুঁজতে হবে। This is also the foundation of cross-tool project visibility: knowing where work is happening means knowing where decisions were made, not just where tickets sit.
ঠিক আছে, তাহলে – তোমার কাছে যা আছে তা দিয়ে ক্রস-টুল সার্চ কীভাবে বানাবে সেটা বলি। নতুন টুল লাগবে না (ভালো, প্রায় – একদম শেষে একটা mention করব, কিন্তু ছাড়াই চলবে)।
একটা ছড়িয়ে পড়া Decision-এর Anatomy
নির্দিষ্ট কিছু দিয়ে বুঝিয়ে দিই। গত বছর, আমরা ঠিক করছিলাম job queue-র জন্য BullMQ না Temporal ব্যবহার করব। সেই decision আসলে কোথায় ছিল:
- Slack (#engineering): দুই দিনে তিনটা আলাদা thread। প্রথমটায় কেউ Temporal blog post-এর link share করেছিল। দ্বিতীয়টায় durable execution লাগবে কি না নিয়ে তর্ক। তৃতীয়টায় (এক সপ্তাহ পর, অন্য channel) কেউ জিজ্ঞেস করছে "wait, queue-এর ব্যাপারে কি আমরা ঠিক করলাম?"
- Linear: "Evaluate job queue options" নামে issue, ছয়টা comment সহ, যার মধ্যে আমাদের এক engineer একটা বিকেল খরচ করে বানানো comparison table।
- GitHub: BullMQ implementation-এর PR description-এ লেখা "as discussed" – কোথায় discuss হয়েছিল তার zero link।
- Notion: একটা অসম্পূর্ণ architecture decision record যা Temporal-এর pros কভার করেছে কিন্তু final choice দিয়ে update হয়নি।
- Google Docs: যে call-এ আসলে decision নেওয়া হয়েছিল তার meeting notes, দুটো unrelated agenda item-এর মাঝে bullet point-এ চাপা পড়ে।
পাঁচটা টুল। একটা decision। যেকোনো একটা টুলে সার্চ করলে fragment পেতে – পুরো ছবি কখনও না। PR বলে আমরা কী choose করেছি। Slack thread বলে কী consider করেছি। Linear issue বলে trade-off। Notion doc বলে reasoning-এর অর্ধেক। Meeting notes বলে যে মুহূর্তে finalise হয়েছিল।
এটা অস্বাভাবিক না। ২০২৬ সালে engineering team কীভাবে decision track করে, এটাই কোনোভাবে state of the art। আমাদের AI আছে যেটা কোড generate করে আর search engine আছে যেটা পুরো internet index করে, কিন্তু তোমার টিম Temporal-এর বদলে BullMQ কেন choose করল সেটা জানতে পাঁচটা app চেক করতে হয় আর আশা করতে হয় কারও memory ধরে রাখে।
কেন ডেভেলপারদের জন্য ক্রস-টুল সার্চ কঠিন
এটা API সমস্যা না – আমরা যেসব টুল ব্যবহার করি সবারই চমৎকার search API আছে। সমস্যা এর চেয়ে অদ্ভুত:
ভিন্ন data shape। Slack return করে message, timestamp আর channel ID সহ। Linear return করে issue, state আর label সহ। GitHub return করে commit, PR, আর code match সম্পূর্ণ ভিন্ন response format-এ। এগুলো একটা coherent timeline-এ merge করতে normalisation লাগে যা কেউ বানাতে বসে না (কারণ সত্যি বলতে, এই কাজ sprint demo-তে দেখানো যায় না)।
Context fragmentation। "Let's go with option B" বলা Slack message, option A, B, আর C define করা thread ছাড়া meaningless। কিন্তু Slack-এর search individual message return করে, conversation arc না। তুমি conclusion পাও reasoning ছাড়া।
Temporal drift। Decision process প্রায়ই দিন বা সপ্তাহ ধরে চলে, মাঝে gap থাকে যখন সবাই অন্য কাজে ব্যস্ত। Keyword search conversation-এর শুরু আর শেষ surface করতে পারে কিন্তু গুরুত্বপূর্ণ মাঝখান মিস করতে পারে, শুধু কারণ ভিন্ন পর্যায়ে ভিন্ন শব্দ ব্যবহার হয়েছে।
ডেভেলপারদের জন্য ক্রস-টুল সার্চ API সমস্যা না – প্রতিটা টুলের চমৎকার search endpoint আছে। এটা context সমস্যা: decision একাধিক টুলে incompatible shape-এ ছড়িয়ে, conversation arc-এ খণ্ডিত, আর temporal drift দ্বারা আলাদা। Keyword search fragment খোঁজে; শুধু connected context পুরো ছবি খোঁজে।
তোমার কাছে যা আছে তা দিয়ে ক্রস-টুল সার্চ বানানো
এবার practical অংশ। তিন-চারটা টুলের read-only search-এর জন্য MVP বানাতে আধা দিন লাগবে – বেশিরভাগ সময় যাবে auth setup আর response normalisation-এ, search logic-এ না।
API Access Setup
প্রতিটা টুলের জন্য token লাগবে:
- Slack:
search:read scope-এর user token (Slack-এর search method-এ user token লাগে, bot token না – Slack API apps page থেকে বানাও)
- Linear: Settings, তারপর API থেকে personal API key
- GitHub: তোমার repo-তে read access সহ fine-grained PAT
- Notion: Settings, তারপর Connections থেকে internal integration token
Fan-out Query Script
Basic pattern বিব্রতকরভাবে সহজ – একই search query প্রতিটা API-তে fire করো আর result collect করো:
```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()); } ```
প্রতিটা search* function সংশ্লিষ্ট API wrap করে। Slack-এর জন্য search.messages। Linear-এর জন্য তাদের search field-এ GraphQL query। GitHub-এর জন্য REST search endpoint। Notion-এর জন্য query parameter সহ search endpoint।
Normalise আর Deduplicate
কঠিন অংশ search না – result useful করা। তোমাকে করতে হবে:
- টুল জুড়ে timestamp normalise (Slack Unix epoch ব্যবহার করে, Linear ISO string, GitHub timezone offset সহ ISO)
- সম্পর্কিত result group করা – একই Slack thread তিনবার আসলে (কারণ তিনটা message match করেছে), thread URL দিয়ে একটাতে collapse করো
- Relevance অনুযায়ী rank করা – বেশিরভাগ API নিজস্ব relevance score return করে, কিন্তু টুল জুড়ে তুলনীয় না। সহজ heuristic: title-এ exact keyword match body match-এর ওপরে rank করো, আর সমান relevance-এ নতুন result পুরোনোর ওপরে
CLI-তে Wrap করো
আমি এর জন্য Commander.js ব্যবহার করি (বেশিরভাগ অভ্যাসবশত, কিন্তু যেকোনো কিছু চলবে):
```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... ```
চৌদ্দটা result, সময় অনুযায়ী সাজানো, চারটা টুল থেকে। Decision-এর পুরো arc এক জায়গায় দেখতে পাও: Notion doc আগে শুরু হয়েছিল, তারপর Slack আলোচনা, তারপর tracking-এর জন্য Linear issue, আর অবশেষে এক সপ্তাহ পর PR land করেছে।
এটাকে আসলে ভালো করা
উপরের basic version কাজ করে, কিন্তু কিছু frustrating edge আছে। কীভাবে improve করবে:
Slack-এর জন্য thread expansion। Matching message পেলে conversations.replies দিয়ে পুরো thread fetch করো। Matching message হয়তো "yeah, let's go with BullMQ" – আগের ৪০টা debate message ছাড়া useless। Thread-এর snippet দেখাও, শুধু matching message না।
PR review comment। GitHub-এর search API PR search করলে review comment surface করে না – সেগুলো fetch করতে pull request reviews endpoint-এ আলাদা call লাগবে। আসল technical আলোচনা ওখানেই থাকে।
Backlink। Linear issue পেলে check করো কোনো Slack message-এ সেই issue-র URL আছে কি না। Slack-এর search keyword-এর সাথে has:link filter support করে। এটা formal tracking-এর চারপাশে informal আলোচনা surface করে।
Caching। তোমার টিম যদি অনেক content generate করে (আর কার করে না), rate limit-এ তাড়াতাড়ি আটকাবে। ৩০ মিনিটের TTL দিয়ে locally cache করো – historical decision এত দ্রুত বদলায় না।
যখন Text Search কাজ করে না
এবার limitation নিয়ে সৎ থাকি। টুল জুড়ে keyword search অবাক করার মতো দূর পর্যন্ত নিয়ে যায়, তারপর দেয়ালে ধাক্কা খায়।
দেয়ালটা এটা: decision evolve করে। "Job queues" নিয়ে Slack thread-এ হয়তো "BullMQ" নামটা কখনো আসেনি – বরং কেউ link share করেছে, আরেকজন বলেছে "I like the Redis-backed option," তৃতীয়জন বলেছে "agreed, let's go with that।" তোমার "BullMQ" সার্চ পুরো thread মিস করে কারণ শব্দটা কখনো ব্যবহার হয়নি। Thread-এর মানুষরা জানত "the Redis-backed option" মানে কী। তোমার সার্চ জানে না।
এটা মৌলিকভাবে graph সমস্যা, text সমস্যা না। তুমি আসলে চাও: "PR #289-এর দিকে নিয়ে যাওয়া decision-এর সাথে connected সবকিছু দেখাও।" মানে বুঝতে হবে PR একটা Linear issue reference করে, যেটা তৈরি হয়েছিল Slack আলোচনার পর, যেটা শুরু হয়েছিল কেউ Notion doc পড়ে। Connection implicit – মানুষ URL copy করে আর "as discussed" বলে এগুলো বানিয়েছে – আর keyword search এগুলো reconstruct করতে পারে না।
তুমি আংশিকভাবে link follow করে এটা সমাধান করতে পারো। Slack message, PR description, আর Linear comment থেকে URL parse করো। সহজ adjacency list বানাও: এই Slack thread এই Linear issue-তে link করে, যেটা এই PR-এ reference আছে। তারপর কেউ সার্চ করলে keyword match না করলেও linked item include করে result expand করতে পারো।
সেই adjacency-list approach আসলে একটা rudimentary নলেজ গ্রাফ – আর ডেভেলপারদের জন্য ক্রস-টুল সার্চের আসল value এখানেই। Individual message খোঁজায় না, বরং decision-এর thread follow করায় প্রতিটা টুল জুড়ে। এটা কম "search" আর বেশি developer knowledge management – তোমার টুলের মধ্যে information কীভাবে flow করে বোঝা, যাতে দরকার পড়লে context reconstruct করতে পারো। That’s the same problem as the cross-tool decision trail from Slack through Linear to GitHub: you need the full chain, not just whichever fragment the right keyword happened to surface. And it’s inseparable from tracking work without losing context between platforms – decisions and tasks are two sides of the same cross-tool visibility coin.
Maintenance সমস্যা (আর একটা Shortcut)
Script approach তিন মাস দারুণ কাজ করে, তারপর কেউ Slack workspace বদলায়, বা Linear তাদের GraphQL schema update করে, বা তুমি নতুন টুল add করো আর কেউ search script update করতে মনে রাখে না। আমি ঠিক এটাই দুবার বানিয়েছি আর দুবার ফেলে দিয়েছি (যেটা approach-এর চেয়ে maintenance-এ আমার commitment সম্পর্কে বেশি বলে)।
তুমি যদি babysitting ছাড়া current থাকা ডেভেলপারদের জন্য ক্রস-টুল সার্চ চাও, Sugarbug-এর মতো টুল এর জন্যই বানানো – এটা নলেজ গ্রাফ স্বয়ংক্রিয়ভাবে maintain করে আর তোমার টুল বদলালেও connection জীবিত রাখে। কিন্তু ওপরের DIY version maintain করতে রাজি থাকলে সত্যিই useful।
পাঁচটা টুলে আলাদাভাবে সার্চ করা বন্ধ করো। Sugarbug নলেজ গ্রাফ বানায় যাতে যেকোনো decision, আলোচনা, বা commit এক জায়গায় খুঁজে পাও।
Q: একসাথে একাধিক ডেভেলপার টুলে কীভাবে সার্চ করব? A: প্রতিটা টুলের API – Slack-এর search.messages, Linear-এর issueSearch, আর GitHub-এর code search endpoint – একটা single script-এ combine করে lightweight ক্রস-টুল সার্চ বানাতে পারো যেটা query fan-out করে আর timestamp অনুযায়ী result merge করে। উপরের code sample দিয়ে এক বিকেলে শুরু করতে পারবে। মূল চ্যালেঞ্জ search নিজে না, বরং ভিন্ন response format-কে coherent timeline-এ normalise করা।
Q: Sugarbug কি ডেভেলপারদের জন্য ক্রস-টুল সার্চ দেয়? A: হ্যাঁ। Sugarbug Linear, GitHub, Slack, Figma, Notion সহ অন্যান্য টুল থেকে সিগন্যাল একটা নলেজ গ্রাফে ingest করে, তাই decision বা আলোচনা সার্চ করলে সংশ্লিষ্ট সব thread, issue, আর commit এক জায়গায় পাবে। Normalisation, deduplication, আর link-following স্বয়ংক্রিয়ভাবে handle করে – যে অংশগুলো DIY approach-কে সময়ের সাথে fragile করে তোলে।
Q: আমার কোডবেসে architecture decision কেন খুঁজে পাই না? A: কারণ বেশিরভাগ decision হয় Slack thread, Linear comment, Notion doc, আর PR review-তে – কোডে না। কোড decision-এর outcome record করে (function আছে, library choose হয়েছে), কিন্তু reasoning, trade-off, আর আলোচিত alternative তোমার communication tool জুড়ে ছড়িয়ে থাকে। git blame বলে কে কখন line বদলেছে, কিন্তু alternative-এর বদলে কেন এই approach choose হলো সেটা বলে না।
Q: Sugarbug কি ADR document-এর বিকল্প হতে পারে? A: Sugarbug ADR replace করে না, তবে যেসব decision কখনও ADR-এ পৌঁছায় না সেগুলো ধরে। বেশিরভাগ টিম তাদের architectural choice-এর মাত্র ১০% ADR লেখে – বাকিগুলো Slack thread আর PR comment-এ মিলিয়ে যায়। Sugarbug conversation-কে তারা যে code change তৈরি করেছে তার সাথে connect করে, ফলে কারও ওয়ার্কফ্লো না বদলেই বাকি ৯০%-এর decision tracking পাও।