ค้นหาข้ามเครื่องมือสำหรับนักพัฒนา: โค้ดเบสผิดที่
การตัดสินใจส่วนใหญ่ของนักพัฒนาอยู่นอกโค้ด นี่คือวิธีสร้างการค้นหาข้ามเครื่องมือผ่าน Slack, Linear, GitHub และ Notion
By Ellis Keane · 2026-03-17
โค้ดเบสของคุณคือสถานที่ที่มีประโยชน์น้อยที่สุดในการค้นหาว่าทำไมถึงตัดสินใจเช่นนั้น
ฉันรู้ว่าฟังดูย้อนแย้ง เราใช้เวลาหลายปีเรียนรู้ flag ของ ripgrep ตั้งค่าการค้นหาใน IDE ท่องจำรูปแบบ regex – และไม่มีสิ่งใดช่วยได้เมื่อคำถามไม่ใช่ "ฟังก์ชันนี้อยู่ที่ไหน?" แต่ "ทำไมเราถึงเลือกวิธีนี้แทนสามทางเลือกที่เราได้อภิปรายกัน?" คำตอบของคำถามที่สองนั้นแทบไม่เคยอยู่ในโค้ดเลย มันอยู่ในเธรด Slack เมื่อสี่เดือนที่แล้ว ความคิดเห็นใน Linear ที่ถูกฝังอยู่ใต้การอัปเดตสถานะ เอกสาร Notion ที่มีคนเริ่มเขียนแต่ไม่เคยเสร็จ และการรีวิว PR ที่การถกเถียงจริง ๆ เกิดขึ้นในการตอบกลับของการตอบกลับของการตอบกลับ
นั่นคือปัญหาการค้นหาข้ามเครื่องมือสำหรับนักพัฒนา – บริบทการตัดสินใจกระจายอยู่ตามเครื่องมือต่าง ๆ โดยไม่มีเส้นทางการค้นหาแบบรวมศูนย์ เรามีการค้นหาที่ทำงานได้ดีภายในแต่ละเครื่องมือ – การค้นหาของ Slack ก็ใช้ได้ การค้นหาโค้ดของ GitHub ยอดเยี่ยมมาก Linear มี filter สำหรับทุกอย่าง – แต่ไม่มีอะไรที่ค้นหาข้ามเครื่องมือเหล่านั้น การตัดสินใจที่กำหนดสถาปัตยกรรมของคุณอยู่ในห้าสถานที่ต่างกัน และคุณต้องจำได้ว่าควรหาที่ไหน
เอาล่ะ – นี่คือวิธีสร้างการค้นหาข้ามเครื่องมือด้วยสิ่งที่คุณมีอยู่แล้ว ไม่ต้องใช้เครื่องมือใหม่ (ก็เกือบ – ฉันจะกล่าวถึงหนึ่งตัวในตอนท้าย แต่สิ่งนี้ทำงานได้โดยไม่มีมัน)
กายวิภาคของการตัดสินใจที่กระจัดกระจาย
ขอยกตัวอย่างที่เฉพาะเจาะจง เมื่อปีที่แล้ว เราตัดสินใจว่าจะใช้ BullMQ หรือ Temporal สำหรับ job queue นี่คือที่ที่การตัดสินใจนั้นอยู่จริง ๆ:
- Slack (#engineering): สามเธรดแยกกันในสองวัน เธรดแรกเป็นลิงก์ที่มีคนแชร์ไปยังโพสต์บล็อกของ Temporal เธรดที่สองเป็นการถกเถียงว่าเราต้องการ durable execution ไหม เธรดที่สาม (หนึ่งสัปดาห์ต่อมา ช่องต่างกัน) เป็นคนถามว่า "เดี๋ยว เราตัดสินใจเรื่อง queue แล้วหรือยัง?"
- Linear: อิชชูชื่อ "ประเมินตัวเลือก job queue" พร้อมหกความคิดเห็น รวมถึงตารางเปรียบเทียบที่วิศวกรคนหนึ่งของเราใช้เวลาครึ่งวันเขียน
- GitHub: คำอธิบาย PR สำหรับการ implement BullMQ ที่บอกว่า "as discussed" โดยไม่มีลิงก์ไปยังที่ที่อภิปรายกัน
- Notion: บันทึกการตัดสินใจด้านสถาปัตยกรรมที่ทำเสร็จครึ่งเดียว ครอบคลุมข้อดีของ Temporal แต่ไม่เคยอัปเดตด้วยการเลือกขั้นสุดท้าย
- Google Docs: บันทึกการประชุมจากการโทรที่เราตัดสินใจจริง ๆ ฝังอยู่ในหัวข้อย่อยระหว่างสองรายการวาระที่ไม่เกี่ยวข้องกัน
ห้าเครื่องมือ การตัดสินใจหนึ่งครั้ง และถ้าคุณค้นหาในเครื่องมือใดเครื่องมือหนึ่ง คุณจะพบเพียงส่วนหนึ่ง – ไม่มีทางได้ภาพรวมทั้งหมด PR บอกคุณว่าเราเลือกอะไร เธรด Slack บอกว่าเราพิจารณาอะไรบ้าง อิชชู Linear บอกข้อดีข้อเสีย เอกสาร Notion บอกเหตุผลครึ่งหนึ่ง บันทึกการประชุมบอกช่วงเวลาที่ตัดสินใจขั้นสุดท้าย
สิ่งนี้ไม่ใช่เรื่องผิดปกติ นี่คือสถานะของศิลปะในการที่ทีม engineering ติดตามการตัดสินใจในปี 2026 เรามี AI ที่สร้างโค้ดและเครื่องมือค้นหาที่จัดทำดัชนีอินเทอร์เน็ตทั้งหมด แต่การค้นหาว่าทำไมทีมของคุณถึงเลือก BullMQ แทน Temporal ต้องตรวจสอบห้าแอปและหวังว่าความทรงจำของใครสักคนจะยังดีอยู่
สิ่งที่ทำให้การค้นหาข้ามเครื่องมือสำหรับนักพัฒนาเป็นเรื่องยาก
ไม่ใช่ปัญหา API – ทุกเครื่องมือที่เราใช้มี API การค้นหาที่ดีมาก ปัญหานั้นแปลกกว่านั้น:
รูปแบบข้อมูลต่างกัน Slack คืนข้อความพร้อม timestamp และ channel ID Linear คืนอิชชูพร้อมสถานะและป้ายกำกับ GitHub คืน commit, PR และผลการค้นหาโค้ดในรูปแบบการตอบสนองที่แตกต่างกันโดยสิ้นเชิง การรวมสิ่งเหล่านี้เป็น timeline ที่สอดคล้องกันต้องการการ normalise ที่ไม่มีใครสนใจสร้าง (เพราะจริง ๆ แล้ว มันเป็นงานประเภทที่ไม่ปรากฏในการสาธิต sprint)
การแตกแยกของบริบท ข้อความ Slack ที่บอกว่า "ไปกับตัวเลือก B" ไม่มีความหมายโดยไม่มีเธรดที่นิยามตัวเลือก A, B และ C แต่การค้นหาของ Slack คืนข้อความแต่ละข้อความ ไม่ใช่ arc ของการสนทนา คุณพบข้อสรุปโดยไม่มีเหตุผล
การเบี่ยงเบนตามเวลา กระบวนการตัดสินใจมักครอบคลุมวันหรือสัปดาห์ โดยมีช่องว่างที่ไม่มีอะไรเกิดขึ้นเพราะทุกคนกำลังทำงานอย่างเต็มที่ การค้นหาด้วยคำสำคัญอาจแสดงจุดเริ่มต้นและจุดสิ้นสุดของการสนทนาในขณะที่พลาดส่วนกลางที่สำคัญ เพียงเพราะใช้คำต่างกันในขั้นตอนต่าง ๆ
การค้นหาข้ามเครื่องมือสำหรับนักพัฒนาไม่ใช่ปัญหา API – ทุกเครื่องมือมี endpoint การค้นหาที่ดีมาก มันเป็นปัญหาบริบท: การตัดสินใจกระจายอยู่ตามเครื่องมือต่าง ๆ ในรูปแบบที่เข้ากันไม่ได้ แตกแยกโดย arc ของการสนทนา และแยกออกจากกันด้วยการเบี่ยงเบนตามเวลา การค้นหาด้วยคำสำคัญพบเพียงชิ้นส่วน – เฉพาะบริบทที่เชื่อมต่อกันเท่านั้นที่จะพบภาพรวมทั้งหมด
สร้างการค้นหาข้ามเครื่องมือด้วยสิ่งที่คุณมี
นี่คือส่วนที่เป็นประโยชน์จริง ๆ สำหรับสามหรือสี่เครื่องมือที่มีการค้นหาแบบอ่านอย่างเดียว คาดว่าจะใช้เวลาครึ่งวันในการทำ MVP ให้ใช้งานได้ – ส่วนใหญ่ใช้ไปกับการตั้งค่า auth และการ normalise การตอบสนอง มากกว่าตรรกะการค้นหาเอง
ตั้งค่าการเข้าถึง API
คุณต้องการ token สำหรับแต่ละเครื่องมือ:
- Slack: User token ที่มี scope
search:read (วิธีการค้นหาของ Slack ต้องการ user token ไม่ใช่ bot token – สร้างผ่าน หน้า Slack API apps)
- Linear: Personal API key จาก Settings แล้ว API
- GitHub: Fine-grained PAT ที่มีสิทธิ์อ่าน repo ของคุณ
- Notion: Internal integration token จาก Settings แล้ว Connections
สคริปต์ Fan-out Query
รูปแบบพื้นฐานนั้นเรียบง่ายอย่างน่าประหลาดใจ – ส่งคำค้นหาเดียวกันไปยัง API ทุกตัวและรวบรวมผลลัพธ์:
```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* แต่ละตัว wrap API ที่เกี่ยวข้อง สำหรับ Slack นั่นคือ search.messages สำหรับ Linear เป็น GraphQL query กับ field การค้นหาของพวกเขา สำหรับ GitHub เป็น REST search endpoint สำหรับ Notion เป็น search endpoint ที่มีพารามิเตอร์ query
Normalise และลบรายการซ้ำ
ส่วนที่ยากไม่ใช่การค้นหา – มันคือการทำให้ผลลัพธ์มีประโยชน์ คุณต้องการ:
- Normalise timestamp ข้ามเครื่องมือ (Slack ใช้ Unix epoch, Linear ใช้ ISO string, GitHub ใช้ ISO พร้อม timezone offset)
- จัดกลุ่มผลลัพธ์ที่เกี่ยวข้อง – ถ้าเธรด Slack เดียวกันปรากฏสามครั้งเพราะสามข้อความตรงกัน รวมเป็นผลลัพธ์เดียวพร้อม thread URL
- จัดอันดับตามความเกี่ยวข้อง – API ส่วนใหญ่คืนคะแนนความเกี่ยวข้องของตัวเอง แต่ไม่สามารถเปรียบเทียบข้ามเครื่องมือได้ heuristic ง่าย ๆ: การตรงกันของคำสำคัญในหัวเรื่องได้อันดับสูงกว่าการตรงในเนื้อหา และผลลัพธ์ล่าสุดได้อันดับสูงกว่าผลเก่าที่ความเกี่ยวข้องเท่ากัน
Wrap เป็น CLI
ฉันใช้ 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... ```
สิบสี่ผลลัพธ์ เรียงตามเวลา ข้ามสี่เครื่องมือ คุณสามารถเห็น arc ทั้งหมดของการตัดสินใจในที่เดียว: เอกสาร Notion เริ่มก่อน จากนั้นการสนทนา Slack เกิดขึ้น แล้วอิชชู Linear ถูกสร้างเพื่อติดตาม และสุดท้าย PR ลงจอดหนึ่งสัปดาห์ต่อมา
ทำให้ดีจริง ๆ
เวอร์ชันพื้นฐานข้างต้นใช้งานได้ แต่มีขอบที่น่าหงุดหงิดบางอย่าง นี่คือวิธีปรับปรุง:
Thread expansion สำหรับ Slack เมื่อคุณพบข้อความที่ตรงกัน ดึงเธรดทั้งหมดด้วย conversations.replies ข้อความที่ตรงกันอาจเป็น "โอเค ไปกับ BullMQ เลย" – ไม่มีประโยชน์หากไม่มี 40 ข้อความก่อนหน้าของการถกเถียง แสดง snippet ของเธรด ไม่ใช่แค่ข้อความที่ตรงกัน
PR review comments API การค้นหาของ GitHub ไม่แสดง review comment เมื่อคุณค้นหา PR – คุณต้องโทรแยกต่างหากไปยัง pull request reviews endpoint เพื่อดึงมา นั่นคือที่ที่การอภิปรายทางเทคนิคจริง ๆ อยู่
Backlinks เมื่อคุณพบอิชชู Linear ตรวจสอบว่ามีข้อความ Slack ใดบ้างที่มี URL ของอิชชูนั้น การค้นหาของ Slack รองรับ filter has:link ร่วมกับคำสำคัญ สิ่งนี้แสดงการอภิปรายอย่างไม่เป็นทางการที่เกิดขึ้นรอบ ๆ การติดตามอย่างเป็นทางการ
Caching ถ้าทีมของคุณสร้างเนื้อหามาก (ใครไม่ล่ะ) คุณจะชนขีดจำกัด rate อย่างรวดเร็ว cache ผลลัพธ์ locally ด้วย TTL 30 นาที – การตัดสินใจในอดีตส่วนใหญ่ไม่เปลี่ยนแปลงเร็วนัก
เมื่อการค้นหาด้วยข้อความพัง
นี่คือที่ที่ฉันจะพูดตรง ๆ เกี่ยวกับข้อจำกัด การค้นหาด้วยคำสำคัญข้ามเครื่องมือพาคุณไปได้ไกลอย่างน่าประหลาดใจ แล้วก็ชนกำแพง
กำแพงนั้นคือ: การตัดสินใจพัฒนา เธรด Slack เกี่ยวกับ "job queues" อาจไม่เคยกล่าวถึง "BullMQ" โดยตรง – แทนนั้น มีคนแชร์ลิงก์ คนอื่นบอกว่า "ฉันชอบตัวเลือกที่รองรับ Redis" และคนที่สามบอกว่า "เห็นด้วย ไปกับนั้นเลย" การค้นหา "BullMQ" ของคุณพลาดเธรดทั้งหมดเพราะคำนั้นไม่ถูกใช้ คนในเธรดรู้ว่า "ตัวเลือกที่รองรับ Redis" หมายถึงอะไร การค้นหาของคุณไม่รู้
นี่คือปัญหากราฟในเชิงพื้นฐาน ไม่ใช่ปัญหาข้อความ สิ่งที่คุณต้องการจริง ๆ คือ: "แสดงทุกอย่างที่เชื่อมต่อกับการตัดสินใจที่นำไปสู่ PR #289" ซึ่งหมายถึงการเข้าใจว่า PR อ้างอิงอิชชู Linear ซึ่งถูกสร้างหลังจากการสนทนา Slack ซึ่งเริ่มต้นเพราะมีคนอ่านเอกสาร Notion การเชื่อมต่อนั้นเป็นนัย – มนุษย์สร้างขึ้นโดยการคัดลอก URL และพูดว่า "as discussed" – และการค้นหาด้วยคำสำคัญไม่สามารถสร้างมันขึ้นมาใหม่ได้
คุณสามารถแก้ปัญหาได้บางส่วนโดยการติดตามลิงก์ แยก URL จากข้อความ Slack คำอธิบาย PR และความคิดเห็น Linear สร้าง adjacency list อย่างง่าย: เธรด Slack นี้ลิงก์ไปยังอิชชู Linear นี้ ซึ่งถูกอ้างอิงใน PR นี้ แล้วเมื่อมีคนค้นหา คุณสามารถขยายผลลัพธ์เพื่อรวมรายการที่ลิงก์แม้ว่าจะไม่ตรงกับคำสำคัญ
วิธีการ adjacency-list นั้นในสาระสำคัญคือกราฟความรู้แบบดั้งเดิม – และนั่นคือที่ที่คุณค่าจริง ๆ ของการค้นหาข้ามเครื่องมือสำหรับนักพัฒนาอยู่ ไม่ใช่ในการค้นหาข้อความเดียว แต่ในการติดตามเส้นด้ายของการตัดสินใจข้ามทุกเครื่องมือที่มันสัมผัส มันเป็น "การค้นหา" น้อยกว่า และเป็นการจัดการความรู้สำหรับนักพัฒนามากกว่า – การเข้าใจวิธีที่ข้อมูลเชิงลึกไหลระหว่างเครื่องมือของคุณเพื่อให้คุณสามารถสร้างบริบทขึ้นมาใหม่ได้เมื่อต้องการ
ปัญหาการบำรุงรักษา (และทางลัด)
วิธีการสคริปต์ทำงานได้ยอดเยี่ยมประมาณสามเดือน แล้วใครสักคนเปลี่ยน Slack workspace หรือ Linear อัปเดต GraphQL schema หรือคุณเพิ่มเครื่องมือใหม่และไม่มีใครจำที่จะอัปเดตสคริปต์การค้นหา ฉันสร้างสิ่งนี้สองครั้งและละทิ้งสองครั้ง (ซึ่งน่าจะบอกได้มากกว่าเกี่ยวกับความมุ่งมั่นในการบำรุงรักษาของฉันมากกว่าวิธีการเอง)
ถ้าคุณต้องการการค้นหาข้ามเครื่องมือสำหรับนักพัฒนาที่ทันสมัยโดยไม่ต้องดูแล นั่นคือสิ่งที่เครื่องมืออย่าง Sugarbug ถูกสร้างมาเพื่อ – มันรักษากราฟความรู้โดยอัตโนมัติและคงการเชื่อมต่อไว้เมื่อเครื่องมือของคุณเปลี่ยนแปลง แต่เวอร์ชัน DIY ข้างต้นมีประโยชน์จริง ๆ ถ้าคุณเต็มใจที่จะบำรุงรักษามัน
หยุดค้นหาในห้าเครื่องมือแยกกัน Sugarbug สร้างกราฟความรู้เพื่อให้คุณค้นหาการตัดสินใจ การสนทนา หรือ commit ใด ๆ ได้ในที่เดียว
Q: จะค้นหาข้ามเครื่องมือสำหรับนักพัฒนาหลายตัวพร้อมกันได้อย่างไร? A: คุณสามารถสร้างการค้นหาข้ามเครื่องมือแบบเบาได้โดยรวม API ของแต่ละเครื่องมือ – search.messages ของ Slack, issueSearch ของ Linear และ endpoint การค้นหาโค้ดของ GitHub – เป็นสคริปต์เดียวที่ส่งคำค้นหาออกไปและรวมผลลัพธ์ตามเวลา ตัวอย่างโค้ดข้างต้นจะช่วยให้คุณเริ่มต้นได้ในครึ่งวัน ความท้าทายหลักไม่ใช่การค้นหาเอง แต่เป็นการ normalise รูปแบบการตอบสนองต่าง ๆ ให้เป็น timeline ที่สอดคล้องกัน
Q: Sugarbug มีการค้นหาข้ามเครื่องมือสำหรับนักพัฒนาไหม? A: มี Sugarbug รับสัญญาณจาก Linear, GitHub, Slack, Figma, Notion และเครื่องมืออื่น ๆ เข้าสู่กราฟความรู้ เพื่อให้คุณค้นหาการตัดสินใจหรือการสนทนาและพบทุกเธรด อิชชู และ commit ที่เชื่อมต่อกันในที่เดียว มันจัดการการ normalise การลบรายการซ้ำ และการติดตามลิงก์โดยอัตโนมัติ – ส่วนที่ทำให้วิธีการ DIY เปราะบางตามเวลา
Q: ทำไมฉันถึงไม่พบการตัดสินใจด้านสถาปัตยกรรมในโค้ดเบส? A: เพราะการตัดสินใจส่วนใหญ่เกิดขึ้นในเธรด Slack ความคิดเห็น Linear เอกสาร Notion และการรีวิว PR – ไม่ใช่ในโค้ดโดยตรง โค้ดบันทึกผลลัพธ์ของการตัดสินใจ (ฟังก์ชันมีอยู่ ไลบรารีถูกเลือก) แต่เหตุผล การเปรียบเทียบข้อดีข้อเสีย และทางเลือกที่ได้อภิปรายกันนั้นกระจัดกระจายอยู่ทั่วเครื่องมือสื่อสารของคุณ git blame บอกคุณว่าใครเปลี่ยนบรรทัดและเมื่อไหร่ แต่ไม่ใช่ว่าทำไมพวกเขาถึงเลือกวิธีนั้นแทนทางเลือกอื่น
Q: Sugarbug แทนที่เอกสาร ADR สำหรับการติดตามการตัดสินใจได้ไหม? A: Sugarbug ไม่ได้แทนที่ ADR แต่จะจับการตัดสินใจที่ไม่เคยถูกบันทึกลงใน ADR ทีมส่วนใหญ่เขียน ADR สำหรับประมาณ 10% ของการเลือกสถาปัตยกรรม – ส่วนที่เหลือละลายหายไปในเธรด Slack และความคิดเห็น PR Sugarbug นำสิ่งเหล่านั้นขึ้นมาโดยเชื่อมการสนทนากับการเปลี่ยนแปลงโค้ดที่เกิดขึ้น เพื่อให้คุณได้การติดตามการตัดสินใจสำหรับ 90% ที่เหลือโดยไม่ต้องเปลี่ยนเวิร์กโฟลว์ของใคร