ในไตรมาสสุดท้ายของปี 2019 ทีมเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ได้เริ่มปรับปรุงประสบการณ์การใช้งานของนักพัฒนาแอปในเครื่องมือสำหรับนักพัฒนาเว็บในเรื่องคุกกี้ ซึ่งเป็นเรื่องที่สำคัญอย่างยิ่งเนื่องจาก Google Chrome และเบราว์เซอร์อื่นๆ ได้เริ่มเปลี่ยนลักษณะการทำงานเริ่มต้นของคุกกี้
ขณะค้นคว้าข้อมูลเกี่ยวกับเครื่องมือที่เครื่องมือสำหรับนักพัฒนาเว็บมีให้ เรามักจะพบสถานการณ์ต่อไปนี้
😰 คอนโซลเต็มไปด้วยคำเตือนและข้อความแสดงข้อผิดพลาด แต่มีคำอธิบายทางเทคนิคมากกว่าและบางครั้งก็ลิงก์ไปยัง chromestatus.com ทุกข้อความก็มีความสำคัญพอๆ กัน ทำให้ยากที่จะรู้ว่าควรตอบเรื่องใดก่อน ที่สำคัญไปกว่านั้น ข้อความไม่ได้ลิงก์ไปยังข้อมูลเพิ่มเติมภายในเครื่องมือสำหรับนักพัฒนาเว็บ ซึ่งทำให้เข้าใจสิ่งที่เกิดขึ้นได้ยาก และสุดท้าย ข้อความมักจะส่งถึงนักพัฒนาเว็บเพื่อค้นหาวิธีแก้ไขปัญหา หรือเรียนรู้เกี่ยวกับบริบททางเทคนิค
และหากคุณใช้คอนโซลสำหรับรับข้อความจากแอปพลิเคชันของคุณเองด้วย บางครั้งการค้นหาข้อความระหว่างข้อความทั้งหมดจากเบราว์เซอร์อาจทำได้ยาก
เช่นเดียวกับมนุษย์ กระบวนการอัตโนมัติในการโต้ตอบกับข้อความในคอนโซลก็เป็นเรื่องยากเช่นกัน ตัวอย่างเช่น นักพัฒนาซอฟต์แวร์อาจใช้ Chrome Headless และ Puppeteer ในสถานการณ์การรวมอย่างต่อเนื่อง/การทำให้ใช้งานได้อย่างต่อเนื่อง เนื่องจากข้อความในคอนโซลเป็นเพียงสตริง นักพัฒนาแอปจึงต้องเขียนนิพจน์ทั่วไปหรือโปรแกรมแยกวิเคราะห์อื่นๆ เพื่อดึงข้อมูลที่ดำเนินการได้
โซลูชัน: การรายงานปัญหาแบบมีโครงสร้างและที่ดำเนินการได้
เราเริ่มคิดถึงข้อกำหนดและรวบรวมข้อกำหนดไว้ในเอกสารการออกแบบเพื่อหาวิธีแก้ปัญหาที่ดีกว่า
เป้าหมายของเราคือการแสดงปัญหาในลักษณะที่อธิบายปัญหาและวิธีแก้ไขอย่างชัดเจน ในกระบวนการออกแบบของเรา เราพบว่าปัญหาแต่ละรายการควรประกอบด้วย 4 ส่วนต่อไปนี้
- ชื่อ
- คำอธิบาย
- ลิงก์ไปยังทรัพยากรที่ได้รับผลกระทบภายในเครื่องมือสำหรับนักพัฒนาเว็บ
- และลิงก์ไปยังคำแนะนำเพิ่มเติม
ในส่วนของชื่อ เราอยากให้ชื่อที่สั้นและแม่นยำเพื่อช่วยให้นักพัฒนาแอปเข้าใจปัญหาหลัก และมักจะบอกเป็นนัยถึงการแก้ปัญหาไว้แล้วด้วย เช่น ปัญหาเกี่ยวกับคุกกี้มีข้อความว่า
ทำเครื่องหมายคุกกี้ข้ามเว็บไซต์ว่า "ปลอดภัย" เพื่ออนุญาตให้ตั้งค่าในบริบทแบบข้ามเว็บไซต์
ทุกปัญหามีรายละเอียดเพิ่มเติมในคำอธิบาย ซึ่งอธิบายสิ่งที่เกิดขึ้น ให้คำแนะนำที่นำไปใช้ได้จริงเกี่ยวกับวิธีแก้ปัญหา และลิงก์ไปยังแผงอื่นๆ ภายในเครื่องมือสำหรับนักพัฒนาเว็บเพื่อทำความเข้าใจปัญหาในบริบท นอกจากนี้ เรายังมีลิงก์ไปยังบทความเจาะลึกใน web.dev เพื่อให้นักพัฒนาเว็บได้เรียนรู้เกี่ยวกับหัวข้อนี้อย่างละเอียดมากขึ้น
ส่วนสำคัญของแต่ละปัญหาคือส่วนทรัพยากรที่ได้รับผลกระทบ ซึ่งจะลิงก์ไปยังส่วนอื่นๆ ของเครื่องมือสำหรับนักพัฒนาเว็บ และทำให้คุณตรวจสอบเพิ่มเติมได้ง่ายดาย ในตัวอย่างปัญหาเกี่ยวกับคุกกี้ ควรมีรายการคำขอเครือข่ายที่ก่อให้เกิดปัญหา และการคลิกที่คำขอจะนำคุณไปยังแผงเครือข่ายโดยตรง เราหวังว่าวิธีนี้จะไม่เพียงแต่ช่วยอำนวยความสะดวกเท่านั้น แต่ยังเป็นการตอกย้ำถึงแผงและเครื่องมือต่างๆ ในเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ที่สามารถใช้เพื่อแก้ไขข้อบกพร่องบางประเภทได้
เมื่อนึกถึงการโต้ตอบของนักพัฒนาซอฟต์แวร์กับแท็บปัญหาในระยะยาว เราคิดว่าการโต้ตอบกับนักพัฒนาแอปมีวิวัฒนาการดังต่อไปนี้
- เมื่อพบปัญหาหนึ่งๆ เป็นครั้งแรก นักพัฒนาเว็บจะอ่านบทความเพื่อทำความเข้าใจปัญหาในเชิงลึก
- เมื่อพบปัญหาในครั้งที่ 2 เราหวังว่าคำอธิบายปัญหาจะเพียงพอที่จะทำให้นักพัฒนาซอฟต์แวร์ทราบว่าปัญหาเกี่ยวข้องกับอะไร และอนุญาตให้นักพัฒนาแอปตรวจสอบและดำเนินการเพื่อแก้ไขปัญหาโดยทันที
- หลังจากพบปัญหา 2-3 ครั้ง เราหวังว่าชื่อปัญหาจะเพียงพอให้นักพัฒนาซอฟต์แวร์จดจำประเภทของปัญหาได้
สิ่งสำคัญอีกประการที่เราต้องการปรับปรุงคือการรวมข้อมูล ตัวอย่างเช่น หากคุกกี้เดียวกันทำให้เกิดปัญหาเดิมหลายครั้ง เราต้องการรายงานคุกกี้เพียงครั้งเดียว นอกจากจะลดจำนวนข้อความได้อย่างมากแล้ว วิธีนี้ยังช่วยให้ระบุสาเหตุหลักของปัญหาได้เร็วขึ้นอีกด้วย
การติดตั้งใช้งาน
ทางทีมจึงได้เริ่มหาวิธีนำฟีเจอร์ใหม่ดังกล่าวไปใช้ในการปฏิบัติตามข้อกำหนดเหล่านี้ โดยทั่วไปแล้ว โปรเจ็กต์สำหรับเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome จะครอบคลุม 3 ด้านที่แตกต่างกัน ดังนี้
- Chromium โครงการโอเพนซอร์สที่เขียนขึ้นด้วย C++ ซึ่งอยู่เบื้องหลัง Google Chrome
- ฟรอนท์เอนด์ของ DevTools คือการติดตั้งใช้งาน JavaScript ของเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
- โปรโตคอลเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome (CDP) ซึ่งเป็นเลเยอร์ที่เชื่อมต่อเครื่องมือทั้งสอง
การติดตั้งใช้งานจะประกอบไปด้วยงาน 3 อย่างดังนี้
- ใน Chromium เราต้องระบุคอมโพเนนต์ที่มีข้อมูลที่ต้องการแสดงและทำให้ข้อมูลนั้นเข้าถึงได้จากโปรโตคอล DevTools โดยไม่ลดความเร็วหรือความปลอดภัย
- จากนั้นเราจะต้องออกแบบโปรโตคอลเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome (CDP) เพื่อกำหนด API ที่แสดงข้อมูลแก่ไคลเอ็นต์ เช่น ฟรอนท์เอนด์ของเครื่องมือสำหรับนักพัฒนาเว็บ
- สุดท้ายคือเราต้องใช้คอมโพเนนต์ในฟรอนท์เอนด์ของ DevTools ที่ขอข้อมูลจากเบราว์เซอร์ผ่าน CDP และแสดงใน UI ที่เหมาะสม เพื่อให้นักพัฒนาซอฟต์แวร์ตีความและโต้ตอบกับข้อมูลได้อย่างง่ายดาย
ในส่วนของเบราว์เซอร์ก่อนนั้น เราได้พิจารณาวิธีจัดการข้อความคอนโซลก่อน เนื่องจากลักษณะการทำงานของข้อความนั้นคล้ายกับปัญหาที่เราคิดไว้มาก CodeSearch มักเป็นจุดเริ่มต้นที่ดีสำหรับการสำรวจแบบนี้ ซึ่งจะช่วยให้คุณค้นหาและสำรวจซอร์สโค้ดทั้งหมดของโปรเจ็กต์ Chromium ทางออนไลน์ได้ วิธีนี้จะช่วยให้เราได้เรียนรู้เกี่ยวกับการใช้ข้อความในคอนโซลและอาจทำให้มีวิธีทำงานพร้อมกันแต่มีโครงสร้างมากขึ้นจากข้อกำหนดที่เรารวบรวมสำหรับปัญหานั้นๆ
การดำเนินงานของที่นี่มีความท้าทายอย่างยิ่งเนื่องจากเราต้องคำนึงถึงผลกระทบด้านความปลอดภัยอยู่เสมอ โครงการ Chromium มีส่วนช่วยอย่างมากในการแยกสิ่งต่างๆ ออกเป็นกระบวนการต่างๆ และจัดให้มีการสื่อสารผ่านช่องทางการสื่อสารที่มีการควบคุมเท่านั้นเพื่อป้องกันการรั่วไหลของข้อมูล ปัญหาอาจมีข้อมูลที่ละเอียดอ่อน ดังนั้นเราต้องระมัดระวังที่จะไม่ส่งข้อมูลดังกล่าวให้กับส่วนใดๆ ของเบราว์เซอร์ที่ไม่ควรทราบข้อมูลดังกล่าว
ในฟรอนท์เอนด์ของเครื่องมือสำหรับนักพัฒนาเว็บ
โดยDevToolsเองเป็นเว็บแอปพลิเคชันที่เขียนด้วย JavaScript และ CSS ซึ่งก็คล้ายกับเว็บแอปพลิเคชันอื่นๆ อีกมาก เพียงแต่ว่าฟีเจอร์นี้เป็นมานานกว่า 10 ปีแล้ว และแน่นอนว่าแบ็กเอนด์เป็นช่องทางการสื่อสารโดยตรงกับเบราว์เซอร์ นั่นก็คือโปรโตคอลสำหรับนักพัฒนาเว็บใน Chrome
สําหรับแท็บ "ปัญหา" ในตอนแรกเราพิจารณาเรื่องราวของผู้ใช้และสิ่งที่นักพัฒนาแอปต้องทำเพื่อแก้ไขปัญหา แนวคิดของเราส่วนใหญ่พัฒนามาจากการใช้แท็บปัญหาเป็นจุดเริ่มต้นหลักในการตรวจสอบที่ลิงก์ผู้คนเข้ากับแผงซึ่งแสดงข้อมูลโดยละเอียดมากขึ้น เราตัดสินใจวางแท็บ "ปัญหา" ไว้กับแท็บอื่นๆ ที่ด้านล่างของเครื่องมือสำหรับนักพัฒนาเว็บ เพื่อให้แท็บดังกล่าวเปิดค้างไว้ได้ในขณะที่นักพัฒนาซอฟต์แวร์โต้ตอบกับคอมโพเนนต์อื่นของเครื่องมือสำหรับนักพัฒนาเว็บ เช่น แผง "เครือข่าย" หรือแผงแอปพลิเคชัน
ด้วยแนวทางนี้ นักออกแบบ UX ของเราจึงเข้าใจเป้าหมายของเราและได้สร้างต้นแบบของข้อเสนอเบื้องต้นต่อไปนี้
หลังจากแลกเปลี่ยนความเห็นมากมายเกี่ยวกับโซลูชันที่ดีที่สุด เราก็เริ่มปรับการออกแบบและทบทวนการตัดสินใจไปทีละน้อย แล้วค่อยๆ สรุปออกมาว่าแท็บปัญหามีลักษณะเป็นอย่างไรในปัจจุบัน
ปัจจัยที่สำคัญมากอีกอย่างคือความสามารถในการค้นพบได้ของแท็บปัญหา ที่ผ่านมา ฟีเจอร์ที่ยอดเยี่ยมต่างๆ ของเครื่องมือสำหรับนักพัฒนาเว็บไม่สามารถค้นพบได้โดยที่นักพัฒนาซอฟต์แวร์จะไม่ทราบว่าต้องมองหาสิ่งใดโดยเฉพาะ สำหรับแท็บ "ปัญหา" เราตัดสินใจไฮไลต์ปัญหาในหลายๆ ด้านเพื่อให้นักพัฒนาแอปไม่พลาดปัญหาที่สำคัญ
เราตัดสินใจเพิ่มการแจ้งเตือนลงในแผงคอนโซล เนื่องจากตอนนี้ข้อความบางอย่างในคอนโซลถูกนำออกเพราะจะทำให้เกิดปัญหา นอกจากนี้ เรายังเพิ่มไอคอนในตัวนับคำเตือนและข้อผิดพลาดที่ด้านขวาบนของหน้าต่างเครื่องมือสำหรับนักพัฒนาเว็บด้วย
สุดท้าย แท็บ "ปัญหา" ไม่เพียงลิงก์ไปยังแผงอื่นๆ ของเครื่องมือสำหรับนักพัฒนาเว็บเท่านั้น แต่แหล่งข้อมูลที่เกี่ยวข้องกับปัญหาจะลิงก์กลับไปยังแท็บ "ปัญหา" ด้วย
ในโปรโตคอล
การสื่อสารระหว่างฟรอนท์เอนด์และแบ็กเอนด์จะทำงานผ่านโปรโตคอลที่เรียกว่า Chromium DevTools Protocol (CDP) CDP อาจจัดเป็นแบ็กเอนด์ของเว็บแอปซึ่งก็คือ Chrome DevTools CDP แบ่งย่อยเป็นหลายโดเมน และทุกโดเมนประกอบด้วยคําสั่งและเหตุการณ์จำนวนหนึ่ง
สำหรับแท็บ "ปัญหา" เราตัดสินใจเพิ่มเหตุการณ์ใหม่ลงในโดเมนการตรวจสอบ ซึ่งจะเรียกใช้งานเมื่อพบปัญหาใหม่ โดเมนการตรวจสอบจะจัดเก็บปัญหาล่าสุดและนำส่งปัญหาเหล่านั้นทันทีที่มีการเชื่อมต่อเครื่องมือสำหรับนักพัฒนาเว็บ เพื่อให้แน่ใจว่าเราจะรายงานปัญหาที่เกิดขึ้นขณะที่ยังไม่เปิดเครื่องมือสำหรับนักพัฒนาเว็บได้ จากนั้นเครื่องมือสำหรับนักพัฒนาเว็บจะรวบรวมปัญหาเหล่านั้นทั้งหมดและรวบรวมปัญหาเหล่านั้น
CDP ยังช่วยให้ไคลเอ็นต์โปรโตคอลอื่นๆ เช่น Puppeteer รับและประมวลผลปัญหาได้ด้วย เราหวังว่าข้อมูลปัญหาที่มีโครงสร้างที่ส่งไปยัง CDP จะช่วยให้ผสานรวมกับโครงสร้างพื้นฐานของการผสานรวมอย่างต่อเนื่องที่มีอยู่ได้ง่ายขึ้น วิธีนี้จะช่วยให้ตรวจพบและแก้ไขปัญหาได้ตั้งแต่ก่อนที่จะมีการทำให้หน้าเว็บใช้งานได้
โปรไฟล์
ก่อนอื่น ต้องย้ายข้อความจำนวนมากจากคอนโซลไปยังแท็บปัญหา การดำเนินการนี้อาจใช้เวลาสักครู่ เนื่องจากเราต้องการมอบเอกสารประกอบที่ชัดเจนและนำไปดำเนินการได้สำหรับทุกปัญหาใหม่ที่เราเพิ่ม เราหวังว่าในอนาคตนักพัฒนาแอปจะมองหาปัญหาในแท็บ "ปัญหา" แทนในคอนโซล
นอกจากนี้ เรายังคิดหาวิธีผสานรวมปัญหาจากแหล่งที่มาอื่นๆ นอกเหนือจากแบ็กเอนด์ของ Chromium ไว้ในแท็บ "ปัญหา"
เรากำลังมองหาวิธีทำให้แท็บปัญหามีความเป็นระเบียบเรียบร้อยและปรับปรุงความสามารถในการใช้งาน การค้นหา การกรอง และการรวบรวมข้อมูลที่ดียิ่งขึ้นอยู่ในรายการของเราสำหรับปีนี้ ในการจัดโครงสร้างจำนวนปัญหาที่รายงานเพิ่มขึ้น เรากําลังดำเนินการเปิดตัวหมวดหมู่ปัญหาที่จะทำให้แสดงเฉพาะปัญหาที่เกี่ยวข้องกับการเลิกใช้งานที่กําลังจะเกิดขึ้นได้ เป็นต้น นอกจากนี้เรายังคิดที่จะเพิ่มฟีเจอร์เลื่อนการแจ้งเตือน เพื่อให้นักพัฒนาซอฟต์แวร์ใช้เพื่อซ่อนปัญหาชั่วคราวได้
เราต้องการทำให้การค้นหาส่วนใดของหน้าที่ก่อให้เกิดปัญหาได้ง่ายขึ้น เพื่อให้แก้ไขปัญหาได้ โดยเฉพาะอย่างยิ่ง เรากำลังคิดหาวิธีแยกแยะและกรองปัญหาที่มาจากหน้าเว็บของคุณ (เช่น บุคคลที่หนึ่ง) ออกจากปัญหาที่เกิดจากทรัพยากรที่คุณฝังอยู่ แต่ไม่ได้อยู่ภายใต้การควบคุมของคุณโดยตรง (เช่น เครือข่ายโฆษณา) ในขั้นแรก คุณจะซ่อนปัญหาคุกกี้ของบุคคลที่สามใน Chrome 86 ได้
หากคุณมีคำแนะนำในการปรับปรุงแท็บปัญหา โปรดแจ้งให้เราทราบโดยการส่งข้อบกพร่อง
ดาวน์โหลดช่องตัวอย่าง
ลองใช้ Chrome Canary, Dev หรือเบต้าเป็นเบราว์เซอร์สำหรับการพัฒนาเริ่มต้น ตัวอย่างช่องทางเหล่านี้จะช่วยให้คุณสามารถเข้าถึงฟีเจอร์ล่าสุดของเครื่องมือสำหรับนักพัฒนาเว็บ ทดสอบ API แพลตฟอร์มเว็บที่ล้ำสมัย และค้นหาปัญหาในเว็บไซต์ก่อนที่ผู้ใช้จะทำงานได้
ติดต่อทีมเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
ใช้ตัวเลือกต่อไปนี้เพื่อพูดคุยเกี่ยวกับฟีเจอร์ใหม่ๆ และการเปลี่ยนแปลงในโพสต์หรือเรื่องอื่นๆ ที่เกี่ยวข้องกับเครื่องมือสำหรับนักพัฒนาเว็บ
- ส่งคำแนะนำหรือความคิดเห็นถึงเราผ่าน crbug.com
- รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บโดยใช้ตัวเลือกเพิ่มเติม
> ความช่วยเหลือ > รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บในเครื่องมือสำหรับนักพัฒนาเว็บ - ทวีตที่ @ChromeDevTools
- แสดงความคิดเห็นเกี่ยวกับ "มีอะไรใหม่ในวิดีโอ YouTube สำหรับเครื่องมือสำหรับนักพัฒนาเว็บ" หรือเคล็ดลับเครื่องมือสำหรับนักพัฒนาเว็บวิดีโอ YouTube