โพสต์นี้เป็นส่วนหนึ่งของชุดบล็อกโพสต์ที่อธิบายการเปลี่ยนแปลงที่เราทำกับสถาปัตยกรรมของเครื่องมือสำหรับนักพัฒนาเว็บ และวิธีการสร้าง
หลังจากการย้ายข้อมูลไปยังโมดูล JavaScript และการย้ายข้อมูลไปยังคอมโพเนนต์ของเว็บ วันนี้เราจะมาดูบทความบล็อกโพสต์ต่อเรื่องการเปลี่ยนแปลงที่เรากำลังดำเนินการกับสถาปัตยกรรมของ Devtools (หากคุณยังไม่เคยเห็นมาก่อน เราได้โพสต์วิดีโอเกี่ยวกับงานการอัปเกรดสถาปัตยกรรมของเครื่องมือสำหรับนักพัฒนาเว็บไปเป็นเว็บที่ทันสมัย พร้อมเคล็ดลับ 14 ข้อเกี่ยวกับวิธีปรับปรุงโปรเจ็กต์เว็บของคุณ)
ในโพสต์นี้ เราจะอธิบายการเดินทางระยะเวลา 13 เดือนของเราในการย้ายจากเครื่องมือตรวจสอบประเภทการปิดไปยัง TypeScript
เกริ่นนำ
เนื่องจากฐานของโค้ดสำหรับเครื่องมือสำหรับนักพัฒนาเว็บมีขนาดใหญ่และความจำเป็นในการสร้างความมั่นใจให้กับวิศวกรที่ปฏิบัติงานเอง การใช้เครื่องมือตรวจสอบประเภทจึงเป็นสิ่งจำเป็น ด้วยเหตุนี้ DevTools ได้นำ Closure Compiler มาใช้ในปี 2013 การใช้การปิดทำให้วิศวกรเครื่องมือสำหรับนักพัฒนาเว็บทำการเปลี่ยนแปลงได้อย่างมั่นใจ คอมไพเลอร์ Closure จะทำการตรวจสอบประเภทเพื่อให้มั่นใจว่าการผสานรวมระบบทั้งหมดพิมพ์อย่างถูกต้อง
อย่างไรก็ตาม เมื่อเวลาผ่านไป เครื่องมือตรวจสอบประเภททางเลือกเริ่มได้รับความนิยมในการพัฒนาเว็บสมัยใหม่ ตัวอย่างที่เห็นได้ชัดคือ TypeScript และ Flow นอกจากนี้ TypeScript ยังได้กลายเป็นภาษาโปรแกรมอย่างเป็นทางการของ Google ด้วย แม้ว่าเครื่องมือตรวจสอบประเภทใหม่นี้ได้รับความนิยมมากขึ้น แต่เราก็สังเกตเห็นด้วยว่าเครื่องมือตรวจสอบประเภทการจัดส่งของเรามีปัญหาถดถอยการจัดส่ง เราจึงตัดสินใจประเมินเครื่องมือตรวจสอบประเภทที่เราเลือกอีกครั้ง และหาขั้นตอนต่อไปในการพัฒนาเครื่องมือสำหรับนักพัฒนาเว็บ
การประเมินเครื่องมือตรวจสอบประเภท
เนื่องจากเครื่องมือสำหรับนักพัฒนาเว็บใช้เครื่องมือตรวจสอบประเภทอยู่แล้ว คำถามที่จะให้เราตอบคือ
เรายังคงใช้ Closure Compiler หรือย้ายข้อมูลไปยังเครื่องมือตรวจสอบประเภทใหม่หรือไม่
ในการตอบคำถามนี้ เราจึงต้องประเมินเครื่องมือตรวจสอบประเภทโดยใช้ลักษณะเฉพาะหลายๆ อย่าง เนื่องจากการใช้งานเครื่องมือตรวจสอบประเภทของเราจะมุ่งเน้นที่ความเชื่อมั่นของวิศวกร แง่มุมที่สำคัญที่สุดสำหรับเราคือความถูกต้องของประเภท กล่าวคือ เครื่องมือตรวจสอบประเภทการค้นพบปัญหาที่แท้จริงมีความน่าเชื่อถือเพียงใด
การประเมินของเรามุ่งเน้นที่การถดถอยที่เราจัดส่งไปและระบุสาเหตุที่แท้จริงของปัญหา สมมติฐานคือเนื่องจากเราใช้ Closure Compiler อยู่แล้ว Closure จึงไม่พบปัญหาเหล่านี้ ดังนั้น เราจะต้องพิจารณาว่าเครื่องมือตรวจสอบประเภทอื่นๆ จะทำได้หรือไม่
พิมพ์ความถูกต้องใน TypeScript
เนื่องจาก TypeScript เป็นภาษาโปรแกรมที่ได้รับการสนับสนุนอย่างเป็นทางการที่ Google และได้รับความนิยมเพิ่มขึ้นอย่างรวดเร็ว เราจึงตัดสินใจประเมิน TypeScript ก่อน TypeScript เป็นตัวเลือกที่น่าสนใจ เนื่องจากทีม TypeScript เองใช้เครื่องมือสำหรับนักพัฒนาเว็บเป็นหนึ่งในโปรเจ็กต์ทดสอบเพื่อติดตามความเข้ากันได้กับการตรวจสอบประเภท JavaScript เอาต์พุตการทดสอบการอ้างอิงพื้นฐานแสดงให้เห็นว่า TypeScript พบปัญหาประเภทจำนวนมาก ซึ่งเป็นปัญหาที่คอมไพเลอร์ Closure อาจไม่ได้ตรวจพบ ปัญหาเหล่านี้มักเป็นต้นเหตุของปัญหาการจัดส่งที่เราถดถอย ทำให้เราเชื่อว่า TypeScript เป็นตัวเลือกที่ใช้งานได้ดีสำหรับเครื่องมือสำหรับนักพัฒนาเว็บ
ในระหว่างการย้ายข้อมูลไปยังโมดูล JavaScript เราพบว่า Closure Compiler พบปัญหามากกว่าที่เคย การเปลี่ยนไปใช้รูปแบบโมดูลมาตรฐานได้เพิ่มความสามารถของ Closure ในการทำความเข้าใจฐานของโค้ด ซึ่งช่วยเพิ่มประสิทธิภาพของเครื่องมือตรวจสอบประเภท อย่างไรก็ตาม ทีม TypeScript ได้ใช้เครื่องมือสำหรับนักพัฒนาเว็บเวอร์ชันพื้นฐานที่เผยแพร่ก่อนการย้ายข้อมูลโมดูล JavaScript ดังนั้น เราจึงต้องดูว่าการย้ายข้อมูลไปยังโมดูล JavaScript ได้ลดปริมาณข้อผิดพลาดที่คอมไพเลอร์ TypeScript จะตรวจจับได้ด้วยหรือไม่
การประเมิน TypeScript
เครื่องมือสำหรับนักพัฒนาเว็บมีมานานกว่า 10 ปี โดยได้เติบโตขึ้นจนกลายเป็นเว็บแอปพลิเคชันที่มีขนาดค่อนข้างใหญ่และมีฟีเจอร์เป็นจำนวนมาก ขณะที่เขียนบล็อกโพสต์นี้ DevTools มีโค้ด JavaScript ของบุคคลที่หนึ่งประมาณ 150,000 บรรทัด เมื่อเราเรียกใช้คอมไพเลอร์ TypeScript ในซอร์สโค้ดของเรา ปริมาณข้อผิดพลาดที่ท่วมท้นนั้นท่วมท้น เราพบว่าในขณะที่คอมไพเลอร์ TypeScript แสดงข้อผิดพลาดเกี่ยวกับการแปลงรหัสได้น้อยลง (ข้อผิดพลาดประมาณ 2,000 รายการ) แต่ก็ยังมีข้อผิดพลาดอีก 6,000 รายการในฐานของโค้ดที่เกี่ยวข้องกับความเข้ากันได้ของประเภท
สิ่งนี้แสดงให้เห็นว่าแม้ TypeScript จะเข้าใจวิธีแก้ไขประเภท แต่ก็พบความไม่เข้ากันของประเภทในฐานของโค้ดอยู่มาก
การวิเคราะห์ข้อผิดพลาดเหล่านี้ด้วยตนเองแสดงให้เห็นว่า TypeScript ถูกต้อง (ส่วนใหญ่)
เหตุผลที่ TypeScript สามารถตรวจพบข้อผิดพลาดเหล่านี้ได้และการปิดก็ไม่ใช่เพราะว่าคอมไพเลอร์ Closure มักจะอนุมานประเภทเป็น Any ในขณะที่ TypeScript จะอนุมานประเภทโดยอิงตามการกำหนดและอนุมานประเภทที่แม่นยำยิ่งขึ้น
ด้วยเหตุนี้ TypeScript จึงเข้าใจโครงสร้างของออบเจ็กต์และพบการใช้งานที่มีปัญหาได้ดียิ่งขึ้น
สิ่งหนึ่งที่สำคัญสำหรับเรื่องนี้คือ การใช้คอมไพเลอร์ Closure ใน DevTools จะมีการใช้งาน @unrestricted บ่อยครั้ง
การใส่คำอธิบายประกอบในคลาสด้วย @unrestricted จะปิดการตรวจสอบพร็อพเพอร์ตี้ที่เข้มงวดของคอมไพเลอร์การปิดสำหรับคลาสที่เฉพาะเจาะจงนั้นได้อย่างมีประสิทธิภาพ ซึ่งหมายความว่านักพัฒนาซอฟต์แวร์จะเพิ่มคำจำกัดความคลาสได้โดยไม่ต้องคำนึงถึงประเภทความปลอดภัยของประเภท
เราไม่พบบริบทที่ผ่านมาว่าเหตุใดการใช้ @unrestricted จึงแพร่หลายในฐานของโค้ดสำหรับ DevTools แต่ส่งผลให้การเรียกใช้คอมไพเลอร์ Closure ทำงานในโหมดปลอดภัยน้อยลงสำหรับฐานของโค้ดจำนวนมาก
การวิเคราะห์การถดถอยของเราแบบข้ามที่มีประเภทข้อผิดพลาด TypeScript พบว่ายังแสดงให้เห็นถึงการทับซ้อนกันด้วย ซึ่งทำให้เราเชื่อว่า TypeScript สามารถช่วยป้องกันปัญหาเหล่านี้ได้ (โดยที่ประเภทมีความถูกต้อง)
กำลังโทรออกด้วย any
ณ จุดนี้ เราต้องตัดสินใจว่าจะปรับปรุงการใช้งาน Closure Compiler หรือเปลี่ยนไปใช้ TypeScript (เนื่องจาก Google หรือ Chromium ไม่รองรับ Flow เราจึงต้องข้ามตัวเลือกนี้ไป) จากการพูดคุยกับเราและคำแนะนำจากวิศวกรของ Google ที่ทำงานกับเครื่องมือ JavaScript/TypeScript เราจึงเลือกใช้คอมไพเลอร์ TypeScript (เรายังได้เผยแพร่บล็อกโพสต์เกี่ยวกับการย้ายข้อมูล Puppeteer ไปยัง TypeScript ด้วย)
เหตุผลหลักสำหรับคอมไพเลอร์ TypeScript คือความถูกต้องของประเภทที่ได้รับการปรับปรุง ในขณะที่ข้อดีอื่นๆ ได้แก่ การสนับสนุนจากทีม TypeScript ภายในที่ Google และฟีเจอร์ต่างๆ ของภาษา TypeScript เช่น interfaces (แทนที่จะเป็น typedefs ใน JSDoc)
การเลือกคอมไพเลอร์ TypeScript ส่งผลให้เราต้องลงทุนอย่างมากในโค้ดเบสสำหรับนักพัฒนาเว็บและสถาปัตยกรรมภายใน ด้วยเหตุนี้ เราจึงประเมินว่าต้องใช้เวลาอย่างน้อย 1 ปีในการย้ายข้อมูลไปยัง TypeScript (กำหนดเป้าหมายไว้ในไตรมาสที่ 3 ปี 2020)
การดำเนินการย้ายข้อมูล
คำถามสำคัญที่สุดก็คือเราจะเปลี่ยนไปใช้ TypeScript ได้อย่างไร เรามีโค้ด 150,000 บรรทัดและเราไม่สามารถย้ายข้อมูลได้ในครั้งเดียว เรายังทราบด้วยว่าการเรียกใช้ TypeScript ในฐานของโค้ดจะทำให้พบข้อผิดพลาดนับพัน
เราได้ประเมินตัวเลือกหลายรายการ ดังนี้
- แก้ไขข้อผิดพลาด TypeScript ทั้งหมดและเปรียบเทียบกับเอาต์พุต "Golden" วิธีการนี้จะคล้ายกับในทีม TypeScript ข้อเสียที่สำคัญที่สุดของวิธีการนี้คือความขัดแย้งในการผสานรวมเกิดขึ้นเป็นจำนวนมาก เนื่องจากวิศวกรหลายสิบคนทำงานในฐานของโค้ดเดียวกัน
- ตั้งค่าประเภทที่เป็นปัญหาทั้งหมดเป็น
anyวิธีนี้จะทำให้ TypeScript ระงับข้อผิดพลาด เราไม่ได้เลือกตัวเลือกนี้ เนื่องจากเป้าหมายในการย้ายข้อมูลของเราคือความถูกต้องด้านประเภทที่การระงับจะส่งผลเสียต่อการทำงาน - แก้ไขข้อผิดพลาด TypeScript ทั้งหมดด้วยตนเอง กรณีนี้คุณจะต้องแก้ไขข้อผิดพลาดหลายพันรายการ ซึ่งใช้เวลานาน
ถึงแม้ว่าเราจะคาดหวังว่าจะเป็นอย่างสูง แต่เราเลือกตัวเลือกที่ 3 มีเหตุผลอื่นๆ เพิ่มเติมที่เราเลือกตัวเลือกนี้ ตัวอย่างเช่น วิธีนี้ช่วยให้เราสามารถตรวจสอบโค้ดทั้งหมด และทำการตรวจสอบฟังก์ชันทั้งหมดเพียงครั้งเดียว ซึ่งรวมถึงการติดตั้งใช้งานด้วย ในมุมมองทางธุรกิจ เราไม่ได้ให้คุณค่าใหม่ๆ แต่รักษาสถานภาพปัจจุบันไว้ ทำให้เลือกตัวเลือกที่ 3 เป็นตัวเลือกที่ถูกต้องได้ยากขึ้น
อย่างไรก็ตาม การใช้ TypeScript เราเชื่อเป็นอย่างยิ่งว่าเราสามารถป้องกันปัญหาในอนาคต โดยเฉพาะอย่างยิ่งเกี่ยวกับการถดถอย ด้วยเหตุนี้ อาร์กิวเมนต์จึงให้น้อยกว่า "เรากำลังเพิ่มมูลค่าทางธุรกิจใหม่" และ "เราเพิ่มความมั่นใจจะไม่สูญเสียมูลค่าทางธุรกิจที่ได้มา"
การสนับสนุน JavaScript ของคอมไพเลอร์ TypeScript
หลังจากตกลงซื้อและสร้างแผนที่จะใช้คอมไพเลอร์ Closure และ TypeScript ในโค้ด JavaScript เดียวกันแล้ว เราเริ่มจากไฟล์เล็กๆ ก่อน แนวทางของเราส่วนใหญ่นั้นอยู่ที่ตำแหน่งล่างสุด โดยเริ่มจากโค้ดหลักและขยับขึ้นไปในสถาปัตยกรรมไปเรื่อยๆ จนไปถึงแผงระดับสูง
เราทำให้งานของเราสอดคล้องกันด้วยการเพิ่ม @ts-nocheck ลงในไฟล์ทุกไฟล์ในเครื่องมือสำหรับนักพัฒนาเว็บล่วงหน้า กระบวนการ "การแก้ไข TypeScript" คือการนำคำอธิบายประกอบ @ts-nocheck ออกและแก้ไขข้อผิดพลาดใดๆ ที่ TypeScript พบ ซึ่งหมายความว่าเรามั่นใจว่าแต่ละไฟล์ได้รับการตรวจสอบแล้วและปัญหาประเภทมากที่สุดเท่าที่จะเป็นไปได้ได้รับการแก้ไขแล้ว
โดยทั่วไป วิธีการนี้ใช้ได้ผลดีเพียงไม่กี่ปัญหา เราพบข้อผิดพลาดหลายอย่างในคอมไพเลอร์ TypeScript แต่ข้อบกพร่องส่วนใหญ่ไม่ชัดเจน ดังนี้
- พารามิเตอร์ที่ไม่บังคับซึ่งมีประเภทฟังก์ชันซึ่งแสดงผล
anyจะถือว่าเป็นค่าที่จำเป็น: #38551 - การกำหนดพร็อพเพอร์ตี้ให้กับเมธอดคงที่ของการประกาศช่วงพักของชั้นเรียน: #38553
- การประกาศคลาสย่อยที่มีตัวสร้างที่ไม่มีอาร์กิวเมนต์และคลาสซูเปอร์ที่มีตัวสร้างอาร์กิวเมนต์ตัดตัวสร้างย่อย #41397
ข้อบกพร่องเหล่านี้ไฮไลต์ว่าสำหรับกรณี 99% นั้นคอมไพเลอร์ TypeScript จะเป็นรากฐานที่มั่นคงสำหรับการพัฒนา ใช่ ข้อบกพร่องที่ไม่ชัดเจนเหล่านี้อาจก่อให้เกิดปัญหาสำหรับเครื่องมือสำหรับนักพัฒนาเว็บ แต่ส่วนใหญ่แล้วข้อบกพร่องดังกล่าวไม่ชัดเจนพอที่จะแก้ปัญหาได้อย่างง่ายดาย
ปัญหาเดียวที่ทำให้เกิดความสับสนคือเอาต์พุตที่ไม่ได้กำหนดของไฟล์ .tsbuildinfo: #37156
ที่ Chromium เรากำหนดให้เวอร์ชัน 2 บิลด์ของ Chromium คอมมิตเดียวกันให้ผลลัพธ์เดียวกัน
ขออภัย วิศวกรบิลด์ของ Chromium พบว่าเอาต์พุตของ .tsbuildinfo เป็นแบบ crbug.com/1054494
ในการแก้ปัญหานี้ เราต้องรีบแพตช์ไฟล์ .tsbuildinfo (ซึ่งมี JSON) อยู่ก่อนแล้วประมวลผลเพื่อส่งคืนผลลัพธ์ที่กำหนด: https://crrev.com/c/2091448
โชคดีที่ทีม TypeScript แก้ไขปัญหาอัปสตรีมได้และในไม่ช้าเราก็นำวิธีแก้ปัญหาเบื้องต้นออกได้ ขอขอบคุณทีม TypeScript ที่เปิดรับรายงานข้อบกพร่องและแก้ไขปัญหาเหล่านี้อย่างทันท่วงที
โดยรวมแล้ว เราพอใจกับความถูกต้อง (ประเภท) ของคอมไพเลอร์ TypeScript เราหวังว่า Devtools ในฐานะที่เป็นโครงการ JavaScript โอเพนซอร์สขนาดใหญ่ได้ช่วยให้การสนับสนุน JavaScript ใน TypeScript แข็งแกร่งขึ้น
การวิเคราะห์ผลที่ตามมา
เราสามารถแก้ไขข้อผิดพลาดประเภทนี้ได้ดียิ่งขึ้น และค่อยๆ เพิ่มปริมาณโค้ดที่ TypeScript ตรวจสอบ อย่างไรก็ตาม ในเดือนสิงหาคม 2020 (9 เดือนหลังการย้ายครั้งนี้) เราได้ตรวจสอบข้อมูลแล้วและพบว่าเวลาปัจจุบันยังไม่ถึงกำหนดเวลา หนึ่งในวิศวกรของเราสร้างกราฟการวิเคราะห์เพื่อแสดงความคืบหน้าของ "TypeScriptification" (ชื่อที่เราตั้งให้กับการย้ายข้อมูลครั้งนี้)
ความคืบหน้าในการย้ายข้อมูล TypeScript - บรรทัดการติดตามโค้ดที่เหลืออยู่ซึ่งต้องมีการย้ายข้อมูล
การประมาณการตอนที่จะถึง 0 บรรทัดซึ่งเหลืออยู่ในช่วงเดือนกรกฎาคม 2021 ถึงธันวาคม 2021 ซึ่งผ่านกำหนดเวลาเกือบ 1 ปีมาแล้ว หลังจากพูดคุยกับฝ่ายบริหารและวิศวกรอื่นๆ เราตกลงที่จะเพิ่มจำนวนวิศวกรที่ทำงานเพื่อย้ายข้อมูลไปยังการสนับสนุนคอมไพเลอร์ TypeScript เราทำได้เนื่องจากเราออกแบบการย้ายข้อมูลให้พร้อมกันได้ โดยวิศวกรหลายคนที่ทำงานในไฟล์ต่างๆ กันหลายๆ ไฟล์จะไม่ขัดแย้งกัน
ณ จุดนี้ กระบวนการ TypeScriptification ได้กลายเป็นงานที่ต้องทำกันทั้งทีม ความช่วยเหลือเพิ่มเติมช่วยให้เราย้ายข้อมูลได้เสร็จสิ้นในสิ้นเดือนพฤศจิกายน 2020 หลังจากเริ่มต้นแล้ว 13 เดือน และย้ายข้อมูลได้กว่า 1 ปีก่อนที่จะมีการคาดการณ์เบื้องต้น
โดยรวมแล้ว มีรายการเปลี่ยนแปลง 771 รายการ (คล้ายกับคำขอแบบพุล) ที่ส่งมาโดยวิศวกร 18 คน ข้อบกพร่องในการติดตามของเรา (https://crbug.com/1011811) มีความคิดเห็นมากกว่า 1,200 รายการ (เกือบทั้งหมดเป็นโพสต์อัตโนมัติจากรายการการเปลี่ยนแปลง) ชีตติดตามของเรามีแถวกว่า 500 แถวสำหรับไฟล์ทั้งหมดที่จะพิมพ์ ผู้รับมอบหมาย และรายการการเปลี่ยนแปลงที่มีการ "พิมพ์"
การลดผลกระทบจากประสิทธิภาพของคอมไพเลอร์ TypeScript
ปัญหาใหญ่ที่สุดที่เรากำลังจัดการอยู่ตอนนี้คือคอมไพเลอร์ TypeScript ทำงานช้า เนื่องจากจำนวนวิศวกรที่สร้าง Chromium และเครื่องมือสำหรับนักพัฒนาเว็บ จุดคอขวดนี้จึงมีต้นทุนสูง น่าเสียดายที่เราไม่สามารถระบุความเสี่ยงนี้ก่อนการย้ายข้อมูลได้ และในตอนนั้นเราได้ย้ายข้อมูลไฟล์ส่วนใหญ่ไปยัง TypeScript เท่านั้น ซึ่งเราพบว่าเวลาที่ใช้ในแต่ละบิลด์ของ Chromium เพิ่มขึ้นอย่างเห็นได้ชัด https://crbug.com/1139220
เราได้รายงานปัญหานี้ไปยังทีมคอมไพเลอร์ Microsoft TypeScript แล้ว แต่ทีมพบว่าการทำงานดังกล่าวเกิดจากความจงใจ เราหวังว่าพวกเขาจะได้พิจารณาปัญหานี้อีกครั้ง แต่ในระหว่างนี้เรากำลังพยายามลดผลกระทบด้านประสิทธิภาพที่ช้าในฝั่ง Chromium ให้มากที่สุดเท่าที่จะเป็นไปได้
น่าเสียดายที่โซลูชันที่เราใช้อยู่ในปัจจุบันอาจไม่เหมาะกับผู้ร่วมให้ข้อมูลที่ไม่ใช่ Googler เสมอไป เนื่องจากการมีส่วนร่วมแบบโอเพนซอร์สใน Chromium มีความสำคัญมาก (โดยเฉพาะการมีส่วนร่วมจากทีม Microsoft Edge) เราจึงมุ่งมั่นมองหาตัวเลือกอื่นๆ ที่จะเหมาะกับผู้ให้ข้อมูลร่วมกันทุกคน อย่างไรก็ตาม ขณะนี้เรายังไม่ทราบโซลูชันทางเลือกที่เหมาะสม
สถานะปัจจุบันของ TypeScript ในเครื่องมือสำหรับนักพัฒนาเว็บ
ในขณะนี้ เราได้นำเครื่องมือตรวจสอบประเภทคอมไพเลอร์ Closure ออกจากฐานของโค้ดและใช้เฉพาะคอมไพเลอร์ TypeScript เท่านั้น เราสามารถเขียนไฟล์ที่สร้างโดย TypeScript และใช้ฟีเจอร์เฉพาะของ TypeScript (เช่น อินเทอร์เฟซ ทั่วไป ฯลฯ...) ซึ่งช่วยเราในชีวิตประจำวัน เรามั่นใจว่าคอมไพเลอร์ TypeScript จะตรวจจับข้อผิดพลาดประเภทและการถดถอยได้ ซึ่งเป็นสิ่งที่เราหวังว่าจะเกิดขึ้นเมื่อเราเริ่มย้ายข้อมูลนี้เป็นครั้งแรก การย้ายข้อมูลเช่นนี้เกิดขึ้นได้ช้า รายละเอียดเล็กๆ น้อยๆ และมักทำได้ยาก เป็นต้น แต่เมื่อเรามอบประโยชน์ให้แล้ว เราเชื่อว่ามันคุ้มค่า
ดาวน์โหลดช่องตัวอย่าง
ลองใช้ Chrome Canary, Dev หรือเบต้าเป็นเบราว์เซอร์สำหรับการพัฒนาเริ่มต้น ตัวอย่างช่องทางเหล่านี้จะช่วยให้คุณสามารถเข้าถึงฟีเจอร์ล่าสุดของเครื่องมือสำหรับนักพัฒนาเว็บ ทดสอบ API แพลตฟอร์มเว็บที่ล้ำสมัย และค้นหาปัญหาในเว็บไซต์ก่อนที่ผู้ใช้จะทำงานได้
ติดต่อทีมเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome
ใช้ตัวเลือกต่อไปนี้เพื่อพูดคุยเกี่ยวกับฟีเจอร์ใหม่ๆ และการเปลี่ยนแปลงในโพสต์หรือเรื่องอื่นๆ ที่เกี่ยวข้องกับเครื่องมือสำหรับนักพัฒนาเว็บ
- ส่งคำแนะนำหรือความคิดเห็นถึงเราผ่าน crbug.com
- รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บโดยใช้ตัวเลือกเพิ่มเติม
> ความช่วยเหลือ > รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บในเครื่องมือสำหรับนักพัฒนาเว็บ - ทวีตที่ @ChromeDevTools
- แสดงความคิดเห็นเกี่ยวกับ "มีอะไรใหม่ในวิดีโอ YouTube สำหรับเครื่องมือสำหรับนักพัฒนาเว็บ" หรือเคล็ดลับเครื่องมือสำหรับนักพัฒนาเว็บวิดีโอ YouTube