รีเฟรชสถาปัตยกรรมเครื่องมือสำหรับนักพัฒนาเว็บ: ย้ายข้อมูลไปยังโมดูล JavaScript

Tim van der Lippe
Tim van der Lippe

ดังที่คุณอาจทราบแล้ว เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome คือเว็บแอปพลิเคชันที่เขียนด้วย HTML, CSS และ JavaScript ตลอดหลายปีที่ผ่านมา เครื่องมือสำหรับนักพัฒนาเว็บมีฟีเจอร์ที่สมบูรณ์มากขึ้น ชาญฉลาดขึ้น และมีความรอบรู้เกี่ยวกับแพลตฟอร์มเว็บที่กว้างขึ้น แม้ว่า DevTools จะมีการขยายตัวมากขึ้นในช่วงหลายปีที่ผ่านมา แต่สถาปัตยกรรมส่วนใหญ่ยังคล้ายกับสถาปัตยกรรมดั้งเดิมตอนที่ยังเป็นส่วนหนึ่งของ WebKit

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

ช่วงแรกยังไม่มีอะไร

แม้ว่าภูมิทัศน์ของฟรอนท์เอนด์ในปัจจุบันจะมีระบบโมดูลที่หลากหลายพร้อมกับเครื่องมือต่างๆ ที่อยู่รอบๆ รวมถึงรูปแบบโมดูล JavaScript ที่ได้มาตรฐานในปัจจุบัน แต่ก็ไม่มีระบบโมดูลใดๆ อยู่เลยเมื่อสร้างเครื่องมือสำหรับนักพัฒนาเว็บเป็นครั้งแรก เครื่องมือสำหรับนักพัฒนาเว็บสร้างขึ้นจากโค้ดที่จัดส่งครั้งแรกใน WebKit มานานกว่า 12 ปี

การกล่าวถึงระบบโมดูลในเครื่องมือสำหรับนักพัฒนาเว็บเป็นครั้งแรกเกิดขึ้นในปี 2012 นั่นก็คือการแนะนำรายการโมดูลพร้อมรายการแหล่งที่มาที่เกี่ยวข้อง นี่เป็นส่วนหนึ่งของโครงสร้างพื้นฐานของ Python ที่ใช้สมัยนั้นเพื่อคอมไพล์และสร้างเครื่องมือสำหรับนักพัฒนาเว็บ การเปลี่ยนแปลงที่ตามมาได้แยกโมดูลทั้งหมดเป็นไฟล์ frontend_modules.json แยกต่างหาก (สัญญาผูกมัด) ในปี 2013 จากนั้นแยกเป็น module.json ไฟล์ (สัญญาผูกมัด) ในปี 2014

ตัวอย่างไฟล์ module.json

{
  "dependencies": [
    "common"
  ],
  "scripts": [
    "StylePane.js",
    "ElementsPanel.js"
  ]
}

ตั้งแต่ปี 2014 มีการใช้รูปแบบ module.json ในเครื่องมือสำหรับนักพัฒนาเว็บเพื่อระบุโมดูลและไฟล์ต้นฉบับ ในขณะเดียวกัน ระบบนิเวศของเว็บก็พัฒนาไปอย่างรวดเร็ว และมีการสร้างรูปแบบโมดูลที่หลากหลายขึ้น ซึ่งรวมถึง UMD, CommonJS และโมดูล JavaScript ที่ได้มาตรฐานในท้ายที่สุด แต่เครื่องมือสำหรับนักพัฒนาเว็บยังคงใช้รูปแบบ module.json อยู่

ในขณะที่เครื่องมือสำหรับนักพัฒนาเว็บยังคงใช้งานได้อยู่ จะมีข้อเสีย 2-3 ข้อจากการใช้ระบบโมดูลที่ไม่ได้มาตรฐานและไม่เหมือนใคร ดังนี้

  1. รูปแบบ module.json ต้องใช้เครื่องมือสร้างที่กำหนดเอง ซึ่งคล้ายกับ Bundler สมัยใหม่
  2. ไม่มีการผสานรวม IDE ซึ่งต้องใช้เครื่องมือที่กำหนดเองเพื่อสร้างไฟล์ที่ IDE สมัยใหม่เข้าใจได้ (สคริปต์ต้นฉบับในการสร้างไฟล์ jsconfig.json สำหรับ VS Code)
  3. ฟังก์ชัน คลาส และออบเจ็กต์ล้วนอยู่ในขอบเขตรวมทั้งหมดเพื่อให้แชร์ระหว่างโมดูลได้
  4. ไฟล์ขึ้นอยู่กับลำดับ ซึ่งหมายความว่าลำดับการแสดงรายการ sources มีความสำคัญ เราไม่รับประกันว่าโค้ดที่คุณต้องใช้จะโหลด นอกเสียจากว่ามนุษย์ได้ยืนยันโค้ดแล้ว

โดยสรุปแล้ว เมื่อประเมินสถานะปัจจุบันของระบบโมดูลในเครื่องมือสำหรับนักพัฒนาเว็บและรูปแบบโมดูลอื่นๆ (ที่ใช้กันอย่างแพร่หลายมากกว่า) เราได้ข้อสรุปว่ารูปแบบ module.json สร้างปัญหามากกว่าที่จะแก้ไขได้ และถึงเวลาแล้วที่เราควรจะเลิกใช้รูปแบบดังกล่าว

ประโยชน์ของมาตรฐาน

จากระบบโมดูลที่มีอยู่ เราเลือกโมดูล JavaScript เป็นโมดูลที่จะย้ายข้อมูลไป ในช่วงเวลาดังกล่าว โมดูล JavaScript การตัดสินใจนั้นยังคงส่งอยู่หลังจาก Flag ใน Node.js และแพ็กเกจจำนวนมากที่มีใน NPM ไม่มีแพ็กเกจโมดูล JavaScript ที่เราสามารถใช้ได้ อย่างไรก็ตาม เราได้ข้อสรุปว่าโมดูล JavaScript เป็นตัวเลือกที่ดีที่สุด

ประโยชน์หลักของโมดูล JavaScript คือเป็นรูปแบบโมดูลมาตรฐานสำหรับ JavaScript เมื่อพูดถึงข้อเสียของ module.json (ดูด้านบน) เราตระหนักดีว่าเกือบทุกกรณีเกี่ยวข้องกับการใช้รูปแบบโมดูลที่ไม่ได้มาตรฐานและไม่ซ้ำใคร

การเลือกรูปแบบโมดูลที่ไม่ได้มาตรฐานจะทำให้เราต้องทุ่มเทเวลาไปกับการสร้างการผสานรวมกับเครื่องมือการสร้างและเครื่องมือที่ผู้บำรุงรักษาใช้

การผสานรวมเหล่านี้มักไม่ยุ่งยากและขาดการสนับสนุนสำหรับฟีเจอร์ต่างๆ ทำให้ต้องใช้เวลาในการบำรุงรักษามากขึ้น บางครั้งจึงทำให้เกิดข้อบกพร่องเล็กๆ น้อยๆ ซึ่งในที่สุดจะจัดส่งไปยังผู้ใช้

และเนื่องจากโมดูล JavaScript เป็นโมดูลมาตรฐาน นั่นหมายความว่า IDE เช่น VS Code เครื่องมือตรวจสอบประเภท เช่น Closure Compiler/TypeScript และเครื่องมือสร้าง เช่น Rollup/minifiers จะเข้าใจซอร์สโค้ดที่เราเขียนได้ นอกจากนี้ เมื่อผู้บำรุงรักษารายใหม่เข้าร่วมทีมเครื่องมือสำหรับนักพัฒนาเว็บ ก็จะไม่ต้องเสียเวลาเรียนรู้รูปแบบ module.json ที่เป็นกรรมสิทธิ์ ดังที่ (น่าจะ) คุ้นเคยกับโมดูล JavaScript อยู่แล้ว

แน่นอนว่าเมื่อสร้างเครื่องมือสำหรับนักพัฒนาเว็บในตอนแรก ก็ไม่ได้ให้ประโยชน์ใดๆ ที่กล่าวมาเลย ต้องใช้เวลาหลายปีในการทำงานในกลุ่มมาตรฐาน การใช้งานรันไทม์ และนักพัฒนาซอฟต์แวร์ที่ใช้โมดูล JavaScript ในการให้ความคิดเห็นเพื่อทำงานให้ถึงจุดที่เป็นอยู่ในปัจจุบัน แต่เมื่อโมดูล JavaScript พร้อมให้ใช้งานแล้ว เรามีทางเลือกที่จะตัดสินใจคือ: รักษารูปแบบของเราเองต่อไปหรือจะเปลี่ยนไปใช้รูปแบบใหม่

ต้นทุนของแอปใหม่

แม้ว่าโมดูล JavaScript จะมีประโยชน์มากมายที่เราอยากจะใช้ แต่เรายังคงอยู่ในโลกของ module.json ที่ไม่เป็นไปตามมาตรฐาน การใช้ประโยชน์จากโมดูล JavaScript ทำให้เราต้องลงทุนจำนวนมากในการล้างหนี้ทางเทคนิค ดำเนินการย้ายข้อมูลที่อาจทำให้ฟีเจอร์เสียหายและทำให้เกิดข้อบกพร่องของการถดถอย

ในจุดนี้ คุณยังมีคำถามที่ว่า "เราต้องการใช้โมดูล JavaScript ไหม" แต่มีคำถามที่ว่า "การใช้โมดูล JavaScript มีค่าใช้จ่ายสูงแค่ไหน" เราต้องรักษาสมดุลระหว่างความเสี่ยงที่จะทำให้ผู้ใช้ใช้งานไม่ได้กับการถดถอย ต้นทุนที่วิศวกรต้องใช้เวลาไปกับการย้ายข้อมูล (จำนวนมาก) กับสถานการณ์ที่แย่ลงชั่วคราวที่เราจะต้องรับมือ

ประเด็นสุดท้ายนี้กลายเป็นสิ่งที่สำคัญมาก แม้ว่าในทางทฤษฎีแล้วเราสามารถไปยังโมดูล JavaScript ได้ แต่ระหว่างการย้ายข้อมูล เราจะลงเอยด้วยโค้ดที่จะต้องพิจารณาทั้ง module.json และโมดูล JavaScript สิ่งนี้ไม่เพียงแค่ยากที่จะบรรลุทางเทคนิค แต่ยังทำให้วิศวกรทุกคนที่พัฒนาเครื่องมือสำหรับนักพัฒนาเว็บต้องทราบวิธีทำงานในสภาพแวดล้อมนี้ด้วย พวกเขาจะต้องถามตัวเองอย่างต่อเนื่องว่า "สำหรับฐานของโค้ดส่วนนี้เป็นโมดูล module.json หรือ JavaScript และฉันจะทำการเปลี่ยนแปลงได้อย่างไร"

ตัวอย่าง: ค่าใช้จ่ายแอบแฝงจากการแนะนำเพื่อนผู้ดูแลผ่านการย้ายข้อมูลนั้นสูงกว่าที่เราคาดไว้

หลังจากวิเคราะห์ต้นทุน เราได้ข้อสรุปว่าการเปลี่ยนไปใช้โมดูล JavaScript นั้นยังคุ้มค่าอยู่ ดังนั้น เป้าหมายหลักของเรามีดังนี้

  1. ตรวจสอบว่าการใช้โมดูล JavaScript ได้รับผลประโยชน์สูงสุดเท่าที่จะเป็นไปได้
  2. ตรวจสอบว่าการผสานรวมกับระบบ module.json ที่มีอยู่นั้นปลอดภัยและไม่นำไปสู่ผลกระทบเชิงลบต่อผู้ใช้ (ข้อบกพร่องแบบถดถอย ความไม่สบายใจของผู้ใช้)
  3. แนะนำผู้บำรุงรักษาเครื่องมือสำหรับนักพัฒนาเว็บทั้งหมดเกี่ยวกับการย้ายข้อมูล โดยส่วนใหญ่จะมีการตรวจสอบและการสร้างสมดุลในตัวเพื่อป้องกันความผิดพลาดโดยไม่ตั้งใจ

สเปรดชีต การเปลี่ยนรูปแบบ และหนี้ทางเทคนิค

แม้เป้าหมายจะชัดเจน แต่ข้อจำกัดโดยรูปแบบ module.json ก็พิสูจน์ให้เห็นแล้วว่าแก้ไขได้ยาก ต้องทำซ้ำ สร้างต้นแบบ และเปลี่ยนแปลงสถาปัตยกรรมหลายครั้งกว่าจะคิดค้นโซลูชันที่เราถนัด เราเขียนเอกสารการออกแบบพร้อมกลยุทธ์การย้ายข้อมูลที่สรุปไว้ เอกสารการออกแบบยังได้ระบุระยะเวลาโดยประมาณเริ่มต้นของเราไว้ที่ 2-4 สัปดาห์ด้วย

ระวังสปอยล์: ส่วนที่เข้มข้นที่สุดของการย้ายข้อมูลใช้เวลา 4 เดือน และตั้งแต่เริ่มต้นจนจบใช้เวลา 7 เดือน!

อย่างไรก็ตาม แผนเริ่มต้นนั้นถือว่ามีการทดสอบอยู่ เราจะสอนให้รันไทม์ของเครื่องมือสำหรับนักพัฒนาเว็บโหลดไฟล์ทั้งหมดที่อยู่ในอาร์เรย์ scripts ในไฟล์ module.json โดยใช้วิธีเดิม ขณะที่ไฟล์ทั้งหมดในรายการในอาร์เรย์ modules ที่มีการนำเข้าโมดูล JavaScript แบบไดนามิก ไฟล์ที่อยู่ในอาร์เรย์ modules จะใช้การนำเข้า/ส่งออก ES ได้

นอกจากนี้ เราจะย้ายข้อมูลเป็น 2 ระยะ (สุดท้ายเราจะแบ่งระยะสุดท้ายเป็น 2 ระยะย่อย โปรดดูด้านล่าง ได้แก่ ระยะ export และ import สถานะของโมดูลที่จะอยู่ในระยะที่มีการติดตามในสเปรดชีตขนาดใหญ่:

สเปรดชีตการย้ายข้อมูลโมดูล JavaScript

ตัวอย่างข้อมูลของชีตความคืบหน้าจะแสดงต่อสาธารณะที่นี่

export เฟส

ขั้นตอนแรกคือการเพิ่มคำสั่ง export สำหรับสัญลักษณ์ทั้งหมดที่ควรจะมีการแชร์ระหว่างโมดูล/ไฟล์ การเปลี่ยนรูปแบบจะเป็นแบบอัตโนมัติโดยการเรียกใช้สคริปต์ต่อโฟลเดอร์ สัญลักษณ์ต่อไปนี้จะมีอยู่ในโลก module.json

Module.File1.exported = function() {
  console.log('exported');
  Module.File1.localFunctionInFile();
};
Module.File1.localFunctionInFile = function() {
  console.log('Local');
};

(ในที่นี้ Module คือชื่อของโมดูลและFile1ชื่อไฟล์ ในซอร์สโค้ดของเรา ค่าที่ได้จะเป็น front_end/module/file1.js)

โดยจะแปลงเป็นรูปแบบต่อไปนี้

export function exported() {
  console.log('exported');
  Module.File1.localFunctionInFile();
}
export function localFunctionInFile() {
  console.log('Local');
}

/** Legacy export object */
Module.File1 = {
  exported,
  localFunctionInFile,
};

ในช่วงแรก เรามีแผนที่จะเขียนการนำเข้าไฟล์เดียวกันใหม่ในขั้นตอนนี้ด้วย ตัวอย่างเช่น ในตัวอย่างด้านบน เราจะเขียน Module.File1.localFunctionInFile ใหม่เป็น localFunctionInFile อย่างไรก็ตาม เราเห็นว่าการนําไปใช้แบบอัตโนมัติจะง่ายกว่าและปลอดภัยยิ่งขึ้นหากแยกการเปลี่ยนรูปแบบทั้ง 2 นี้ออกจากกัน ดังนั้น "ย้ายสัญลักษณ์ทั้งหมดในไฟล์เดียวกัน" จะกลายเป็นระยะย่อยที่ 2 ของระยะ import

เนื่องจากการเพิ่มคีย์เวิร์ด export ในไฟล์เปลี่ยนรูปแบบไฟล์จาก "สคริปต์" เป็น "โมดูล" จึงต้องอัปเดตโครงสร้างพื้นฐานจำนวนมากของเครื่องมือสำหรับนักพัฒนาเว็บให้สอดคล้องกัน ซึ่งรวมถึงรันไทม์ (ที่มีการนำเข้าแบบไดนามิก) และมีเครื่องมืออย่างเช่น ESLint เพื่อเรียกใช้ในโหมดโมดูล

สิ่งหนึ่งที่เราค้นพบระหว่างที่แก้ไขปัญหาเหล่านี้คือ การทดสอบของเราทำงานในโหมด "เลอะเทอะ" เนื่องจากโมดูล JavaScript บอกเป็นนัยว่าไฟล์ทำงานในโหมด "use strict" จึงจะส่งผลต่อการทดสอบของเราด้วย ผลที่ได้คือการทดสอบจำนวนเล็กน้อยที่อาศัยความไม่สม่ำเสมอนี้ ซึ่งรวมถึงการทดสอบที่ใช้ข้อความ with \r

สุดท้าย การอัปเดตโฟลเดอร์แรกให้มีคำสั่ง export ใช้เวลาประมาณ 1 สัปดาห์และลองย้ายตำแหน่งหลายครั้ง

import เฟส

หลังจากส่งออกสัญลักษณ์ทั้งหมดโดยใช้คำสั่ง export แล้ว และยังคงอยู่ในขอบเขตส่วนกลาง (เดิม) เราจึงต้องอัปเดตการอ้างอิงสัญลักษณ์ข้ามไฟล์ทั้งหมดเพื่อใช้การนำเข้า ES เป้าหมายสูงสุดคือการนำ "ออบเจ็กต์การส่งออกเดิม" ทั้งหมดออก ซึ่งเป็นการล้างขอบเขตทั้งหมด การเปลี่ยนรูปแบบจะเป็นแบบอัตโนมัติโดยการเรียกใช้สคริปต์ต่อโฟลเดอร์

ตัวอย่างเช่น สำหรับสัญลักษณ์ต่อไปนี้ที่มีอยู่ในโลก module.json

Module.File1.exported();
AnotherModule.AnotherFile.alsoExported();
SameModule.AnotherFile.moduleScoped();

โดยมีการเปลี่ยนรูปแบบเป็นดังนี้

import * as Module from '../module/Module.js';
import * as AnotherModule from '../another_module/AnotherModule.js';

import {moduleScoped} from './AnotherFile.js';

Module.File1.exported();
AnotherModule.AnotherFile.alsoExported();
moduleScoped();

อย่างไรก็ตาม มีคำเตือนบางประการสำหรับวิธีการนี้ ดังนี้

  1. สัญลักษณ์บางตัวไม่ได้ตั้งชื่อเป็น Module.File.symbolName สัญลักษณ์บางตัวมีชื่อแค่ Module.File หรือแม้กระทั่ง Module.CompletelyDifferentName ซึ่งความไม่สอดคล้องกันนี้หมายความว่าเราต้องสร้างการแมปภายในจากออบเจ็กต์ส่วนกลางเก่าไปยังออบเจ็กต์ที่นำเข้าใหม่
  2. บางครั้งชื่อ Scoped อาจขัดแย้งกัน สิ่งที่โดดเด่นที่สุดคือ เราใช้รูปแบบการประกาศ Events บางประเภท โดยแต่ละสัญลักษณ์ตั้งชื่อแค่ Events ซึ่งหมายความว่าหากคุณฟังเหตุการณ์หลายประเภทที่ประกาศในไฟล์ต่างกัน การทับซ้อนของชื่อจะเกิดขึ้นในคำสั่ง import สำหรับ Events เหล่านั้น
  3. และพบว่ามีการขึ้นต่อกันซ้ำๆ ระหว่างไฟล์ ซึ่งทำได้ดีในบริบทของขอบเขตรวมทั้งหมด เนื่องจากการใช้สัญลักษณ์เกิดขึ้นหลังจากโหลดโค้ดทั้งหมดแล้ว อย่างไรก็ตาม หากต้องใช้ import ระบบจะระบุทรัพยากร Dependency แบบวงกลมไว้อย่างชัดเจน กรณีนี้จะไม่เป็นปัญหาในทันที เว้นแต่คุณจะมีการเรียกใช้ฟังก์ชันที่ส่งผลข้างเคียงในโค้ดขอบเขตรวมซึ่งเครื่องมือสำหรับนักพัฒนาเว็บก็ดำเนินการเช่นกัน โดยสรุปแล้ว เราต้องผ่าตัดและเปลี่ยนโครงสร้างภายในเพื่อทำให้การเปลี่ยนรูปแบบปลอดภัย

โลกใบใหม่กับโมดูล JavaScript

ในเดือนกุมภาพันธ์ 2020 หลังจากผ่านไป 6 เดือนหลังจากเริ่มต้นในเดือนกันยายน 2019 มีการดำเนินการการล้างข้อมูลครั้งล่าสุดในโฟลเดอร์ ui/ ซึ่งถือเป็นการสิ้นสุดการย้ายข้อมูลอย่างไม่เป็นทางการ หลังจากที่ปัญหาได้รับการแก้ไขแล้ว เราได้กำหนดสถานะการย้ายข้อมูลอย่างเป็นทางการว่าเสร็จสิ้นในวันที่ 5 มีนาคม 2020 🎉

ปัจจุบันโมดูลทั้งหมดในเครื่องมือสำหรับนักพัฒนาเว็บใช้โมดูล JavaScript เพื่อแชร์โค้ด เรายังคงใส่สัญลักษณ์บางอย่างไว้ในขอบเขตรวมทั้งหมด (ในไฟล์ module-legacy.js) สำหรับการทดสอบเดิมหรือผสานรวมกับส่วนอื่นๆ ของสถาปัตยกรรมเครื่องมือสำหรับนักพัฒนาเว็บ เราจะนำตัวเลือกเหล่านี้ออกเมื่อเวลาผ่านไปแต่จะไม่ถือว่านี่เป็นตัวบล็อกสำหรับการพัฒนาในอนาคต นอกจากนี้ยังมีคู่มือแนะนำการใช้งานโมดูล JavaScript อีกด้วย

สถิติ

ตัวเลขเชิงรับโดยประมาณสำหรับจำนวน CL (ตัวย่อของรายการการเปลี่ยนแปลง - คำที่ใช้ใน Gerrit ที่แสดงถึงการเปลี่ยนแปลง เช่นเดียวกับคำขอพุลของ GitHub) ที่เกี่ยวข้องกับการย้ายข้อมูลครั้งนี้มีประมาณ 250 CL ซึ่งส่วนใหญ่ดำเนินการโดยวิศวกร 2 คน เราไม่มีสถิติที่แน่นอนเกี่ยวกับขนาดของการเปลี่ยนแปลง แต่ค่าประมาณเชิงป้องกันของบรรทัดมีการเปลี่ยนแปลง (คำนวณจากผลรวมของความแตกต่างสัมบูรณ์ระหว่างการแทรกและการลบสำหรับแต่ละ CL) ประมาณ 30,000 (ประมาณ 20% ของโค้ดฟรอนท์เอนด์ของ DevTools ทั้งหมด)

ไฟล์แรกที่ใช้ export จัดส่งใน Chrome 79 ซึ่งมีการเผยแพร่เป็นเวอร์ชันเสถียรในเดือนธันวาคม 2019 การเปลี่ยนแปลงล่าสุดในการย้ายข้อมูลไปยัง import จะจัดส่งใน Chrome 83 และเปิดตัวเป็นเวอร์ชันเสถียรในเดือนพฤษภาคม 2020

เราทราบถึงการถดถอย 1 อย่างที่เกิดขึ้นใน Chrome เวอร์ชันเสถียร และได้เกิดขึ้นโดยเป็นส่วนหนึ่งของการย้ายข้อมูลนี้ การเติมข้อมูลโค้ดโดยอัตโนมัติในเมนูคำสั่งขัดข้องเนื่องจากมีการส่งออก default มากเกินไป เราพบการถดถอยอื่นๆ หลายครั้ง แต่ชุดทดสอบอัตโนมัติและผู้ใช้ Chrome Canary ได้รายงานปัญหาดังกล่าวและแก้ปัญหาเหล่านั้นก่อนที่จะสามารถเข้าถึงผู้ใช้เวอร์ชันเสถียรของ Chrome

คุณสามารถดูเส้นทางแบบเต็ม (CL บางรายการไม่ได้แนบมากับข้อบกพร่องนี้ แต่ส่วนใหญ่) จะบันทึกไว้ใน crbug.com/1006759

สิ่งที่เราได้เรียนรู้

  1. การตัดสินใจในอดีตอาจมีผลกระทบต่อโครงการในระยะยาว แม้ว่าโมดูล JavaScript (และรูปแบบโมดูลอื่นๆ) จะมีให้ใช้งานมาระยะหนึ่งแล้ว แต่เครื่องมือสำหรับนักพัฒนาเว็บก็ไม่อยู่ในสถานะที่จะรองรับการย้ายข้อมูล การตัดสินใจว่าจะย้ายข้อมูลเมื่อใดและเมื่อใดไม่ควรย้ายเป็นเรื่องยากและขึ้นอยู่กับการคาดเดาอย่างมีหลักการ
  2. เวลาเบื้องต้นโดยประมาณของเราอยู่ในระยะเวลาหลายสัปดาห์แทนที่จะเป็นเดือน ปัญหานี้มักเกิดจากการที่เราพบปัญหาที่ไม่คาดคิดมากกว่าที่คาดไว้ในการวิเคราะห์ต้นทุนครั้งแรกของเรา แม้ว่าแผนการย้ายข้อมูลจะมั่นคง แต่หนี้ทางเทคนิคก็เป็นตัวบล็อก (บ่อยครั้งกว่าที่เราจะทำได้)
  3. การย้ายโมดูล JavaScript นั้นรวมถึงการชำระหนี้ทางเทคนิคจำนวนมาก (ดูเหมือนจะไม่เกี่ยวข้อง) การเปลี่ยนไปใช้รูปแบบโมดูลมาตรฐานที่ทันสมัยช่วยให้เราปรับแนวทางปฏิบัติแนะนำในการเขียนโค้ดให้สอดคล้องกับการพัฒนาเว็บสมัยใหม่ได้ ตัวอย่างเช่น เราแทนที่ Bundler ของ Python ที่กำหนดเองด้วยการกำหนดค่า Rollup ขั้นต่ำได้
  4. แม้ว่าจะมีผลกระทบอย่างมากต่อฐานของโค้ด (ประมาณ 20% ของโค้ดเปลี่ยนแปลง) แต่ก็มีการรายงานการถดถอยน้อยมาก แม้เราจะมีปัญหาหลายอย่างในการย้ายข้อมูลไฟล์ 2-3 ไฟล์แรก แต่หลังจากนั้นเราก็มีเวิร์กโฟลว์ที่แข็งแกร่งและเป็นแบบอัตโนมัติบางส่วน ซึ่งหมายความว่าการเปลี่ยนแปลงนี้จะส่งผลในแง่ลบต่อผู้ใช้น้อยที่สุดของเรา
  5. การสอนความซับซ้อนของการย้ายข้อมูลบางอย่างไปให้กับเพื่อนผู้ดูแลเป็นเรื่องยากและบางครั้งก็ทำไม่ได้ การย้ายข้อมูลขนาดใหญ่เช่นนี้ทำตามได้ยากและต้องใช้ความรู้ด้านโดเมนอย่างมาก การถ่ายทอดความรู้ของโดเมนนั้นไปให้ผู้อื่นที่ทำงานในโค้ดเบสเดียวกันไม่เป็นที่น่าพอใจสำหรับงานที่ทำอยู่ การรู้ว่าควรแชร์อะไรและรายละเอียดที่ไม่ควรแชร์เป็นเรื่องศิลปะแต่จำเป็นต้องรู้ ดังนั้นจึงเป็นสิ่งสำคัญในการลดปริมาณการย้ายข้อมูลจำนวนมาก หรืออย่างน้อยที่สุดก็ไม่ต้องดำเนินการพร้อมกัน

ดาวน์โหลดช่องตัวอย่าง

ลองใช้ Chrome Canary, Dev หรือเบต้าเป็นเบราว์เซอร์สำหรับการพัฒนาเริ่มต้น ตัวอย่างช่องทางเหล่านี้จะช่วยให้คุณสามารถเข้าถึงฟีเจอร์ล่าสุดของเครื่องมือสำหรับนักพัฒนาเว็บ ทดสอบ API แพลตฟอร์มเว็บที่ล้ำสมัย และค้นหาปัญหาในเว็บไซต์ก่อนที่ผู้ใช้จะทำงานได้

ติดต่อทีมเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome

ใช้ตัวเลือกต่อไปนี้เพื่อพูดคุยเกี่ยวกับฟีเจอร์ใหม่ๆ และการเปลี่ยนแปลงในโพสต์หรือเรื่องอื่นๆ ที่เกี่ยวข้องกับเครื่องมือสำหรับนักพัฒนาเว็บ

  • ส่งคำแนะนำหรือความคิดเห็นถึงเราผ่าน crbug.com
  • รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บโดยใช้ตัวเลือกเพิ่มเติม   เพิ่มเติม   > ความช่วยเหลือ > รายงานปัญหาเกี่ยวกับเครื่องมือสำหรับนักพัฒนาเว็บในเครื่องมือสำหรับนักพัฒนาเว็บ
  • ทวีตที่ @ChromeDevTools
  • แสดงความคิดเห็นเกี่ยวกับ "มีอะไรใหม่ในวิดีโอ YouTube สำหรับเครื่องมือสำหรับนักพัฒนาเว็บ" หรือเคล็ดลับเครื่องมือสำหรับนักพัฒนาเว็บวิดีโอ YouTube