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

Tim van der Lippe
Tim van der Lippe
X GitHub

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

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

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

  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 เฟส

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

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

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

ตอนนี้โมดูลทั้งหมดใน DevTools ใช้โมดูล 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 DevTools

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