ความสอดคล้องในระบบนิเวศของเฟรมเวิร์ก JavaScript
ในบล็อกโพสต์แนะนำ เราได้พูดถึงสิ่งที่เราได้เรียนรู้มากมายระหว่างการสร้างและใช้เฟรมเวิร์กและเครื่องมือเพื่อพัฒนาและดูแลรักษาเว็บแอปพลิเคชันขนาดใหญ่ เช่น Google Search, Maps, Photos และอื่นๆ เราได้พิสูจน์แล้วว่าเฟรมเวิร์กมีบทบาทสำคัญต่อผลลัพธ์ด้านประสิทธิภาพและคุณภาพของแอปพลิเคชัน เพื่อป้องกันนักพัฒนาแอปจากการเขียนโค้ดที่อาจส่งผลเสียต่อประสบการณ์ของผู้ใช้
ภายในที่ Google เราใช้คำว่า "Conformance" ในการอธิบายถึงวิธีการนี้ และบทความนี้ครอบคลุมวิธีที่เราวางแผนที่จะทำให้แนวคิดนี้แบบโอเพนซอร์สสำหรับระบบนิเวศของเฟรมเวิร์ก JavaScript
การปฏิบัติตามข้อกำหนดคืออะไร
ที่ Google การปฏิบัติตามข้อกำหนดคือวิวัฒนาการ ทีมต่างๆ อาศัยกลุ่มผู้ดูแลที่มีประสบการณ์ช่ำชองซึ่งได้ทำการตรวจสอบโค้ดอย่างครอบคลุม เพื่อรายงานปัญหาที่ส่งผลต่อคุณภาพของแอปและการบำรุงรักษาให้ดียิ่งขึ้นไปมากกว่าแค่ปัญหาด้านความถูกต้อง ในการขยายธุรกิจนี้ไปยังทีมนักพัฒนาแอปที่กำลังเติบโต ระบบการปฏิบัติตามข้อกำหนดจึงพัฒนาขึ้นเพื่อจัดแบ่งแนวทางปฏิบัติแนะนำในลักษณะที่เป็นไปโดยอัตโนมัติและบังคับใช้ได้ การทำเช่นนี้ช่วยดูแลให้แอปมีคุณภาพและความสามารถในการบำรุงรักษาโค้ดเบสสูงอย่างต่อเนื่อง โดยไม่คำนึงถึงจำนวนผู้ร่วมให้ข้อมูลโค้ด
การปฏิบัติตามข้อกำหนดคือระบบที่ดูแลให้นักพัฒนาแอปใช้เส้นทางที่มีแสงสว่างเพียงพอ สร้างความมั่นใจและทำให้เกิดผลลัพธ์ที่คาดการณ์ได้ ทำให้ทีมทำงานได้อย่างมีประสิทธิภาพ และกลายเป็นสิ่งสำคัญต่อการปรับขนาด เมื่อทีมเติบโตและมีการพัฒนาฟีเจอร์ต่างๆ มากขึ้นพร้อมกัน เครื่องมือนี้ช่วยให้นักพัฒนาซอฟต์แวร์มุ่งเน้นไปที่การสร้างฟีเจอร์ผลิตภัณฑ์ ทำให้แอปสามารถออกจากรายละเอียดเล็กๆ น้อยๆ และสภาพแวดล้อมที่เปลี่ยนแปลงไปในด้านต่างๆ เช่น ประสิทธิภาพ การช่วยเหลือพิเศษ ความปลอดภัย ฯลฯ ทุกคนสามารถเลือกไม่ใช้การปฏิบัติตามข้อกำหนดได้ทุกเมื่อ และควรปรับแต่งได้ในขอบเขตที่ทีมจะมีตัวเลือกในการบังคับใช้สิ่งที่คุณตัดสินใจทำไว้
การปฏิบัติตามข้อกำหนดนั้นสร้างจากค่าเริ่มต้นที่มีประสิทธิภาพ และมอบกฎที่นำไปใช้ได้จริงซึ่งบังคับใช้ได้ในเวลาที่ให้สิทธิ์ ซึ่งแบ่งออกเป็น 3 หลักการต่อไปนี้
1. ค่าเริ่มต้นที่รัดกุม
แง่มุมพื้นฐานของการปฏิบัติตามข้อกำหนดคือ การตรวจสอบว่าเครื่องมือที่นักพัฒนาซอฟต์แวร์ใช้มีค่าเริ่มต้นที่ชัดเจน ซึ่งหมายความว่าโซลูชันไม่เพียงแค่ผสานเข้ากับเฟรมเวิร์ก แต่รูปแบบการออกแบบเฟรมเวิร์กก็ช่วยให้ทำสิ่งที่ใช่ได้ง่ายๆ และทำตามลายที่ต้องแก้ไขได้ยาก เฟรมเวิร์กนี้สนับสนุนนักพัฒนาซอฟต์แวร์ด้วยการออกแบบแอปพลิเคชันและโครงสร้างโค้ด
สำหรับประสิทธิภาพการโหลด ทรัพยากรทั้งหมด (แบบอักษร, CSS, JavaScript, รูปภาพ ฯลฯ) ควรได้รับการเพิ่มประสิทธิภาพ นี่เป็นความท้าทายที่ซับซ้อนเกี่ยวกับการตัดไบต์ การลดการเดินทางไป-กลับ และการแยกสิ่งที่จำเป็นสำหรับการแสดงภาพครั้งแรก ความพร้อมด้านภาพ และการโต้ตอบของผู้ใช้ เช่น การดึงข้อมูล CSS ที่สำคัญ และการตั้งค่าลำดับความสำคัญให้กับรูปภาพที่สำคัญ
2. กฎที่นำไปใช้ได้จริง
แม้จะมีการเพิ่มประสิทธิภาพพื้นฐานแล้ว แต่นักพัฒนาซอฟต์แวร์ก็ยังต้องตัดสินใจอยู่ มีความเป็นไปได้มากมายในการเพิ่มประสิทธิภาพเมื่อนักพัฒนาแอปต้องการอินพุตที่ต้องการ ดังนี้
- ค่าเริ่มต้นที่ไม่ต้องมีอินพุตจากนักพัฒนาซอฟต์แวร์ เช่น การใส่ CSS ที่สำคัญ
- ต้องให้นักพัฒนาแอปเลือกใช้ เช่น การใช้คอมโพเนนต์รูปภาพที่ได้จากเฟรมเวิร์กเพื่อกำหนดขนาดและปรับขนาดรูปภาพ
- ต้องให้นักพัฒนาซอฟต์แวร์เลือกใช้และการปรับแต่ง เช่น การติดแท็กรูปภาพสำคัญเพื่อให้โหลดตั้งแต่เนิ่นๆ
- ไม่ใช่ฟีเจอร์ที่เฉพาะเจาะจง แต่เป็นสิ่งที่นักพัฒนาแอปต้องตัดสินใจ เช่น การหลีกเลี่ยงแบบอักษรหรือสคริปต์แบบซิงโครนัสที่ทำให้การแสดงผลล่วงหน้าล่าช้า
การเพิ่มประสิทธิภาพที่นักพัฒนาแอปต้องตัดสินใจอาจก่อให้เกิดความเสี่ยงต่อประสิทธิภาพของแอปพลิเคชัน เมื่อมีการเพิ่มฟีเจอร์และทีมของคุณขยายขนาด แม้แต่นักพัฒนาซอฟต์แวร์ที่มีประสบการณ์มากที่สุดก็ไม่สามารถตามทันแนวทางปฏิบัติแนะนำที่เปลี่ยนแปลงอยู่ตลอดเวลาได้ และก็ไม่ใช่การใช้เวลาให้เกิดประโยชน์สูงสุดด้วย เพื่อความสอดคล้อง กฎที่นำไปใช้ได้จริงนั้นมีความสำคัญพอๆ กับค่าเริ่มต้นที่แข็งแกร่ง เพื่อดูแลให้แอปพลิเคชันเป็นไปตามมาตรฐานหนึ่งๆ อยู่เสมอแม้ในขณะที่นักพัฒนาซอฟต์แวร์ยังคงทำการเปลี่ยนแปลงใดๆ อยู่
3. เวลาเขียน
การตรวจสอบและป้องกันปัญหาด้านประสิทธิภาพตั้งแต่เนิ่นๆ ในวงจรการพัฒนาเป็นสิ่งสำคัญ เวลาเขียนก่อนที่จะใส่โค้ด จะเหมาะที่สุดในการจับและแก้ปัญหา ปัญหาภายหลังเกิดขึ้นในวงจรการพัฒนา ยิ่งแก้ไขได้ยากขึ้นและแพงขึ้น แม้ว่ากรณีนี้จะใช้กับปัญหาด้านความถูกต้อง แต่ก็เป็นความจริงสำหรับปัญหาด้านประสิทธิภาพเช่นกัน เนื่องจากปัญหาเหล่านี้ส่วนใหญ่จะไม่ได้รับการแก้ไขย้อนหลังเมื่อทำฐานของโค้ดแล้ว
ทุกวันนี้ ความคิดเห็นเกี่ยวกับประสิทธิภาพส่วนใหญ่เกิดขึ้นนอกขอบเขตผ่านทางเอกสารประกอบ การตรวจสอบแบบครั้งเดียว หรือปรากฏช้าเกินไปจากการถดถอยของเมตริกหลังจากนำไปใช้งานจริง เราต้องการให้ผู้อ่าน มีเวลาเขียน
ความสอดคล้องในกรอบงาน
คุณจะต้องตอบคำถามต่อไปนี้เพื่อรักษาระดับประสบการณ์ของผู้ใช้ในด้านประสิทธิภาพการโหลดให้สูงอยู่เสมอ
- การโหลดที่เหมาะสมที่สุดคืออะไร และอะไรคือปัญหาที่พบได้ทั่วไปซึ่งอาจส่งผลกระทบต่อการโหลด
- โซลูชันใดที่นำไปต่อยอดได้ซึ่งไม่จำเป็นต้องมีอินพุตจากนักพัฒนาซอฟต์แวร์
- เราจะมั่นใจได้อย่างไรว่านักพัฒนาแอปใช้โซลูชันเหล่านี้และใช้ประโยชน์จากโซลูชันเหล่านี้ได้อย่างเต็มประสิทธิภาพ
- นักพัฒนาแอปสามารถเลือกอะไรอีกบ้างที่ส่งผลต่อประสิทธิภาพการโหลด
- รูปแบบโค้ดที่สามารถบอกให้เราทราบเกี่ยวกับตัวเลือกเหล่านี้ (ข้อ 3 และ #4 ด้านบน) ตั้งแต่เนิ่นๆ ในเวลาที่สร้างมีอะไรบ้าง
- เราสามารถกำหนดกฎใดบ้างเพื่อประเมินรูปแบบโค้ดเหล่านี้ เขียนคำตอบให้นักพัฒนาซอฟต์แวร์เห็นขณะเขียนงานได้อย่างไรในขณะที่ผสานรวมเข้ากับเวิร์กโฟลว์ได้อย่างราบรื่น
ในการนำโมเดลการปฏิบัติตามข้อกำหนดที่เรามีอยู่ภายในองค์กรของ Google ไปใช้เฟรมเวิร์กโอเพนซอร์ส ทีมของเราได้ทดลองใน Next.js อย่างหนัก และเรายินดีที่จะได้แชร์วิสัยทัศน์และแผนการที่ปรับแต่งมาเป็นอย่างดี เราได้ตระหนักว่าชุดกฎที่ดีที่สุดในการประเมินรูปแบบโค้ดได้จะต้องประกอบด้วยการวิเคราะห์โค้ดแบบคงที่และการตรวจสอบแบบไดนามิกร่วมกัน กฎเหล่านี้ครอบคลุมหลายแพลตฟอร์ม ได้แก่
- ESLint
- TypeScript
- การตรวจสอบแบบไดนามิกในเซิร์ฟเวอร์การพัฒนาของผู้ใช้ (หลังการสร้าง DOM)
- Module Bundler (Webpack)
- เครื่องมือ CSS (ยังอยู่ในช่วงสำรวจ)
การใช้ประโยชน์จากการกำหนดกฎผ่านเครื่องมือต่างๆ ทำให้เรามั่นใจได้ว่ากฎมีความสอดคล้องกัน แต่ก็ยังครอบคลุมปัญหาเกี่ยวกับประสบการณ์ของผู้ใช้ซึ่งส่งผลต่อประสิทธิภาพการโหลดโดยตรงด้วย นอกจากนี้ นักพัฒนาซอฟต์แวร์ยังอาจแสดงกฎเหล่านี้ในเวลาต่างๆ กันอีกด้วย
- ระหว่างการพัฒนาภายในเครื่องในเซิร์ฟเวอร์การพัฒนา เบราว์เซอร์และ IDE ของผู้ใช้จะแสดงคำเตือนเพื่อเตือนให้นักพัฒนาซอฟต์แวร์เปลี่ยนแปลงโค้ดเล็กน้อย
- ในเวลาบิลด์ ปัญหาที่ยังไม่ได้แก้ไขจะปรากฏในเทอร์มินัลของผู้ใช้อีกครั้ง
โดยสรุปแล้ว ทีมจะเลือกผลลัพธ์ที่ตนสนใจ เช่น Core Web Vitals หรือประสิทธิภาพการโหลด และเปิดให้ผู้จัดทำโค้ดทุกคนปฏิบัติตามได้
แม้ว่าวิธีนี้จะทำงานได้ดีสำหรับโปรเจ็กต์ใหม่ๆ แต่การอัปเกรดฐานโค้ดขนาดใหญ่ให้เป็นไปตามชุดกฎเต็มรูปแบบก็ไม่ใช่เรื่องง่าย ที่ Google เรามีระบบที่กว้างขวางสำหรับการเลือกไม่ใช้ในระดับต่างๆ เช่น ซอร์สโค้ดแต่ละบรรทัด ทั้งไดเรกทอรี โค้ดเบสเดิม หรือส่วนต่างๆ ของแอปที่ไม่ได้อยู่ระหว่างการพัฒนา เราขยันหากลยุทธ์ที่มีประสิทธิภาพเพื่อให้ทีมต่างๆ ใช้เฟรมเวิร์กโอเพนซอร์สได้
ความสอดคล้องใน Next.js
ESLint ใช้กันอย่างแพร่หลายในหมู่นักพัฒนาซอฟต์แวร์ JavaScript และแอปพลิเคชัน Next.js กว่า 50% ใช้ ESLint เป็นส่วนหนึ่งของเวิร์กโฟลว์การสร้าง Next.js v11 เปิดตัวการรองรับ ESLint แบบพร้อมใช้งานทันที ซึ่งประกอบด้วยปลั๊กอินที่กำหนดเองและการกำหนดค่าที่แชร์ได้ เพื่อให้ง่ายต่อการตรวจพบปัญหาเฉพาะเฟรมเวิร์กที่พบได้บ่อยในระหว่างการพัฒนาและในเวลาบิลด์ วิธีนี้จะช่วยให้นักพัฒนาแอปแก้ไขปัญหาสำคัญในเวลาที่เขียนได้ ตัวอย่างได้แก่ เมื่อมีการใช้หรือไม่ใช้คอมโพเนนต์ในลักษณะที่อาจเป็นอันตรายต่อประสิทธิภาพ เช่น ไม่มีลิงก์ HTML สำหรับหน้าเว็บ) หรือถ้าแบบอักษร สไตล์ชีต หรือสคริปต์บางอย่าง อาจส่งผลเสียต่อการโหลดทรัพยากรในหน้าเว็บ เช่น ไม่มีสคริปต์แบบซิงโครนัส
นอกเหนือจาก ESLint รองรับการตรวจสอบประเภทที่ผสานรวมทั้งด้านการพัฒนาและเวอร์ชันที่ใช้งานจริงใน Next.js ตั้งแต่ v9 ด้วยการรองรับ TypeScript คอมโพเนนต์หลายตัวที่เฟรมเวิร์ก (รูปภาพ สคริปต์ ลิงก์) สร้างขึ้นเป็นส่วนขยายขององค์ประกอบ HTML (<img>, <script>, <a>) เพื่อให้นักพัฒนาซอฟต์แวร์มีวิธีที่มีประสิทธิภาพในการเพิ่มเนื้อหาลงในหน้าเว็บ การตรวจสอบประเภทรองรับการใช้งานฟีเจอร์เหล่านี้อย่างเหมาะสม โดยตรวจสอบว่าพร็อพเพอร์ตี้และตัวเลือกที่กำหนดอยู่ในขอบเขตค่าและประเภทที่รองรับซึ่งยอมรับได้ ดูความกว้างและความสูงของรูปภาพที่จำเป็นสำหรับตัวอย่าง
การแสดงข้อผิดพลาดด้วยข้อความโทสต์และการวางซ้อน
ดังที่กล่าวไว้ก่อนหน้านี้ กฎการปฏิบัติตามข้อกำหนดจะปรากฏได้ในหลายด้าน เรากำลังสำรวจข้อความโทสต์และการวางซ้อนเพื่อหาวิธีแสดงข้อผิดพลาดในเบราว์เซอร์โดยตรงภายในสภาพแวดล้อมการพัฒนาในเครื่องของผู้ใช้
เครื่องมือตรวจสอบข้อผิดพลาดและการตรวจสอบจำนวนมากที่นักพัฒนาซอฟต์แวร์ใช้ (แท็บปัญหาของ Lighthouse, Chrome DevTools) เป็นแบบแพสซีฟและต้องใช้การโต้ตอบบางอย่างของผู้ใช้เพื่อดึงข้อมูล นักพัฒนาซอฟต์แวร์มีแนวโน้มที่จะดำเนินการเมื่อข้อผิดพลาดแสดงขึ้นโดยตรงภายในเครื่องมือที่มีอยู่ และเมื่อระบุการดำเนินการที่เจาะจงและรูปธรรมที่ควรทำเพื่อแก้ไขปัญหา
ความสอดคล้องในกรอบงานอื่นๆ
เราจะสำรวจความสอดคล้องใน Next.js ก่อน โดยมีเป้าหมายที่จะขยายไปยังเฟรมเวิร์กอื่นๆ (Nuxt, Angular เป็นต้น) ESLint และ TypeScript มีการใช้ในเฟรมเวิร์กจำนวนมากในหลายๆ รูปแบบแล้ว แต่แนวคิดของระบบรันไทม์ระดับเบราว์เซอร์ที่สอดคล้องกันกำลังได้รับการสำรวจอย่างต่อเนื่อง
บทสรุป
ความสอดคล้องจะเชื่อมโยงแนวทางปฏิบัติแนะนำเป็นชุดกฎที่นักพัฒนาซอฟต์แวร์นำไปใช้ได้ในรูปแบบโค้ดง่ายๆ ทีม Aurora มุ่งเน้นที่ประสิทธิภาพการโหลด แต่แนวทางปฏิบัติแนะนำอื่นๆ เช่น การช่วยเหลือพิเศษและความปลอดภัย ก็นำมาใช้ได้เช่นกัน
การปฏิบัติตามกฎการปฏิบัติตามข้อกำหนดควรส่งผลให้เกิดผลลัพธ์ที่คาดการณ์ได้ และการได้รับประสบการณ์ของผู้ใช้ที่มีมาตรฐานสูงอาจกลายเป็นผลข้างเคียงของการสร้างชุดซอฟต์แวร์โครงสร้างพื้นฐานได้ ความสอดคล้องกันทำให้ทีมทำงานได้อย่างมีประสิทธิภาพและทำให้แอปพลิเคชันมีคุณภาพสูงแม้ในขณะที่ทีมและฐานของโค้ดจะเติบโตขึ้นเรื่อยๆ