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

Tim van der Lippe
Tim van der Lippe
X GitHub

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

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

ตอนแรกไม่มีอะไร

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ค่าใช้จ่ายของ

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

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

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

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

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

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

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

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

โปรดทราบว่าการย้ายข้อมูลใช้เวลา 4 เดือนในส่วนที่เข้มข้นที่สุด และใช้เวลาทั้งหมด 7 เดือน

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

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

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

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

export-phase

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

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

(ในที่นี้ Module คือชื่อของโมดูลและ File1 คือชื่อของไฟล์ ใน Sourcetree ของเราจะเป็น 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 ในไฟล์จะเปลี่ยนไฟล์จาก "สคริปต์" เป็น "โมดูล" โครงสร้างพื้นฐานของ DevTools จํานวนมากจึงต้องได้รับการอัปเดตตามความเหมาะสม ซึ่งรวมถึงรันไทม์ (ที่มีการนําเข้าแบบไดนามิก) และเครื่องมือต่างๆ เช่น ESLint เพื่อทํางานในโหมดโมดูล

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

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

import-phase

หลังจากส่งออกสัญลักษณ์ทั้งหมดโดยใช้คำสั่ง 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. บางครั้งชื่อระดับโมดูลอาจทับซ้อนกัน สิ่งที่เห็นได้ชัดที่สุดคือเราใช้รูปแบบการประกาศ Events บางประเภท โดยตั้งชื่อสัญลักษณ์แต่ละรายการว่า Events ซึ่งหมายความว่าหากคุณกำลังรอเหตุการณ์หลายประเภทที่ประกาศไว้ในไฟล์ต่างๆ ระบบจะเกิดการทับซ้อนของชื่อในimport-statementสําหรับEventsเหล่านั้น
  3. ปรากฏว่าไฟล์มีการขึ้นต่อกันแบบเวียนกลับ ซึ่งใช้ได้ในบริบทขอบเขตส่วนกลาง เนื่องจากการใช้สัญลักษณ์เกิดขึ้นหลังจากโหลดโค้ดทั้งหมดแล้ว อย่างไรก็ตาม หากต้องการ import ระบบจะแสดงการขึ้นต่อกันแบบเวียนกลับอย่างชัดเจน ปัญหานี้ไม่ได้เกิดขึ้นทันที เว้นแต่คุณจะมีการเรียกใช้ฟังก์ชันที่มีผลข้างเคียงในโค้ดระดับส่วนกลาง ซึ่งเครื่องมือสำหรับนักพัฒนาเว็บก็มีเช่นกัน โดยรวมแล้ว เราต้องทำการแก้ไขและปรับโครงสร้างเพื่อให้การเปลี่ยนรูปแบบเป็นไปอย่างปลอดภัย

โลกใบใหม่ด้วยโมดูล JavaScript

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

ตอนนี้โมดูลทั้งหมดในเครื่องมือสำหรับนักพัฒนาเว็บใช้โมดูล JavaScript เพื่อแชร์โค้ด เรายังคงใส่สัญลักษณ์บางอย่างไว้ในขอบเขตส่วนกลาง (ในไฟล์ module-legacy.js) สำหรับการทดสอบเดิมหรือเพื่อผสานรวมกับส่วนอื่นๆ ของสถาปัตยกรรม DevTools เราจะนำรายการเหล่านี้ออกเมื่อเวลาผ่านไป แต่ไม่ได้มองว่าเป็นอุปสรรคในการพัฒนาในอนาคต นอกจากนี้ เรายังมีคู่มือสไตล์สำหรับการใช้โมดูล 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 (และโมดูลรูปแบบอื่นๆ) จะมีให้บริการมาระยะหนึ่งแล้ว แต่ DevTools ยังไม่พร้อมที่จะย้ายข้อมูล การตัดสินใจว่าจะย้ายข้อมูลหรือไม่นั้นเป็นเรื่องยากและขึ้นอยู่กับการคาดคะเนโดยอิงตามข้อมูลที่มีอยู่
  2. ค่าประมาณเวลาเริ่มต้นของเราคือเป็นสัปดาห์ ไม่ใช่เดือน สาเหตุหลักมาจากที่เราพบปัญหาที่ไม่คาดคิดมากกว่าที่คาดไว้ในการวิเคราะห์ต้นทุนเบื้องต้น แม้ว่าแผนการย้ายข้อมูลจะดี แต่หนี้ทางเทคนิคก็เป็นสิ่งที่ขัดขวาง (บ่อยกว่าที่เราต้องการ)
  3. การย้ายข้อมูลโมดูล JavaScript มีการล้างหนี้ทางเทคนิคจำนวนมาก (ดูเหมือนว่าจะไม่เกี่ยวข้องกัน) การย้ายข้อมูลไปยังรูปแบบโมดูลมาตรฐานสมัยใหม่ช่วยให้เราปรับแนวทางปฏิบัติแนะนำด้านการเขียนโค้ดให้สอดคล้องกับการพัฒนาเว็บในปัจจุบันได้ ตัวอย่างเช่น เราแทนที่เครื่องมือรวม Python ที่กําหนดเองด้วยการกำหนดค่า Rollup แบบขั้นต่ำได้
  4. แม้ว่าโค้ดเบสของเราจะมีการเปลี่ยนแปลงมาก (โค้ดประมาณ 20%) แต่เราก็พบการถดถอยเพียงเล็กน้อยเท่านั้น แม้ว่าเราจะพบปัญหามากมายในการย้ายข้อมูลไฟล์ 2-3 ไฟล์แรก แต่หลังจากผ่านไประยะหนึ่ง เราก็มีเวิร์กโฟลว์ที่มีประสิทธิภาพและทำงานอัตโนมัติได้บางส่วน ซึ่งหมายความว่าผู้ใช้ที่ใช้งานอย่างสม่ำเสมอได้รับผลกระทบเชิงลบน้อยที่สุดจากการย้ายข้อมูลครั้งนี้
  5. การสอนผู้ดูแลคนอื่นๆ เกี่ยวกับความซับซ้อนของการย้ายข้อมูลนั้นเป็นเรื่องยากและบางครั้งก็ทําไม่ได้ การย้ายข้อมูลในขนาดนี้มีความซับซ้อนและต้องใช้ความรู้ด้านโดเมนอย่างมาก การโอนความรู้เกี่ยวกับโดเมนนั้นให้กับผู้อื่นที่ทำงานในโค้ดเบสเดียวกันนั้นไม่เหมาะสําหรับงานที่ทำอยู่ การรู้ว่าควรแชร์อะไรและไม่ควรแชร์รายละเอียดใดเป็นศิลปะอย่างหนึ่งที่จำเป็น ดังนั้น คุณจึงควรลดจำนวนการย้ายข้อมูลขนาดใหญ่ หรืออย่างน้อยที่สุดก็ไม่ควรย้ายข้อมูลพร้อมกัน

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

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

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

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