- ระหว่างการทำงานประจำวัน มักเกิดกรณีที่เพื่อนร่วมงาน จับภาพหน้าจอข้อความแล้วส่งมา อยู่บ่อยครั้ง ซึ่งเป็นวิธีที่ไม่มีประสิทธิภาพและทำให้การค้นหาโค้ดกับการทำความเข้าใจบริบททำได้ยากมาก
- โค้ดที่ได้รับมาในรูปสกรีนช็อตทำให้ไม่อาจรู้ บริบทอย่างการประกาศตัวแปร ตำแหน่งของโมดูล หรือการจัดการ exception ได้เลย จนต้องพิมพ์ลงช่องค้นหาทีละตัวเอง หรือไม่ก็ต้องใช้ coding agent ช่วยหา
- หากส่ง build error log มาเป็นสกรีนช็อต ก็จะไม่สามารถรู้ได้เลยว่า กำลัง build อะไร, fail ที่บรรทัดไหน, และ error message ที่แท้จริงคืออะไร ทำให้แก้ปัญหาไม่ได้
- หากใช้การคัดลอก-วางข้อความหรือ แชร์ไฟล์/ลิงก์ GitHub ก็จะสามารถใช้ความสามารถในการค้นหาของ IDE และตรวจดูบริบททั้งหมดได้
- เว้นแต่จะเป็นปัญหาที่เกี่ยวกับ การแสดงผลบนหน้าจอ ข้อความก็ควรแชร์ในรูปแบบที่คัดลอกได้ ไม่ใช่สกรีนช็อต เพื่อให้การทำงานร่วมกันมีประสิทธิภาพ
ตัวอย่างปัญหาจากสกรีนช็อต 1: โค้ด
- เมื่อคุยประเด็นเกี่ยวกับโค้ดกับเพื่อนร่วมงาน ก็มักได้รับ สกรีนช็อตของโค้ด
- ไม่สามารถเข้าใจ บริบทสำคัญได้เลย เช่น การประกาศตัวแปร
slug, วิธีสร้าง baseUrl, เหตุผลที่ hardcode โดเมน, วิธีจัดการ exception หรือแม้แต่ตำแหน่งของโมดูลนั้น
- ต้อง พิมพ์โค้ดในสกรีนช็อตลงช่องค้นหาเองทีละบรรทัด หรือใช้ coding agent เพื่อหาโมดูลที่เกี่ยวข้อง
- ถ้าใช้การคัดลอก-วางข้อความ แม้จะเป็น บรรทัดเดียวกันก็ยังเห็นบริบทได้มากกว่า และยังสามารถวางลงในเครื่องมือค้นหาของ IDE ได้ทันที
- การแชร์ไฟล์โดยตรงหรือ ลิงก์ GitHub มีประสิทธิภาพกว่ามาก
ตัวอย่างปัญหาจากสกรีนช็อต 2: build error log
- ได้รับ สกรีนช็อตของ error log พร้อมข้อความว่า “build fail แล้ว ช่วยดูให้หน่อยได้ไหม?”
- ไม่รู้เลยว่ากำลัง build อะไร, fail ที่บรรทัดไหน, หรือแม้แต่ error message ที่แน่ชัดคืออะไร
- บางครั้งพอลอง rebuild ทั้งหมดบน workstation ของตัวเองกลับ build ผ่าน
- ถ้า คัดลอก error log ทั้งหมด หรือ dump log ออกเป็นไฟล์แล้วส่งมา ก็เป็นปัญหาที่แก้ได้ง่ายมาก
วิธีแชร์ข้อความที่ถูกต้อง
- อย่าส่งข้อความเป็นสกรีนช็อต แต่ให้ แชร์ในรูปแบบที่คัดลอกได้
- ควรใช้สกรีนช็อตเฉพาะเมื่อจำเป็นต้องแสดง ปัญหาด้านหน้าตาของการแสดงผลบนจอ หรือมีข้อมูลประกอบที่ข้อความล้วนถ่ายทอดไม่ได้
- การแชร์ไฟล์หรือลิงก์ GitHub คือ วิธีที่ดีที่สุดในการเข้าใจบริบทและค้นหาโค้ด
4 ความคิดเห็น
ผมไม่ชอบสกรีนช็อตที่เป็นข้อความ
บางครั้งก็มีการจับภาพโค้ดแล้วโพสต์ ด้วยเหตุผลเรื่องความอ่านง่ายที่เห็นในเอดิเตอร์ตอนแคป และความสะดวกของคีย์ลัดจับภาพหน้าจอที่ OS รองรับมาให้ตั้งแต่ต้น
ถ้ามีโปรแกรมที่สามารถแปลงโค้ดในภาพที่จับด้วยคีย์ลัดเดียวให้เป็นลิงก์อย่าง Text fragments เพื่อแชร์ออกไปภายนอกได้ และวางต่อได้ทันที ก็น่าจะเลือกใช้โปรแกรมนั้นนะ
เวลาโพสต์ลง Slack ก็จะแสดงพรีวิวได้ แล้วกดเข้าลิงก์ไปเพื่อคัดลอกโค้ดได้
ผมไม่ชอบสกรีนช็อตที่เป็นข้อความ
เพื่อเรียกกระแสหน่อย ผมขอแนะนำเว็บที่เปลี่ยนโค้ดให้เป็นภาพสกรีนช็อตสวย ๆ สำหรับดูโค้ดครับ 555
https://ray.so/
เวลาผมจะส่งอะไรทางเมสเซนเจอร์หรืออีเมล ผมเองก็พยายามใช้ข้อความล้วนให้มากที่สุดเหมือนกัน แต่จริง ๆ แล้วในบางกรณี การใช้แต่ข้อความอย่างเดียวก็อาจทำให้ใช้งานลำบากกว่าได้เหมือนกัน
เมื่อเทียบกันแล้ว การจับภาพหน้าจอนั้นแค่กดคีย์ลัดสักครั้ง ลากเลือกหน้าจอ แล้ววางลงไป ก็จัดการได้บน GUI เลย ดังนั้นในมุมของคนส่ง มันก็น่าจะรู้สึกว่าสะดวกกว่า
แต่ตามที่บทความต้นทางชี้ไว้ ในมุมของคนรับ บางครั้งสกรีนช็อตอย่างเดียวก็ไม่ได้ถ่ายทอดบริบทได้ครบถ้วน แถมยังค้นหาหรือคัดลอก-วางก็ไม่สะดวก เลยทำให้เกิดความไม่พอใจได้ ผมคิดว่าเป็นแบบนั้น ต่อให้ยังไม่ต้องพูดถึงเรื่องที่มันสร้างโอเวอร์เฮดในการส่งและจัดเก็บข้อมูลมากกว่าที่จำเป็นตั้งเยอะก็ตาม
ถ้าจะไล่บ่นเรื่องแบบนี้เป็นข้อ ๆ ส่วนตัวผมก็ยังไม่ค่อยชอบตั้งแต่การทำเอกสารภายในบริษัทเป็นไฟล์ Word แทนที่จะใช้วิกิแล้วล่ะ…
ความเห็นจาก Hacker News
อย่างที่มีคนพูดไว้ในคอมเมนต์อื่นๆ ฟีเจอร์ OCR อัตโนมัติ บนแพลตฟอร์มของ Apple นั้นปฏิวัติวงการจริงๆ
ผมคิดว่าฟีเจอร์แบบนี้ควรมีเป็นค่าเริ่มต้นในตัวดูเอกสารของทุกแพลตฟอร์ม
อีกอย่างที่อยากได้คือการใส่ metadata ลงไปในภาพหน้าจอด้วย เช่น ถ้าจับภาพจาก Instagram ก็ควรมี URL นั้นติดไปด้วย, ในเบราว์เซอร์ก็ควรมี URL ปัจจุบันกับเส้นทาง DOM, ในแอปแผนที่ก็ควรมีพิกัด, ในตัวดู PDF ก็ควรมีค่าแฮช SHA1 และออฟเซ็ตของเอกสาร
แน่นอนว่ามี ปัญหาความเป็นส่วนตัว อยู่ แต่ผมคิดว่าไอเดียแบบนี้น่าจะถูกพูดถึงในแวดวงวิชาการมาบ้างแล้ว
ทุกวันนี้แนวคิดเรื่องไฟล์ถูกทำให้เป็นนามธรรมไปมาก จนรู้สึกว่าภาพหน้าจอกลายเป็นภาษากลางของยุคคอมพิวเตอร์พกพา
อีกอย่าง อยากขอพูดถึง Screenshot Conf ด้วย
ภาพหน้าจอถูกจัดการในระดับ OS ดังนั้นถ้าแอปรู้ว่าตัวเองถูกแคปหรือรู้ข้อมูลตำแหน่ง มันอันตรายมาก
บริษัทอย่าง Evernote หรือ CloudApp ก็เคยพยายามทำ แต่สุดท้ายก็ไม่สำเร็จ ภาพหน้าจอมีประโยชน์เพราะมันเรียบง่าย
ระบบที่ผมสร้างเก็บ ข้อมูลบริบท ไว้ใน URL เยอะมาก แต่ภาพหน้าจอไม่พกสิ่งนั้นมาด้วย
เลยต้องขอ URL ในรูปข้อความแยกต่างหาก อยู่เสมอ
หลังแคปหน้าจอ พวกเขาก็ใส่ฟีเจอร์อย่าง AI insight, การค้นหาสินค้า, การคุยกับ Gemini/LLM ลงใน UI
เพราะทุกคนใช้ภาพหน้าจอเพื่อเก็บหรือค้นข้อมูลกันหมด
แต่ถูกตัดออกจากเวอร์ชันที่ออกขาย เพราะกลัวคนจะเอาไปใช้แทนโปรแกรมประมวลผลคำ
ผมใช้ภาพหน้าจอบ่อยมาก
เพราะมันรักษาความกว้าง 80 ตัวอักษรไว้ได้ ทำให้ อ่านง่าย และยังคง ฟอนต์โมโนสเปซ กับ syntax highlighting ไว้ครบ
ถ้าอยากให้โค้ดหรือผลลัพธ์จากเทอร์มินัลไม่พังเวลาอยู่ในอีเมลหรือแชตบนมือถือ ภาพหน้าจอคือวิธีที่ชัวร์ที่สุด
แน่นอนว่าถ้าต้องใช้ทั้งไฟล์ผมก็แนบไฟล์ไป แต่ส่วนที่เกี่ยวข้องจะส่งเป็นภาพหน้าจอไปด้วย
ภาพหน้าจอต้องซูม และยังเสียเปรียบในด้านการเข้าถึง
ถ้าส่งเป็นข้อความก็ทั้งค้นหาและคัดลอกได้ง่ายกว่า
ระบบส่วนใหญ่รองรับฟอนต์โมโนสเปซอยู่แล้ว และปัญหาจริงๆ คือข้อจำกัดของสภาพแวดล้อมอย่าง การเรนเดอร์ของ Gmail มากกว่า
GMail ไม่มีข้อจำกัดด้านความกว้าง และขนาดฟอนต์ก็ไม่สม่ำเสมอจนอ่านยาก
ในกรณีของ URL ยาวๆ หรือหน้าจอกว้างๆ มันยิ่งทำให้ ความอ่านง่ายลดลง มากกว่าเดิม
เพราะสี รูปแบบ และบริบทมันอยู่ครบ
เวลาจะอธิบายปัญหา คำว่า “ภาพหนึ่งภาพมีค่ามากกว่าคำพูดพันคำ” ใช้ได้จริง
แบบนั้นผมจะได้ดูด้วย ฟอนต์, ความกว้าง, สีสัน ตามที่ชอบในเอดิเตอร์ของตัวเอง และยังค้นหาหรือแก้ไขได้
สุดท้ายภาพหน้าจอก็คือการสร้างความลำบากให้คนอื่น
ฟีเจอร์ การรู้จำข้อความและคัดลอกได้ บน Mac และ iOS นี่ถือว่าปฏิวัติจริงๆ
คุณคัดลอกข้อความจากภาพหน้าจอหรือรูปภาพ แล้วเอาไปวางในโน้ตได้ทันที
ตอนนั้นรู้สึกเลยว่า เราอยู่ในอนาคตแล้วจริงๆ
ใน Safari ยังแปลข้อความในภาพได้ด้วย ซึ่งมีประโยชน์มากโดยเฉพาะเวลาจะแปลเว็บภาษาญี่ปุ่น
มันทำงานได้เลยโดยไม่ต้องบันทึกไฟล์ก่อน สะดวกมาก
เมื่อก่อนคนชอบแปะภาพหน้าจอลงในเอกสาร Word แล้วส่งกัน
แต่ตอนนี้จะเสนอให้ ใช้ LLM ดึงข้อความกลับออกมาอีกที มันสิ้นเปลืองเกินไป
สิ่งที่ต้องการจริงๆ คือ นวัตกรรมด้าน UI ที่ทำให้การแชร์ข้อความง่ายพอๆ กับการแชร์ภาพหน้าจอ
เวลาเห็นคนที่อยากเป็นโปรแกรมเมอร์ทำแบบนี้แล้วมันน่าอึดอัดมาก
คือเอาไฟล์ Word อื่นมาแทรกเป็นอ็อบเจ็กต์จริงๆ ไว้ข้างในเอกสาร
กฎข้อ 7 ในบทความที่ผมเขียนเรื่อง ‘วิธีขอความช่วยเหลือใน Slack’ คือ “อย่าโพสต์ภาพหน้าจอของข้อความ”
ต่อให้ OCR ของ Apple ดีแค่ไหน ปัญหาเรื่อง ค้นหาไม่ได้ ก็ยังอยู่
ลิงก์ต้นฉบับ
ผมชอบส่งทั้งลิงก์ไปยังเอกสารหรือโค้ดเต็ม พร้อมกับแนบ ภาพหน้าจอของส่วนที่เกี่ยวข้อง ไปด้วย
เพราะบริบททางภาพยังอยู่ครบ ทำให้กลับมาดูทีหลังแล้ว จำได้ง่ายกว่า
นักพัฒนามือใหม่มักแชร์ ภาพหน้าจอของข้อความ บ่อยในช่วงสองสามสัปดาห์แรก
แต่เพราะมันอ่านยากบนมือถือ และ Slack ยังบีบอัดภาพจนซูมก็ไม่ชัด
สุดท้ายคนส่วนใหญ่ก็เรียนรู้ที่จะแชร์เป็นข้อความแทน
ใน MS Teams การรองรับโค้ดบล็อกแย่มากจนหลายครั้งต้องใช้ภาพหน้าจอแทน
มันมีฟีเจอร์นี้อยู่ แต่ซ่อนจนหาไม่ค่อยเจอ
ภาพหน้าจอเป็นวิธีที่ เร็วและสม่ำเสมอ
ไม่ว่าจะเป็นเว็บแอป แอปเนทีฟ หรือเว็บไซต์ มันก็ใช้วิธีเดียวกันได้หมด
ถึงผู้รับอาจไม่สะดวก แต่ในมุมของคนส่งมัน มีประสิทธิภาพ
บน Linux ผมตั้งค่าการทำงานแบบกำหนดเองของ xfce4-screenshooter ให้เชื่อมกับ สคริปต์ OCR ของ tesseract
พอแคปพื้นที่ที่เลือกไว้ ข้อความก็จะถูกคัดลอกเข้า clipboard โดยอัตโนมัติ
ถ้ากรณีไหนอ่านยาก ก็จะใช้ Gemma3-4B + llama.cpp
ทุกวันนี้เบราว์เซอร์ส่วนใหญ่มีฟีเจอร์ Text Fragment และผมก็ใช้งานมันได้อย่างมีประโยชน์มาก
ลองกดลิงก์ที่ไฮไลต์ไว้ในโพสต์นี้ เพื่อดูว่ามันทำงานหรือไม่