HN เปิดตัว: Haystack – IDE สำหรับสำรวจและแก้ไขโค้ดบนผืนผ้าใบไร้ขีดจำกัด

 (haystackeditor.com)
2 คะแนน โดย GN⁺ 2024-07-26 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Haystack ถูกนำเสนอเป็นเครื่องมือรีวิวโค้ดที่อ่านทั้ง ประวัติการสนทนาและการเปลี่ยนแปลง ของ PR ร่วมกัน แล้วส่งต่อให้รีวิวเวอร์เฉพาะการเปลี่ยนแปลงที่ต้องอาศัยการตัดสินใจของมนุษย์จริง ๆ
  • PR ที่สะอาดจะถูกรวมอัตโนมัติ ส่วน PR ที่มีความเสี่ยงจะถูกจัดเป็น เป้าหมายสำหรับการคัดกรอง โดยมุ่งไปสู่เวิร์กโฟลว์ที่เข้าใกล้ “human code review time to zero”
  • PR ตัวอย่างได้ทำ tenancyInit() และ cacheWarmup() ให้รันแบบขนานด้วย Promise.all() เพื่อลด cold start จากประมาณ 4 วินาทีเหลือ 2.4 วินาที แต่เป็นการย้อนการตัดสินใจเรื่องลำดับการทำงานในอดีต
  • Haystack ค้นพบหลักฐานจากประวัติการสนทนาว่า cacheWarmup ต้องรันหลัง tenancyInit และยืนยันใน sandbox ว่า จากการบูต 50 ครั้ง มี 31 ครั้งที่แครช
  • PR ที่มีปัญหาถูกส่งต่อไปยัง @maya ซึ่งเป็นผู้กำหนดลำดับเดิม พร้อมแนบทั้งการตัดสินใจด้านสถาปัตยกรรมที่ถูกทำให้พังและผลล้มเหลว เพื่อช่วยลดเวลาในการตัดสินรีวิว

เวิร์กโฟลว์สำหรับคัดกรอง PR รีวิวโดยอัตโนมัติ

  • Haystack อ่านทั้ง ประวัติการสนทนา และการเปลี่ยนแปลงของทุก PR เพื่อประเมินความเสี่ยง
  • PR ที่เสี่ยงจะถูกนำไปรันตรวจสอบแบบ end-to-end และจะดึงรีวิวเวอร์เข้ามาเฉพาะเมื่อจำเป็นต้องใช้การตัดสินใจของมนุษย์เท่านั้น
  • บนหน้าจอมีภาพที่ Haystack กำลังคัดกรอง PR 16 รายการ
    • มี PR จากหลายภาษา เช่น TypeScript, JavaScript, C, Python, Ruby, Go, C++ เป็นต้น
    • แต่ละ PR แสดงสถานะเป็น analyzing

ตัวอย่างการเปลี่ยนแปลงที่เสี่ยง: ทำ bootstrap ของบริการให้ขนานกัน

  • PR ตัวอย่าง platform#3120 feat: parallelize service bootstrap เป็นการเปลี่ยนแปลงเพื่อทำให้ขั้นตอน bootstrap ของบริการรันแบบขนาน
  • โค้ดเดิมรัน tenancyInit() ก่อน แล้วจึงรัน cacheWarmup() ตามลำดับ
  • โค้ดที่เปลี่ยนใหม่รันทั้งสองงานพร้อมกันด้วย Promise.all([tenancyInit(), cacheWarmup()])
  • ตามคำอธิบาย PR ค่า cold start เพิ่มไปถึงประมาณ 4 วินาที และหลังทำขนานลดลงมาเหลือประมาณ 2.4 วินาที
  • การทดสอบเดิมผ่านทั้งหมด ทำให้ภายนอกดูเหมือนเป็นการปรับปรุงประสิทธิภาพที่อนุมัติได้ง่าย

การตัดสินใจด้านสถาปัตยกรรมที่เผยออกมาจากประวัติการสนทนา

  • Haystack อ่านประวัติเบื้องหลังของ PR แล้วพบว่าการเปลี่ยนแปลงนี้กำลัง ย้อนการตัดสินใจด้านสถาปัตยกรรมในอดีต
  • @maya เคยกำหนดว่า tenancyInit ต้องเสร็จก่อน เพื่อไม่ให้ cacheWarmup อ่านค่าการตั้งค่าที่ว่างเปล่า
  • ในชุดทดสอบไม่มีรายการที่ตรวจสอบลำดับการทำงานนี้ ทำให้ regression ผ่านการทดสอบได้
  • รีวิวของ Haystack จะแนบข้อมูลต่อไปนี้ไว้ใน PR
    • การตัดสินใจที่คงอยู่ในประวัติการสนทนา
    • พฤติกรรมที่ PR ปัจจุบันเปลี่ยนไปจริง
    • เหตุผลที่การทดสอบยังผ่าน

การตรวจสอบด้วยการรันจริงและผลล้มเหลว

  • Haystack ไม่ได้หยุดแค่อ่านโค้ด แต่รันการเปลี่ยนแปลงนั้นจริงด้วย
  • เมื่อประวัติการสนทนาชี้ไปที่ เงื่อนไขแข่งขันด้านเวลา ที่ไม่มีในเทสต์ ก็จะบูตบริการใน sandbox 50 ครั้ง
  • จาก 50 ครั้ง มี 31 ครั้ง ที่ cacheWarmup อ่านค่าการตั้งค่าที่ว่างก่อน tenancyInit จะเสร็จ
  • ส่งผลให้บริการโยน exception ในคำขอแรกและแครช
  • Haystack QA จะแสดงทั้งเหตุผลที่รัน วิธีการทดสอบที่ทำ และจุดที่พังไว้ใน PR ด้วย

จุดที่ยังต้องใช้การรีวิวโดยมนุษย์

  • Haystack ไม่รวม PR นี้อัตโนมัติ แต่แนะนำให้ดึง @maya ผู้กำหนดลำดับการทำงานเดิมเข้ามามีส่วนร่วม
  • ใน PR จะแสดงทั้งการตัดสินใจด้านสถาปัตยกรรมที่ถูกทำให้พังและผลการบูตที่ล้มเหลวควบคู่กัน
  • หน้าจอรีวิวมีตัวเลือกอย่าง “Request review”, “Chat with @maya”, “Doesn’t need review”
  • เวิร์กโฟลว์ของ Haystack มุ่งเน้นการรวม PR ส่วนใหญ่โดยอัตโนมัติ และส่งต่อเฉพาะการเปลี่ยนแปลงที่เสี่ยงอย่างในตัวอย่างไปยังคนที่เหมาะสม

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-26
ความคิดเห็นบน Hacker News

  • ไม่แน่ใจเรื่องฟีเจอร์ AI แต่แนวคิดของการ ทำงานกับโค้ดบนแคนวาส และใช้ UI แบบผังงานควบคู่กัน เป็นสิ่งที่อยากได้มานานแล้ว
    ส่วนใหญ่ผมทำงานด้านการประมวลผลข้อมูล และมักวาดผังงานเยอะมากเพื่ออธิบาย pipeline หรือทำความเข้าใจมันเอง
    ถ้ามี UI สำหรับการพัฒนาไปในทิศทางนี้ น่าจะดีสำหรับจัดการ codebase ที่รับมือยากซึ่งสร้างโดยคนที่ไม่ได้จบ CS มา

    • คุณนึกถึงเครื่องมืออย่าง LabView อยู่หรือเปล่า?
      https://www.ni.com/en/shop/labview.html
    • คล้ายกับแนวทางที่ BlueJ ทำใน Java หรือเปล่า?
    • สงสัยว่าปัญหาที่เจอคือเรื่องการแสดงภาพ data flow หรือการแสดงภาพ control flow กันแน่
    • ถ้าสามารถสเก็ตช์ทั้ง ไดอะแกรมและโค้ด ไว้บนแคนวาสเดียวกันได้ก็น่าจะเจ๋ง
      น่าจะทำให้การทำเอกสารเชิงภาพง่ายขึ้นมาก

  • เจ๋งจริง ๆ ชอบตรงที่เวลาไปยังเมธอดหรือ declaration มันไม่ได้เปิดทั้งไฟล์ในแท็บเสริมแล้วเลื่อนไปตำแหน่งนิยาม แต่แสดงเฉพาะ ชิ้นส่วนโค้ดที่เกี่ยวข้อง
    ผมมักทำตำแหน่งเมธอดที่กำลังอ่านหลุดหายไปบ่อย ๆ เพราะต้องเทียบตำแหน่งที่เมธอดถูกเรียกกับนิยาม ซึ่งค่อนข้างน่าหงุดหงิด
    ดีที่สามารถ “ปักหมุด” เมธอดไว้ข้าง ๆ แล้วไล่อ่านในมุมมองที่ปักหมุดไว้ได้ โดยไม่เผลอเลื่อนทั้งไฟล์ในมุมมองนั้น
    ลองใช้ดูครู่หนึ่งแล้ว น่าเสียดายที่ยังเน้นเมาส์มาก และพอตามเมธอดที่อยู่ข้างในเมธอดอื่น ๆ ไปเรื่อย ๆ ก็มีหน้าต่างลอยที่ต้องจัดการมากเกินไป
    ถ้ามีลูกศรหรือเส้นให้ติดตามได้ว่าหน้าต่างไหนเป็นหน้าต่าง “พ่อแม่” ก็น่าจะทำเป็นผังงานได้ง่ายขึ้น
    ส่วนตัวมีจุดที่เสียดายอยู่บ้าง แต่ก็ดีใจที่ได้เห็นแนวคิดอีกแบบในพื้นที่นี้ และขอให้ประสบความสำเร็จ

    • เข้าใจว่าทำไมถึงชอบ แต่ในระยะยาวผมคิดว่าผลสุทธิอาจเป็นลบก็ได้
      ผมคิดว่าการรู้ในระดับหนึ่งว่าอะไรอยู่ตรงไหนในโค้ดเป็นประโยชน์
      อาจเป็นไปได้ไหมว่าทำโปรเจกต์หนึ่งมาหลายปี แต่เพราะทำงานโดยดูแค่ชิ้นส่วนเล็ก ๆ เลยไม่รู้ว่าไฟล์ต่าง ๆ ทำอะไรกันแน่
    • Literate programming ทำสิ่งนี้ในแบบ 1 มิติ คือเลื่อนแนวตั้ง และมีมุมมองสองแบบ
      มีซอร์สโค้ดต้นฉบับที่คอมเมนต์กับข้อความผสมกัน และโค้ดที่จัดวางสวยงามพร้อม rich text กับไฮเปอร์ลิงก์สำหรับนำทาง
      http://literateprogramming.com/
    • ใช่แล้ว ต้องทำให้การนำทางด้วยคีย์บอร์ดง่ายขึ้น
      อยากรู้ว่าคุณจินตนาการจุดอ้างอิงของ “หน้าต่างพ่อแม่” ไว้แบบไหน
      อยากกำหนดหน้าต่างใดหน้าต่างหนึ่งเป็น anchor หรืออยากให้ heuristic บางอย่างช่วยหา anchor แบบนั้นให้

  • ยินดีด้วยกับการเปิดตัว ช่วงนี้ผมกำลังไปในทิศทางตรงข้ามสุด ๆ เพราะเรื่องสมาธิและแนวโน้ม ADHD มันช่วยลดการกระโดดไปมาจนรู้สึกท่วมท้นได้
    หน้าต่างเดียว ย่อทุกอย่างให้เล็กที่สุด และที่สำคัญที่สุดคือตัดการนำทางแบบ tree ออก
    ถ้าต้องไปที่ไฟล์ ผมใช้เมนู Recent ของ Intellij หรือกระโดดด้วย file marker
    นั่นหมายความว่าต้องจำ file marker ได้ และต้องมีเจตนาจะไปที่นั่น ผมใช้ปลั๊กอิน IdeaVim สำหรับคีย์ลัดแบบ vim
    สำหรับผม วิธีนี้ทำให้การเขียนโปรแกรมมีสมาธิและสนุกขึ้นมาก
    เป็นส่วนหนึ่งของการเปลี่ยนจากหลายจอไปเป็นจอกว้าง แล้วกลับมาเป็นหน้าจอเดียวอีกครั้ง
    สำหรับ codebase ขนาดใหญ่และโตเต็มที่แบบที่กล่าวถึง ผมใช้ LLM เป็นตัวช่วยนำทาง

    • ใช้อย่างไรหรือครับ? และอยากรู้ด้วยว่าคุณมองว่า codebase ขนาดใหญ่และโตเต็มที่ ระดับไหน
      จากประสบการณ์ของผม LLM ทำผิดและตั้งสมมติฐานเองค่อนข้างมาก แม้จะดูแค่ไฟล์เดียวก็ตาม
    • เข้าใจครับ อยากรู้ว่าคุณใช้ LLM เป็นตัวช่วยนำทางอย่างไร
      จากประสบการณ์ของผม เมื่อถาม LLM ว่า flow ของฟีเจอร์อยู่ตรงไหน มันสร้างจุดเริ่มต้นให้ได้ดี แต่รายละเอียดมักต้องไปทำความเข้าใจเองอยู่บ่อย ๆ และบางครั้งก็ชี้ไปยังที่ที่เกี่ยวข้อง แต่ไม่ใช่สิ่งที่กำลังหา

  • น่าสนใจ มีบันทึกไว้สองสามข้อ
    Obsidian มีฟีเจอร์คล้ายกันชื่อ “Canvas” จึงน่าศึกษา workflow ของมัน
    สำหรับผม ถ้าเป็นเครื่องมือ standalone จะไม่มีประโยชน์ ต้องการให้เป็น ปลั๊กอิน Idea
    ส่วนที่เกลียดที่สุดคือการจัด layout ถ้ามี AI ที่รับ Git patch หรือ bug fix แล้วสร้าง layout ที่เหมาะกับมันให้ได้ก็คงดี
    การแชร์ layout ควรทำได้ง่ายมาก
    ถ้ารวมประวัติ Git เป็นอีกมิติหนึ่งได้ก็คงดี ถ้ามี diff และ blame notation อยู่ใน editor ด้วยก็ยิ่งดี
    มีข้อมูลที่ใช้ฝึก AI ได้อยู่แล้ว นั่นคือ Git commit
    ถ้ารวม debugging เป็นอีกมิติหนึ่ง และรวมข้อมูล profiler เข้าไปด้วยก็คงดี

    • จากวิดีโอเดโม ดูเหมือนว่ามันไม่ได้เป็น standalone แต่ รันอยู่ใน VSCode
      ก็เท่ากับได้สิ่งที่ VSCode มีให้อยู่แล้ว
      ถ้าใช้เครื่องมือสาย Idea ตอนนี้ดูเหมือนยังไม่มีทาง
    • เครื่องมือดูดีและอยากลองใช้กับงานจริง ผมทำ Android/Kotlin จึงขอโหวตเพิ่มอีกเสียงให้ การผสานกับ IDEA

  • อยากลองใช้ของแบบนี้มานานแล้ว มีวิธีติดตามอัปเดตไหม?
    โดยเฉพาะอย่างยิ่ง แม้จะเป็นแค่ตอนลองใช้ครั้งแรก ก็รอตัวเลือกสำหรับ ปิดฟีเจอร์ AI อยู่
    ชอบฟีเจอร์ซูมเข้าไปในฟังก์ชันแล้วซ่อนส่วนที่เหลือของไฟล์เป็นพิเศษ มีหลายครั้งอย่างไม่น่าเชื่อที่อยากได้อะไรแบบนี้
    น่าจะใช้ในลักษณะจัดวางไฟล์เดียวใหม่แบบเสมือน ๆ ได้ด้วย เช่น ลากฟังก์ชันที่กำลังทำงานอยู่ในไฟล์เดียวกันมาวางข้าง ๆ กันได้ง่าย ๆ
    นอกจากอินเทอร์เฟซสำหรับแก้ไขแล้ว ผมคิดว่ายังมีโอกาสด้าน visualization อีกมากในเอดิเตอร์
    เช่น visualization ของการโต้ตอบระหว่างโค้ดของเรากับ dependency จาก third party, กราฟ dependency/call graph ของโค้ดของเรา หรือบางส่วนของมัน, dependency graph ระดับคลาสหรือโมดูล, และ nested call graph ที่ drill down ลงไปถึง call graph ภายในอ็อบเจกต์ได้
    ในกรณีเหล่านี้ทั้งหมด การสลับไปมาระหว่าง visualization กับการแก้ไขได้อย่างลื่นไหล ดูเหมือนจะเป็น killer feature ที่เครื่องมือนี้ตั้งเป้าไว้
    แค่มีกราฟิกเข้ามาในเอดิเตอร์ ก็ทำให้ visualization ที่น่าสนใจได้อีกมาก เช่น heatmap ความถี่ของการเปลี่ยนโค้ด, heatmap ประสิทธิภาพของโค้ด, การติดตามการใช้งานตัวแปร ฯลฯ
    https://adamtornhill.com/articles/crimescene/codeascrimescen...
    สุดท้าย ถ้ายังไม่ได้อ่าน The Programmer's Brain อย่างน้อยลองฟังพอดแคสต์นี้ก็ดี
    https://se-radio.net/2021/06/episode-462-felienne-on-the-pro...
    มีไอเดียด้านเอดิเตอร์มากมายที่เกี่ยวข้องกับวิธีที่สมองเราทำงาน แต่ยังไม่เคยเห็นว่าเอดิเตอร์รองรับได้ดีนัก
    ในเมื่อก้าวไปในทิศทางนั้นแล้ว อาจยังมีโอกาสอีกมาก

    • น่าเสียดายที่ตอนนี้ยังไม่ได้ทำวิธีฉลาด ๆ สำหรับสมัครรับอัปเดตไว้
      จะลองคิดหาวิธีที่ดีที่สุด และท้ายที่สุดจะ push อัปเดตโดยตรงในผลิตภัณฑ์
      ตอนนี้กำลังเพิ่ม การ opt out จาก copilot อยู่พอดี
      ไอเดียตรงนี้ดีมาก และอยากคุยต่อบางข้อด้วย ถ้าโอเคจะส่งอีเมล/DM ไปหา
      โดยรวมแล้วอยากคุยกับหลาย ๆ คน และรับฟีดแบ็กได้ที่ feedback@haystackeditor.com

  • ชอบวิธีนำทางจากฟังก์ชันหนึ่งไปอีกฟังก์ชันหนึ่ง จากไฟล์หนึ่งไปอีกไฟล์หนึ่ง แล้วกลับมาอีกครั้งมาก
    ถ้าจะให้มีประโยชน์ขึ้น น่าจะมี หน้าต่างประวัติการนำทาง แบบ history ในเบราว์เซอร์
    เวลาเคลื่อนที่ระหว่างไฟล์กับฟังก์ชัน อยากให้แสดงรายการ แล้วสามารถเดินหน้า/ถอยหลัง หรือกระโดดไปยังตำแหน่งใดก็ได้ในประวัติการนำทาง โดยไม่ต้องคุ้ยหาหน้าต่างที่เปิดอยู่ให้ลำบาก
    ประวัติการนำทางที่พูดถึงนี้แยกจากประวัติการแก้ไขโดยสิ้นเชิง
    undo/redo การแก้ไขไม่ควรไปขยับประวัติการนำทางไปหน้า/หลัง และในทางกลับกันก็เช่นกัน
    แน่นอนว่าอาจมีคีย์ลัดสำหรับเดินไปมาในประวัติการนำทางได้

    • เป็นไอเดียที่ดี จะลองคิดหาวิธี implement ให้ดีที่สุด

  • เจ๋งดี เกี่ยวข้องกับ Code Bubbles: https://dl.acm.org/doi/abs/10.1145/1753326.1753706

    • ใช่แล้ว Bubbles ยอดเยี่ยม โดยเฉพาะชอบ แนวคิด minimap

  • “เราไม่จัดเก็บโค้ดหรือบันทึกเป็น log เราส่ง snippet โค้ดไปยัง Open AI เพื่อเป็น input ของ copilot สำหรับการนำทาง เราจะเพิ่มตัวเลือกให้ปิดการใช้งานสิ่งนี้เร็ว ๆ นี้”
    ถ้ามีตัวเลือกนั้นแล้วก็อยากลองดู

    • เพิ่ม การ opt out จาก copilot สำหรับการนำทาง บน Mac แล้ว
      เปิด command palette (CMD+SHIFT+P) แล้วใช้คำสั่ง “Opt out of navigational copilot” ได้เลย
      Windows/Linux จะรองรับเร็ว ๆ นี้
      อีกอย่าง โปรดทราบว่าจะส่งข้อมูลไปยัง Open AI เฉพาะเมื่อมี diagnostic ว่าเรียกฟังก์ชันที่ไม่มีอยู่จริงเท่านั้น
    • มีปฏิกิริยาแบบเดียวกัน ยินดีสนับสนุนการพัฒนาเครื่องมือแบบนี้ แต่ขอเป็นวิธีที่ตรงไปตรงมากว่านี้หน่อย
    • เห็นด้วย ควรเป็น opt-in ตั้งแต่แรก
    • สภาพตอนนี้คงลองใช้ในบริษัทได้ยาก

  • เคยตีพิมพ์งานวิจัยเปรียบเทียบ เวลาในการนำทาง ระหว่างเอดิเตอร์แบบ canvas (Code Bubbles), เอดิเตอร์แบบแท็บดั้งเดิม (Eclipse), และเอดิเตอร์แบบ carousel ที่ผมออกแบบ (Patchworks)
    ผลที่ได้คือ canvas ให้อิสระมากเกินไป
    https://austinhenley.com/pubs/Henley2014CHI_Patchworks.pdf

    • น่าสนใจ ไม่ค่อยเคยคิดลึก ๆ เรื่อง การจัดวางเชิงพื้นที่ ของ IDE มาก่อน
      พอมองย้อนกลับไป แม้แต่ใน VS Code ก็ไม่ใช้แท็บแล้ว เพราะมีไฟล์ที่เปิดไว้เยอะเกินไป
      แค่ดูทีละไฟล์ และเวลาต้องสลับก็ใช้ Cmd-P ค้นหา หรือย้ายไปมาระหว่างไฟล์ล่าสุด
      ใช้งานได้ดี แต่ต้องเก็บชื่อไฟล์/ไดเรกทอรีไว้ในหัวตลอดเวลา
    • อ่าน paper ไปนิดหน่อย แต่จากการอภิปรายเกี่ยวกับ Eclipse ดูเหมือนว่าถ้าผู้เข้าร่วมใช้มันให้ สมกับเป็น IDE มากกว่าจะใช้เหมือนเอดิเตอร์หลายแท็บ ก็น่าจะมีประสิทธิภาพกว่ามาก
      การหาเมธอดน่าจะเป็นปัญหาน้อยลงมากถ้ามี outline view ที่เรียงตามตัวอักษร
    • น่าสนใจมาก เคยลังเลระหว่าง grid กับ canvas แต่สุดท้ายเลือก canvas เพราะคิดว่าจริง ๆ แล้วนำทางง่ายกว่า
      ถ้าโอเคก็อยากคุยด้วย และจะส่งอีเมลไปหา
    • น่าสนใจ Patchworks คล้ายกับวิธีที่ผมตั้งค่า Doom Emacs อยู่พอสมควร
      มี code panel 4–6 อันกระจายอยู่หลาย workspace แล้วสลับด้วย SPC TAB ตัวเลข
    • เป็นการวิเคราะห์ที่ยอดเยี่ยม สำหรับผม ไม่ว่าจะเป็นแบบ canvas หรือ carousel มันช่วยลดภาระที่ต้องเก็บข้อมูลเชิงปัญญาจำนวนมากไว้ในหัวเสมอเวลาจัดการ codebase ขนาดใหญ่มาก
      ถ้าจะใช้เครื่องมือให้ได้เต็มที่ ก็แทบจำเป็นต้องมี จอ widescreen ที่ใหญ่พอด้วย
      ประเด็นสำคัญคือการคุ้นเคยกับการจัดการไฟล์ในแนวนอน ไม่ใช่แนวตั้ง
      การคิดแบบแนวตั้งนี้ฝังรากค่อนข้างลึกจากวิธีที่เราเขียน Hello World ครั้งแรก

  • ยินดีกับการเปิดตัว ดูเหมือนเป็นเครื่องมือที่ยอดเยี่ยมและทำออกมาได้ดีมาก รอคอยที่จะได้ลองใช้
    ทำให้นึกถึงฟีเจอร์หนึ่งที่อยากได้มานาน และเคยลองทำเองแบบแมนนวลอยู่หลายครั้ง แต่ไม่เคยทำให้อยู่ในรูปแบบที่แชร์ได้ นั่นคือ ฟีเจอร์ที่คลี่เส้นทางของโค้ดออกมาเป็นสคริปต์หรือไฟล์ซอร์สไฟล์เดียว
    อยากให้สามารถตั้งอะไรสักอย่างคล้าย breakpoint แล้วกดปุ่ม “unravel” จากนั้นเหลือไฟล์เดียวที่แสดงการทำงานทั้งหมดที่เกิดขึ้นจนถึงจุดนั้น
    ถ้าตามอุดมคติ ไฟล์นั้นรันเป็นสคริปต์เดี่ยวได้ด้วยก็ยิ่งดี
    โดยแก่นแล้วมันเหมือนมุมมองที่ debugger แบบทีละขั้นตอนให้มา แต่แทนที่จะต้องอ้างถึงหลายไฟล์และหลายเลเยอร์ ผมอยากเห็นทุกอย่างตั้งแต่ต้นจนจบอยู่ในไฟล์เดียว

    • ทำไมถึงต้องการสิ่งนี้ครับ? กำลังพยายามแก้ปัญหาอะไรอยู่? ผลลัพธ์ที่ต้องการคืออะไร?
      ผมคิดว่าหลายอย่างตกหล่นไปในกระบวนการสื่อสาร เมื่อผู้คนโฟกัสที่รายละเอียดการ implement แบบเฉพาะเจาะจง แทนที่จะเป็น requirements, parameters และผลลัพธ์
      เลยสงสัยว่าทำไมถึงต้องการ implementation แบบนี้ และมันควรทำหน้าที่หรือบรรลุเป้าหมายอะไร