เผยแพร่: 7 พฤศจิกายน 2025
การจัดการความเข้ากันได้ของเบราว์เซอร์สำหรับลูกค้าองค์กรกว่า 38,000 รายทั่วญี่ปุ่นไม่ใช่เรื่องง่าย เมื่อ Kintone ขับเคลื่อนการดำเนินธุรกิจที่สำคัญสำหรับแอปพลิเคชันกว่า 1.5 ล้านรายการทุกวัน การตัดสินใจเกี่ยวกับการรองรับเบราว์เซอร์จึงมีความสำคัญ
Cybozu ซึ่งเป็นบริษัทซอฟต์แวร์กลุ่มชั้นนำในญี่ปุ่นเผชิญกับความท้าทายพื้นฐาน นั่นคือ วิธีรักษามาตรฐานเว็บที่สอดคล้องกันในผลิตภัณฑ์ต่างๆ ขณะเดียวกันก็หลีกเลี่ยงภาระในการบำรุงรักษาเมทริกซ์การรองรับเบราว์เซอร์ที่กำหนดเอง
วิธีแก้ปัญหา การใช้ Baseline เป็นมาตรฐานการพัฒนา ซึ่งเป็นการเปลี่ยนแปลงแนวทางในการนำฟีเจอร์ของแพลตฟอร์มเว็บมาใช้
ความท้าทาย: การรองรับเบราว์เซอร์โดยไม่ต้องคาดเดา
ก่อนที่จะใช้ Baseline นั้น Cybozu ได้กำหนดเกณฑ์การรองรับเบราว์เซอร์ของตนเองโดยอิงตามบันทึกการเข้าถึงและการติดตามเวอร์ชันด้วยตนเอง มาตรฐานของทีมคือการรองรับเบราว์เซอร์ที่ครอบคลุมบันทึกการเข้าถึง 98% แรก และผู้ใช้ที่ใช้เบราว์เซอร์ที่อยู่นอกเกณฑ์ดังกล่าวจะเห็นข้อความแจ้งให้อัปเดตเบราว์เซอร์
ในทุกไตรมาส ทีมวิศวกรของ Cybozu ใช้เวลาประมาณ 1 ชั่วโมงในการอัปเดตเกณฑ์ อย่างไรก็ตาม การผสานรวมเกณฑ์กับทีมพัฒนาไม่ได้ราบรื่น และมักจะมีคำถามว่าเมื่อใดจึงจะใช้ฟีเจอร์ CSS ใหม่ได้ เราจะนำ Polyfill สำหรับ JavaScript API ใหม่ๆ ออกได้เมื่อใด และฟีเจอร์ใดบ้างที่ใช้ได้ตอนนี้
เกณฑ์ที่กำหนดเองของ Cybozu ไม่เพียงแต่ขาดความสามารถในการบำรุงรักษาและความสามารถในการใช้งานสำหรับนักพัฒนาซอฟต์แวร์เท่านั้น แต่ยังตระหนักด้วยว่าการสร้างบนการตรวจหา User Agent และการติดตามเวอร์ชันด้วยตนเองไม่สามารถตามทันความเร็วของการพัฒนาเว็บสมัยใหม่ได้
User-Agent สตริงเชื่อถือได้ไหม
แนวทางก่อนหน้านี้ของ Cybozu คือการดึงชื่อและเวอร์ชันของเบราว์เซอร์จากสตริง User-Agent แล้วรวบรวมผลลัพธ์เหล่านี้เป็นข้อมูล "ผู้ใช้" แต่แนวทางนี้แสดงให้เห็นถึงความเป็นจริงของผู้ใช้ได้จริงหรือ
User-Agent คือส่วนหัวของคำขอ HTTP ซึ่งเป็นข้อมูลที่ไคลเอ็นต์ใดก็ได้อ้างว่าเป็นอะไรก็ได้ บันทึกการเข้าถึงผลิตภัณฑ์มีคำขอจำนวนมากจากบ็อต Crawler ผู้โจมตี และแหล่งที่มาอื่นๆ ไคลเอ็นต์บางรายตั้งใจส่งสตริง User-Agent เก่าเพื่อวัตถุประสงค์ต่างๆ เช่น การสแกนช่องโหว่ ดังนั้น บันทึกการเข้าถึงจึงไม่สามารถแสดงถึงผู้ใช้ที่ควรได้รับการสนับสนุน
User-Agent ไม่สามารถแสดงฟีเจอร์ที่พร้อมใช้งานได้
เวอร์ชันของเบราว์เซอร์ไม่ได้เชื่อมโยงกับฟีเจอร์ หมายเลขเวอร์ชันเดียวกันอาจมีความสามารถแตกต่างกัน ทั้งนี้ขึ้นอยู่กับเวอร์ชัน (เสถียร/เบต้า/ที่กำลังพัฒนา/Canary), ฟีเจอร์แฟล็ก, การทดสอบ Finch หรือนโยบายระดับองค์กร เป็นต้น นอกจากนี้ เบราว์เซอร์ต่างๆ ยังใช้ฟีเจอร์ในไทม์ไลน์ที่แตกต่างกันด้วย เช่น CSS Nesting เปิดตัวใน Safari 16.5 (พฤษภาคม 2023) แต่ Chrome 112 (เมษายน 2023) User-Agentสตริงไม่ได้บ่งบอกถึงความพร้อมใช้งานของฟีเจอร์
ความรับผิดชอบในการรองรับเวอร์ชันเบราว์เซอร์ด้วยตนเอง
การอัปเดตเบราว์เซอร์ไม่ได้มีแค่ฟีเจอร์ใหม่ๆ เท่านั้น แต่การเปิดตัวเบราว์เซอร์เป็นประจำยังรวมถึงแพตช์ความปลอดภัยที่สำคัญและการแก้ไขข้อบกพร่องควบคู่ไปกับความสามารถใหม่ๆ ด้วย เมื่อรองรับเวอร์ชันที่ล้าสมัยแล้ว การหลีกเลี่ยงการใช้ฟีเจอร์ใหม่ไม่ใช่ปัญหาเดียว แต่ยังเป็นการตัดสินใจที่ส่งผลต่อความปลอดภัยของผู้ใช้โดยตรงในเวลาเดียวกันด้วย ในสภาพแวดล้อมขององค์กร ผู้ใช้บางรายอาจพบข้อจำกัดที่ถูกต้อง เช่น
- องค์กรอาจมีนโยบายเบราว์เซอร์ที่เข้มงวดซึ่งป้องกันการอัปเดต
- ฮาร์ดแวร์รุ่นเดิมไม่รองรับการอัปเดตเบราว์เซอร์สมัยใหม่
- ผู้ใช้ในอุตสาหกรรมที่มีการกำกับดูแลซึ่งมีกระบวนการอนุมัติการเปลี่ยนแปลงที่ช้า
อย่างไรก็ตาม การสนับสนุนผู้ใช้เหล่านั้นก็หมายความว่าทำให้ผู้ใช้ยังคงมีความเสี่ยง
หากเกิดเหตุการณ์ด้านความปลอดภัยจากการใช้ช่องโหว่ที่ทราบในเบราว์เซอร์เวอร์ชันเก่า การอธิบายว่า "เบราว์เซอร์นี้รองรับเนื่องจากผู้ใช้ร้องขอ" ก็คงไม่ใช่เหตุผลที่สมเหตุสมผล หากการโจมตีแพร่กระจายไปยังผู้ใช้รายอื่นๆ ที่ดูแลเบราว์เซอร์ให้เป็นเวอร์ชันล่าสุดอย่างถูกต้อง นักพัฒนาแอปและผู้มีส่วนเกี่ยวข้องอื่นๆ ในโปรเจ็กต์จะต้องรับผิดชอบที่ไม่ได้หยุดการสนับสนุนเบราว์เซอร์ที่ไม่ปลอดภัย
Cybozu ตระหนักว่าแนวทางนี้สร้างความเสี่ยงให้กับผู้ใช้ส่วนใหญ่ที่อัปเดตเบราว์เซอร์อยู่เสมอ การรองรับเบราว์เซอร์ตามจำนวนบันทึกเพียงอย่างเดียวไม่มีการตรวจสอบความปลอดภัยที่เหมาะสม การไม่รองรับฟีเจอร์ใหม่ๆ ไม่ได้เป็นเพียงแค่การพลาดโอกาส แต่เป็นการละเลยความรับผิดชอบในการปกป้องผู้ใช้
คำถามเปลี่ยนจาก "มีผู้ใช้ที่ใช้เวอร์ชันนี้กี่คน" เป็น "เราควรให้การสนับสนุนผู้ใช้ตามเวอร์ชันของเบราว์เซอร์หรือไม่"
เหตุผลที่ Baseline เป็นคำตอบที่เหมาะสมสำหรับ Cybozu
Cybozu ต้องการแนวทางใหม่ที่ไม่เพียงแต่แก้ปัญหาค่าใช้จ่ายในการดำเนินงานของการรักษาเกณฑ์การรองรับเบราว์เซอร์ แต่ยังแก้ปัญหาข้อบกพร่องพื้นฐานในระเบียบวิธีเก่าด้วย Baseline ช่วยให้ Cybozu ได้รับสิ่งที่ต้องการ
เกณฑ์ที่ได้รับการปรับปรุงอย่างต่อเนื่องและได้รับการดูแลจากภายนอก
Baseline จะมอบเป้าหมายที่เปลี่ยนแปลงไปซึ่งดูแลโดย WebDX Community Group ของ W3C แทนที่จะต้องประเมินเวอร์ชันเบราว์เซอร์ใหม่ด้วยตนเองทุกไตรมาส ซึ่งไม่ใช่การตัดสินใจโดยพลการของแต่ละบริษัท ซึ่งหมายความว่าเกณฑ์จะพัฒนาไปโดยอัตโนมัติตามข้อมูลจากผู้ให้บริการเบราว์เซอร์และองค์กรที่กำหนดมาตรฐาน
Kintone ไม่จำเป็นต้องจัดการเกณฑ์เวอร์ชันด้วยตนเองอีกต่อไป เนื่องจาก Baseline จะพัฒนาไปโดยอัตโนมัติ สถานะพื้นฐานของฟีเจอร์จะตอบคำถามเกี่ยวกับความพร้อมใช้งานได้อย่างชัดเจน และคำตอบจะอัปเดตตัวเองเมื่อแพลตฟอร์มมีการพัฒนา
ความแม่นยำระดับฟีเจอร์
Baseline ใช้วิธีการที่แตกต่างอย่างสิ้นเชิงแทนที่จะพยายามติดตามสถานการณ์ของเบราว์เซอร์แต่ละรายการ
Baseline Widely available หมายถึงฟีเจอร์ของเว็บที่พร้อมใช้งานมานานกว่า 30 เดือนในเบราว์เซอร์หลัก กรอบเวลานี้กำหนดขึ้นเพื่อ "ประมาณสัญญาณของนักพัฒนาแอป การยอมรับการเปิดตัวเบราว์เซอร์เมื่อเวลาผ่านไป การประมาณการรองรับส่วนแบ่งการตลาดทั้งหมดสูง และการตัดสินใจที่ดีที่สุดของกลุ่มชุมชน WebDX" การตั้งค่าเกณฑ์นี้จะช่วยให้ Baseline ไม่ต้องติดตามสถานการณ์ของเบราว์เซอร์แต่ละรายการที่สังเกตไม่ได้
Baseline จะช่วยให้นักพัฒนาซอฟต์แวร์ได้รับคำตอบโดยตรงเกี่ยวกับความพร้อมใช้งานของฟีเจอร์นั้นๆ ในเบราว์เซอร์ต่างๆ ตอนนี้คำถาม "เราใช้การค้นหาคอนเทนเนอร์ CSS ได้ไหม" เป็นคำถามที่ตอบได้แล้ว นักพัฒนาแอปสามารถตรวจสอบสถานะ Baseline ใน MDN หรือเอกสารอื่นๆ ได้ทันทีโดยไม่ต้องอ้างอิงเมทริกซ์ความเข้ากันได้
ออกแบบมาโดยคำนึงถึงความปลอดภัย
การนำ Baseline Widely available มาใช้เป็นมาตรฐานทำให้ Cybozu ปรับนโยบายการสนับสนุนให้สอดคล้องกับกรอบเวลาที่สัมพันธ์กับวงจรการสนับสนุนของผู้ให้บริการเบราว์เซอร์โดยธรรมชาติ เบราว์เซอร์ที่ยังคงได้รับการบำรุงรักษาอย่างต่อเนื่องจะรองรับฟีเจอร์ทั้งหมดที่พร้อมใช้งานในวงกว้าง รวมถึงจะได้รับการอัปเดตความปลอดภัยที่สำคัญด้วย
เกณฑ์ที่อิงตามบันทึกการเข้าถึงอาจทำให้การสนับสนุนยึดติดกับเบราว์เซอร์ที่ล้าสมัย ซึ่งจะทำให้ผู้ใช้ไม่มีแรงจูงใจในการอัปเดต การใช้ Baseline ไม่เพียงช่วยให้เราใช้ฟีเจอร์ที่ทันสมัยได้อย่างมั่นใจเท่านั้น แต่ผู้ใช้เบราว์เซอร์รุ่นเก่าจะเห็นความจำเป็นในการอัปเดตเมื่อแพลตฟอร์มเว็บก้าวไปข้างหน้า
Baseline ไม่ได้ยกเว้นเบราว์เซอร์ที่มีช่องโหว่อย่างชัดเจน แต่จะให้แรงจูงใจตามธรรมชาติแก่ผู้ใช้ในการอัปเดตเบราว์เซอร์อยู่เสมอ
การใช้เกณฑ์พื้นฐาน
การใช้ Baseline ต้องเปลี่ยนจากการจัดการเวอร์ชันเดิมของ Cybozu ซึ่งหมายความว่า Cybozu ต้องมั่นใจว่า Baseline จะทำงานได้โดยไม่มีข้อเสียที่สำคัญ การทราบว่าผู้ใช้กี่เปอร์เซ็นต์ที่จะได้รับผลกระทบเป็นสิ่งสำคัญสำหรับการนำไปใช้ในระดับองค์กร
เครื่องมือตรวจสอบเกณฑ์พื้นฐานของ Google Analytics คือเครื่องมือที่วิเคราะห์ข้อมูลที่ส่งออกจาก Google Analytics เพื่อแสดงเปอร์เซ็นต์ของผู้ใช้ที่รองรับฟีเจอร์จากเกณฑ์พื้นฐานแต่ละปี เครื่องมือนี้ช่วยให้ Cybozu ตรวจสอบผลกระทบที่แท้จริงของการเลือกเป้าหมายพื้นฐานต่อผู้ใช้ได้ หลังจากเรียกใช้เครื่องมือตรวจสอบพื้นฐานแล้ว Cybozu ก็พบสิ่งหนึ่งที่น่าทึ่ง
Baseline Checker แสดงให้เห็นว่าผู้ใช้ Cybozu 98.8% ใช้เบราว์เซอร์ที่รองรับเป้าหมาย Baseline ที่พร้อมใช้งานอย่างกว้างขวาง ซึ่งครอบคลุมมากกว่ามาตรฐานภายในก่อนหน้านี้ของ Cybozu ที่ผู้ใช้ต้องมีอย่างน้อย 98% เราวิเคราะห์ประเด็นสำคัญ 3 ประเด็นได้โดยอิงตามข้อมูลที่ให้ไว้ ดังนี้
- เบราว์เซอร์ที่รองรับก่อนหน้านี้จะไม่ได้รับผลกระทบ
- เบราว์เซอร์ที่ไม่รองรับก่อนหน้านี้: คิดเป็นประมาณ 0.8% ที่เป็นไปตามเกณฑ์พื้นฐานที่พร้อมใช้งานในวงกว้าง แต่จะไม่เห็นข้อความแจ้งให้อัปเดตเบราว์เซอร์อีกต่อไป
- เบราว์เซอร์ที่เหลือจะยังคงได้รับข้อความแจ้งให้อัปเดตเบราว์เซอร์เช่นเดิม
ที่สำคัญคือการดำเนินการนี้หมายความว่าเราสามารถกำจัดผลบวกลวงได้ ซึ่งก็คือผู้ใช้ประมาณ 0.8% ที่ได้รับคำเตือนโดยไม่จำเป็นแม้ว่าจะใช้เบราว์เซอร์ที่รองรับก็ตาม ในขณะเดียวกัน เราก็ไม่สามารถทำให้เกิดผลลบลวงโดยการเตือนผู้ใช้ที่เคยได้รับการสนับสนุน
ข้อมูลนี้ช่วยให้ Cybozu มั่นใจที่จะใช้ Baseline Widely available เป็นเป้าหมาย
ผลกระทบของ Baseline ในทางปฏิบัติ
การนำ Baseline มาใช้เป็นนโยบายเป็นเรื่องหนึ่ง แต่การทำให้ใช้งานได้จริงต้องสร้างเครื่องมือและกระบวนการ ซึ่งจำเป็นต้องทำเพื่อให้แน่ใจว่านักพัฒนาแอปจะไม่ใช้ฟีเจอร์ที่ไม่รองรับโดยไม่ตั้งใจโดยไม่ต้องตรวจสอบสถานะพื้นฐานด้วยตนเอง
การวิเคราะห์แบบคงที่ตามการกำหนดค่า ESLint
@cybozu/eslint-config คือการกำหนดค่าที่อิงตาม OSS ซึ่งใช้ในผลิตภัณฑ์ Cybozu โดยเริ่มรองรับตั้งแต่ค่าที่กำหนดล่วงหน้า css-baseline ซึ่งจะตรวจสอบฟีเจอร์ CSS กับ Baseline ในเวลาที่สร้าง
// eslint.config.mjs
import cybozuEslintConfigBaseline from '@cybozu/eslint-config/flat/presets/css-baseline.js';
export default [
...cybozuEslintConfigBaseline.map((config) => ({
...config,
files: ['**/*.css']
})),
];
เมื่อนักพัฒนาซอฟต์แวร์ใช้ฟีเจอร์ที่ยังไม่พร้อมใช้งานใน Baseline อย่างแพร่หลาย นักพัฒนาซอฟต์แวร์จะได้รับความคิดเห็นจาก ESLint ทันที
ซึ่งจะช่วยป้องกันไม่ให้ปัญหาความเข้ากันได้ส่งผลกระทบต่อเวอร์ชันที่ใช้งานจริง นักพัฒนาแอปสามารถตัดสินใจโดยอิงตามข้อมูลในช่วงต้นของกระบวนการพัฒนาได้ ไม่ว่าจะรอให้ฟีเจอร์พร้อมใช้งานอย่างแพร่หลาย หรือจะใช้การเพิ่มประสิทธิภาพแบบค่อยเป็นค่อยไปโดยทราบว่าผู้ใช้กลุ่มใดจะได้รับผลกระทบ (ดูข้อมูลเพิ่มเติมเกี่ยวกับการรองรับ CSS และ Baseline ของ ESLint)
กำหนดค่าตัวแปลงภาษาเพื่อกำหนดเป้าหมาย Baseline Widely available
เครื่องมือบิลด์สมัยใหม่เริ่มรองรับ Baseline เป็นเป้าหมายแล้ว เช่น Vite จะกำหนดเป้าหมายเป็น Baseline Widely Available ในการใช้งานจริงโดยอัตโนมัติโดยไม่ต้องกำหนดค่าเพิ่มเติม ตอนนี้ Browserslist รองรับ Baseline ด้วย
การใช้การตั้งค่าคอมไพเลอร์ต่างๆ ช่วยให้มั่นใจได้ว่า JavaScript และ CSS จะได้รับการแปลงเมื่อจำเป็นเท่านั้น ซึ่งจะหลีกเลี่ยงการเปลี่ยนรูปแบบและโพลีฟิลล์ที่ไม่จำเป็นสำหรับฟีเจอร์ที่ได้รับการรองรับอย่างกว้างขวางอยู่แล้ว
ไม่ต้องบำรุงรักษาเกณฑ์ด้วยตนเองและระบบตรวจหาเบราว์เซอร์สำหรับความคิดเห็นของผู้ใช้
การบำรุงรักษาที่ประสบความสำเร็จมากที่สุดมาจากการไม่ต้องติดตามเวอร์ชันเบราว์เซอร์ด้วยตนเอง ปัจจุบัน Cybozu ใช้แพ็กเกจ @web-platform-dx/baseline-browser-mapping ที่ได้รับการดูแลอย่างเปิดเผยเพื่อตอบคำถามเหล่านี้แทนการประชุมรายไตรมาสเพื่อถกเถียงว่าจะรองรับเบราว์เซอร์เวอร์ชันใด
นอกจากนี้ Cybozu ยังสร้างการตรวจหาเบราว์เซอร์อัตโนมัติเพื่อแสดงข้อความแจ้งให้อัปเกรดแก่ผู้ใช้ที่ใช้เบราว์เซอร์เวอร์ชันเก่า
การตรวจหาเบราว์เซอร์จะดึงข้อมูลเวอร์ชันเบราว์เซอร์ที่เข้ากันได้จากแพ็กเกจ @web-platform-dx/baseline-browser-mapping โดยตรง
ซึ่งจะทำงานในระหว่างกระบวนการสร้าง และสร้างแบนเนอร์คำเตือนที่ แชร์ในทีมผลิตภัณฑ์ทั้งหมด เมื่อหน้าต่าง "พร้อมใช้งานในวงกว้าง" ของ Baseline เปลี่ยนไป เพื่อรวมเบราว์เซอร์รุ่นใหม่ๆ ระบบจะตรวจหาการเปลี่ยนแปลงโดยอัตโนมัติโดยไม่ต้อง มีการแทรกแซงด้วยตนเอง
การสื่อสารที่มีประสิทธิภาพ
ประโยชน์ที่สำคัญที่สุดแต่ไม่คาดคิดอย่างหนึ่งคือวิธีที่ Baseline ช่วยลดความซับซ้อนของการสื่อสารระหว่างทีม ก่อนหน้านี้ การพูดคุยเรื่องความเข้ากันได้ของเบราว์เซอร์ต้องใช้ความรู้เกี่ยวกับโดเมนของบริษัท ซึ่งรวมถึงเบราว์เซอร์ที่เรารองรับ เวอร์ชันที่รองรับ และฟีเจอร์ที่พร้อมใช้งานในปัจจุบัน ผู้มาใหม่ต้องใช้เวลาในการเรียนรู้มาตรฐานภายใน ของเรา ตอนนี้ Baseline ช่วยให้เราอ้างอิงเกณฑ์การรองรับเดียวกัน ซึ่งเป็นที่รู้จักกันอย่างแพร่หลายในชุมชนเว็บ
ซึ่งยังช่วยสร้างคำศัพท์ที่ใช้ร่วมกันทั้งในทีมวิศวกรและชุมชนเว็บในวงกว้างด้วย เมื่อพูดถึงการนำฟีเจอร์ไปใช้ ทุกคนจะอ้างอิงข้อมูลเดียวกันจากแหล่งที่มาเดียวกัน ซึ่งช่วยลดความจำเป็นในการอธิบายนโยบายภายในหรือแปลระหว่างเฟรมเวิร์กความเข้ากันได้ที่แตกต่างกัน
เครื่องมือพัฒนาซอฟต์แวร์ก็ได้รับการอัปเดตเช่นกัน โดยตอนนี้ Visual Studio Code และแผงรูปแบบในเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome จะแสดงข้อมูลความเข้ากันได้ของ Baseline โดยตรง นักพัฒนาแอปไม่จำเป็นต้องตรวจสอบ MDN หรือ Can I use อยู่ตลอดเวลาเพื่อยืนยันว่าฟีเจอร์นั้นปลอดภัยที่จะใช้หรือไม่ เครื่องมือจะแจ้งให้ทราบทันที
ทำให้ผลิตภัณฑ์ใช้งานได้สำหรับทุกคนอย่างมั่นใจ
Baseline ช่วยให้เราเปลี่ยนวิธีคิดเกี่ยวกับความเข้ากันได้ของเบราว์เซอร์จากภาระที่เราต้องจัดการไปเป็นรากฐานที่เราเชื่อมั่นได้ กลยุทธ์การติดตั้งใช้งานของเรามุ่งเน้นที่การทำงานอัตโนมัติในทุกขั้นตอน ดังนี้
- ความคิดเห็นขณะพัฒนา: การวิเคราะห์แบบคงที่และการ์ดสถานะพื้นฐาน
- การตรวจสอบเวลาบิลด์: Transpiler จะกำหนดเป้าหมายเป็น Baseline Widely available โดยอัตโนมัติ
- การตรวจจับรันไทม์: คำเตือนที่แสดงต่อผู้ใช้สำหรับเบราว์เซอร์ที่ไม่รองรับซึ่งใช้
baseline-browser-mapping - การอัปเดตอย่างต่อเนื่อง: การซิงค์ข้อมูลพื้นฐานโดยอัตโนมัติช่วยลดการบำรุงรักษาด้วยตนเอง
ผลลัพธ์ที่ได้ก็ทำให้เห็นว่าแคมเปญ Smart Shopping ได้ผล
- ไม่ต้องเสียเวลาในการบำรุงรักษาเวอร์ชันเบราว์เซอร์
- ความครอบคลุมของผู้ใช้กว่า 98.8% ยังคงได้รับการดูแลด้วยความแน่นอนระดับฟีเจอร์
- คำตอบสำหรับคำถามที่พบบ่อยแบบทันทีและฉับพลัน ซึ่งจะตอบคำถามที่ว่า "เราใช้ฟีเจอร์นี้ในเบราว์เซอร์เวอร์ชันนี้ได้ไหม"
- คำศัพท์ที่ใช้ร่วมกันในทีมวิศวกร
- เส้นทางที่ชัดเจนยิ่งขึ้นในการนำฟีเจอร์ไปใช้กระตุ้นให้ทีมพูดคุยเกี่ยวกับการผสานรวมฟีเจอร์ใหม่ และกำหนดเวลาในการนำ Polyfill ออกหากจำเป็น
สำหรับองค์กรที่กำลังพิจารณาการใช้ Baseline คุณควรทราบว่าการเปลี่ยนแปลงนี้จะส่งผลต่อผู้ใช้อย่างไร เครื่องมืออย่างเครื่องมือตรวจสอบค่าพื้นฐานของ Google Analytics ช่วยให้การวัดผลนี้ตรงไปตรงมาและอธิบายได้มากขึ้น เมื่อมั่นใจในข้อมูลและตัดสินใจใช้ Baseline แล้ว คุณสามารถใช้ระบบนิเวศที่กำลังเติบโตของ Baseline เพื่อจัดระเบียบเวิร์กโฟลว์การพัฒนาได้
แพลตฟอร์มเว็บมีประสิทธิภาพ สอดคล้องกัน น่าเชื่อถือ และพัฒนาได้รวดเร็วกว่าในอดีต Baseline ช่วยให้เราใช้ประโยชน์จากพลังดังกล่าวในการผลิตได้อย่างมั่นใจ
แหล่งข้อมูล
- บทความต้นฉบับภาษาญี่ปุ่น: プロダクト開発の基準に Baseline を取り入れるまで - Cybozu Inside Out
- การกำหนดค่า ESLint ของ Cybozu:
@cybozu/eslint-configบน GitHub - เครื่องมือตรวจสอบค่าพื้นฐานของ Google Analytics: เครื่องมือตรวจสอบค่าพื้นฐานของ Google Analytics
- การแมปเบราว์เซอร์พื้นฐาน:
@web-platform-dx/baseline-browser-mapping - ดูข้อมูลเกี่ยวกับ Baseline: Baseline ที่ MDN