Refactoring CSS: บทนำ (ตอนที่ 1)

CSS เป็นภาษาสไตล์ชีตอย่างง่ายสำหรับกำหนดการนำเสนอเว็บไซต์หรือเอกสาร อย่างไรก็ตาม ความเรียบง่ายนี้ทำให้ประตูเปิดกว้างสำหรับปัญหาที่อาจเกิดขึ้นมากมายและ หนี้สินทางเทคนิค — รหัสที่มากเกินไป, ความจำเพาะ, บล็อกรหัสที่ซ้ำกันโดยมีความแตกต่างเพียงเล็กน้อยหรือไม่มีเลย, ตัวเลือกที่ไม่ได้ใช้ที่เหลือ, การแฮ็กที่ไม่จำเป็น และวิธีแก้ปัญหา เป็นต้น

หนี้ทางเทคนิคประเภทนั้นหากไม่จ่ายตรงเวลาก็สามารถสะสมและนำไปสู่ปัญหาร้ายแรงตามมาได้ โดยทั่วไป มันสามารถนำไปสู่ ผลข้างเคียงที่ไม่คาดคิด เมื่อเพิ่มส่วนประกอบ UI ใหม่ และทำให้ codebase ดูแลรักษายาก คุณอาจเคยทำงานในโปรเจ็กต์ที่มีโค้ดเบส CSS ที่ไม่ดีมาก่อน และคิดว่าคุณจะเขียนโค้ดต่างกันอย่างไร โดยให้โอกาสในการปรับโครงสร้างใหม่หรือเขียนทุกอย่างใหม่ตั้งแต่ต้น

การ Refactoring ส่วนใหญ่ของโค้ด CSS ไม่ใช่เรื่องง่ายด้วยการวัดใดๆ ในบางครั้ง อาจดูเหมือนว่าเป็นเพียงกรณีของการ "ลบโค้ดคุณภาพต่ำ เขียน CSS ที่ดีขึ้น และปรับใช้โค้ดที่ปรับปรุงใหม่" อย่างไรก็ตาม ยังมีปัจจัยอื่นๆ อีกมากมายที่ต้องพิจารณา เช่น ความยากในการจัดโครงสร้างโค้ดเบสแบบสด ระยะเวลาที่คาดหวังและการใช้งานทีม การกำหนดเป้าหมายการปรับโครงสร้างใหม่ การติดตามประสิทธิภาพและความคืบหน้าของรีแฟคเตอร์ เป็นต้น นอกจากนี้ยังมีเรื่องของการโน้มน้าวใจผู้บริหารหรือผู้มีส่วนได้ส่วนเสียของโครงการให้ ลงทุนเวลาและทรัพยากรในกระบวนการปรับโครงสร้างใหม่

ในชุดข้อมูล สามส่วน นี้ เราจะพูดถึงกระบวนการรีแฟคเตอร์ CSS ตั้งแต่ต้นจนจบ โดยเริ่มจากความรู้เกี่ยวกับวิธีการเข้าถึงมัน และข้อดีและข้อเสียทั่วไปบางประการของการปรับโครงสร้างใหม่ จากนั้นจึงไปที่กลยุทธ์การปรับโครงสร้างใหม่ด้วยตนเองและสิ้นสุด ด้วยแนวทางปฏิบัติที่ดีที่สุดทั่วไปบางประการเกี่ยวกับขนาดไฟล์ CSS และประสิทธิภาพ

ผลข้างเคียงของ CSS ที่มีคุณภาพต่ำ

สำหรับความยืดหยุ่นและความเรียบง่าย CSS เองมีปัญหาพื้นฐานบางอย่างที่ทำให้นักพัฒนาสามารถเขียนโค้ดคุณภาพต่ำได้ตั้งแต่แรก ปัญหาเหล่านี้เกิดจากกลไกความจำเพาะและการสืบทอด การทำงานในขอบเขตสากล การพึ่งพาลำดับต้นทาง ฯลฯ

ในระดับทีม ปัญหาโค้ดเบส CSS ส่วนใหญ่มักเกิดจาก ระดับทักษะ และความรู้ CSS ที่แตกต่างกัน ความชอบและสไตล์โค้ดที่ต่างกัน การขาดความเข้าใจในโครงสร้างโปรเจ็กต์และโค้ดและส่วนประกอบที่มีอยู่ การขาดระดับโปรเจ็กต์หรือทีม -ระดับมาตรฐานและแนวทางปฏิบัติและอื่นๆ

ด้วยเหตุนี้ CSS ที่มีคุณภาพต่ำอาจทำให้เกิดปัญหาที่นอกเหนือไปจากข้อบกพร่องทางสายตาทั่วไป และสามารถสร้างผลข้างเคียงที่รุนแรงต่างๆ ที่อาจส่งผลต่อโครงการโดยรวมได้ ตัวอย่างดังกล่าว ได้แก่:

• คุณภาพของโค้ดที่ลดลง เมื่อมีการเพิ่มคุณสมบัติเพิ่มเติมเนื่องจากระดับทักษะ CSS ที่แตกต่างกันภายในทีมพัฒนาและไม่มีกฎเกณฑ์ภายใน แบบแผน และแนวทางปฏิบัติที่ดีที่สุด
• การเพิ่มคุณสมบัติใหม่หรือการขยายตัวเลือกที่มีอยู่ทำให้เกิดจุด บกพร่องและผลข้างเคียงที่ไม่คาดคิด ในส่วนอื่นๆ ของโค้ด (หรือที่เรียกว่าการ ถดถอย )
• ตัวเลือก CSS ที่แตกต่างกันหลายตัวพร้อม บล็อกโค้ดที่ซ้ำกัน หรือส่วนย่อยของโค้ด CSS สามารถแยกออกในตัวเลือกใหม่และขยายตามรูปแบบต่างๆ ได้
• โค้ดที่เหลือที่ไม่ได้ใช้จากฟีเจอร์ที่ถูกลบ ทีมพัฒนาไม่ได้ติดตามว่ามีการใช้โค้ด CSS ใดและสามารถลบออกได้อย่างปลอดภัย
• โครงสร้างไฟล์ ไม่สอดคล้องกัน การตั้งชื่อคลาส CSS คุณภาพโดยรวมของ CSS เป็นต้น
• “Specificity hell” ที่มีการเพิ่มคุณสมบัติใหม่โดยการแทนที่โค้ดเบส CSS ที่มีอยู่
• เลิกทำ CSS โดยที่ตัวเลือกที่มีความจำเพาะสูง "รีเซ็ต" สไตล์ตัวเลือกที่มีความจำเพาะต่ำกว่า นักพัฒนากำลังเขียนโค้ดมากขึ้นเพื่อให้มีรูปแบบน้อยลง ส่งผลให้เกิดความซ้ำซ้อนและการสูญเสียโค้ดจำนวนมาก

ในกรณีที่เลวร้ายที่สุด ปัญหาทั้งหมดที่กล่าวมารวมกันอาจส่งผลให้ ไฟล์ CSS มีขนาดใหญ่ แม้จะใช้การลดขนาด CSS ก็ตาม โดยทั่วไป CSS นี้จะบล็อกการแสดงผล ดังนั้นเบราว์เซอร์จะไม่แสดงเนื้อหาเว็บไซต์จนกว่าจะดาวน์โหลดและแยกวิเคราะห์ไฟล์ CSS เสร็จสิ้น ส่งผลให้ UX และประสิทธิภาพในเครือข่ายที่ช้ากว่าหรือไม่น่าเชื่อถือ

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

ทีมงานของ Netlify ตั้งข้อสังเกตว่าเหตุผลที่อยู่เบื้องหลังโครงการรีแฟคเตอร์ CSS ขนาดใหญ่ของพวกเขาคือ คุณภาพของโค้ดที่ลดลง และความสามารถในการบำรุงรักษาเมื่อโปรเจ็กต์มีความซับซ้อนเพิ่มขึ้นด้วยการเพิ่มส่วนประกอบ UI มากขึ้นเรื่อยๆ พวกเขายังสังเกตเห็นว่าการขาดมาตรฐาน CSS ภายในและเอกสารประกอบทำให้คุณภาพของโค้ดลดลง เนื่องจากมีผู้คนจำนวนมากขึ้นที่ทำงานบนโค้ดเบส CSS

“(…) สิ่งที่เริ่มต้นด้วยการจัดระเบียบ PostCSS ค่อยๆ เติบโตจนกลายเป็นสถาปัตยกรรม CSS ระดับโลกที่ซับซ้อนและพันกันโดยมีความจำเพาะและการแทนที่มากมาย อย่างที่คุณคาดไว้ มีจุดที่หนี้เทคโนโลยีที่เพิ่มเข้ามาทำให้ยากต่อการจัดส่งอย่างรวดเร็วโดยไม่เพิ่มการถดถอยใดๆ นอกจากนี้ เนื่องจากจำนวนนักพัฒนาฟรอนต์เอนด์ที่มีส่วนร่วมในฐานโค้ดเพิ่มขึ้น สถาปัตยกรรม CSS ประเภทนี้จึงทำงานได้ยากขึ้น"

Refactor หรือ Rewrite?

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

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

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

การเขียนซ้ำ ช่วยให้นักพัฒนาทำการ เปลี่ยนแปลงที่สำคัญ กับ codebase และถือว่าส่วนใหญ่ถ้าไม่ใช่รหัสทั้งหมดจาก codebase ปัจจุบันจะถูกเปลี่ยนหรือแทนที่ Rewrite ช่วยให้นักพัฒนาสามารถสร้าง codebase ใหม่ตั้งแต่ต้น จัดการกับปัญหาหลักจาก codebase ปัจจุบันที่แก้ไขไม่ได้หรือมีราคาแพง ปรับปรุงเทคโนโลยี stack และสถาปัตยกรรม และสร้างกฎภายในใหม่และแนวทางปฏิบัติที่ดีที่สุดสำหรับ codebase ใหม่

ตัวอย่างเช่น ลูกค้าอยู่ในกระบวนการรีแบรนด์ และเว็บไซต์จำเป็นต้องได้รับการปรับปรุงด้วยการออกแบบใหม่และเนื้อหาที่ปรับปรุงใหม่ เนื่องจากนี่เป็นการ เปลี่ยนแปลงทั่วทั้งไซต์ นักพัฒนาจึงตัดสินใจเริ่มต้นจากศูนย์ เขียนโครงการใหม่ และใช้โอกาสนี้เพื่อแก้ไขปัญหาหลักที่ CSS codebase ปัจจุบันมี แต่ไม่สามารถแก้ไขได้ด้วยการปรับโครงสร้างโค้ด อัปเดต CSS tech stack ใช้เครื่องมือและคุณสมบัติใหม่ล่าสุด ตั้งกฎภายในใหม่และแนวปฏิบัติที่ดีที่สุดสำหรับการจัดสไตล์ ฯลฯ

มาสรุปข้อดีข้อเสียของแต่ละวิธีกัน

เมื่อใดควร Refactor CSS?

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

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

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

หัวหน้านักพัฒนา frontend หรือผู้พัฒนาที่มีประสบการณ์กับ CSS มากที่สุดควรหยิบยกปัญหาและสร้างงาน refactor เพื่อบังคับใช้มาตรฐานคุณภาพโค้ด CSS ใน codebase

เมื่อใดจะเขียน CSS ใหม่

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

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

การตรวจสอบ CSS Codebase Health

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

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

เมื่อทำการตรวจสอบ CSS หรือเตรียมการปรับโครงสร้าง CSS ฉันใช้เครื่องมือที่มีประโยชน์หลายอย่างเพื่อดูภาพรวมทั่วไปและสถิติที่มีประโยชน์เกี่ยวกับ CSS codebase

เครื่องมือส่วนตัวของฉันคือ CSS Stats ซึ่งเป็นเครื่องมือฟรีที่ให้ภาพรวมที่เป็นประโยชน์ของคุณภาพโค้ดเบส CSS พร้อมเมตริกที่มีประโยชน์มากมาย ซึ่งสามารถช่วยให้นักพัฒนาสามารถแก้ไขปัญหาที่ยากต่อจุด

ย้อนกลับไปในปี 2016 trivago ได้ทำการรีแฟคเตอร์ขนาดใหญ่สำหรับโค้ดเบส CSS และใช้ตัววัดจากสถิติ CSS เพื่อกำหนดเป้าหมายที่เป็นรูปธรรมและวัดผลได้ เช่น การลดความจำเพาะและลดจำนวนรูปแบบสี ในเวลาเพียงสามสัปดาห์ พวกเขาปรับปรุงประสิทธิภาพโดยรวมของโค้ดเบส CSS ลดขนาดไฟล์ CSS ปรับปรุงประสิทธิภาพการเรนเดอร์บนมือถือ ฯลฯ

“เครื่องมืออย่างเช่น CSS Stats สามารถช่วยคุณค้นหาปัญหาความสอดคล้องภายใน codebase ของคุณได้อย่างง่ายดาย การระบุสิ่งที่สามารถเกิดขึ้นได้เมื่อทุกคนมีความคิดเห็นที่แตกต่างกันว่าโทนสีเทาควรเป็นอย่างไร คุณจะได้สีเทา 50 เฉด นอกจากนี้ กราฟความจำเพาะยังช่วยบ่งชี้โดยรวมที่ดีเกี่ยวกับความสมบูรณ์ของฐาน CSS ของคุณ”

สำหรับเครื่องมือ CLI Wallace เป็นเครื่องมือที่มีประโยชน์ซึ่งให้สถิติและภาพรวม CSS ที่ค่อนข้างพื้นฐานแต่มีประโยชน์ ซึ่งสามารถใช้เพื่อระบุปัญหาที่เกี่ยวข้องกับขนาดไฟล์ จำนวนกฎและตัวเลือก ประเภทตัวเลือกและความซับซ้อน เป็นต้น

Wallace ยังมีเครื่องมือวิเคราะห์ฟรีบนเว็บไซต์ Project Wallace ซึ่งใช้เวอร์ชันขั้นสูงของ Wallace ในแบ็กเอนด์เพื่อให้การแสดงภาพข้อมูลที่เป็นประโยชน์และตัวชี้วัดอื่นๆ อีกสองสามตัวที่ไม่มีใน Wallace CLI

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

การเขียน CSS คุณภาพสูง

เราได้เห็นแล้วว่าความเรียบง่ายและความยืดหยุ่นของโค้ดเบส CSS ทำให้เกิดปัญหามากมายเกี่ยวกับคุณภาพของโค้ด ประสิทธิภาพ และข้อบกพร่องด้านภาพได้อย่างไร ไม่มีเครื่องมืออัตโนมัติแบบกระสุนเงินที่ทำให้แน่ใจว่าเราเขียน CSS อย่างดีที่สุดและหลีกเลี่ยงข้อผิดพลาดทางสถาปัตยกรรมที่เป็นไปได้ทั้งหมดไปพร้อมกัน

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

ตัวอย่างเช่น การระบุตัวเลือกมากเกินไป นักพัฒนาเพียงคนเดียวสามารถจำกัดการใช้งานได้อย่างรุนแรง ส่งผลให้นักพัฒนารายอื่นต้องทำซ้ำโค้ดเพื่อใช้กับส่วนประกอบอื่นๆ ที่คล้ายคลึงกันซึ่งมีมาร์กอัปต่างกัน ปัญหาเหล่านี้มักเกิดขึ้นเมื่อนักพัฒนาขาดความเข้าใจและไม่ใช้ประโยชน์จากกลไกเบื้องหลัง CSS (การเรียงซ้อน การสืบทอด ประสิทธิภาพของเบราว์เซอร์ และความจำเพาะของตัวเลือก) การตัดสินใจในช่วงแรกๆ เหล่านี้สามารถนำไปสู่ผลกระทบที่สำคัญในอนาคต ดังนั้นความสมบูรณ์และความสามารถในการบำรุงรักษาของ CSS codebase จะขึ้นอยู่กับความรู้ ทักษะ และความเข้าใจของนักพัฒนาในพื้นฐานของ CSS

เครื่องมืออัตโนมัติไม่ได้ตระหนักถึงภาพรวมหรือวิธีการใช้ตัวเลือก ดังนั้นจึงไม่สามารถทำการตัดสินใจด้านสถาปัตยกรรมที่สำคัญเหล่านี้ได้ นอกเหนือจากการบังคับใช้กฎพื้นฐาน คาดเดาได้ และเข้มงวดบางอย่าง

จากประสบการณ์ส่วนตัว ฉันพบว่าสิ่งต่อไปนี้ช่วยให้ฉันปรับปรุงวิธีการทำงานกับ CSS ได้อย่างมาก:

• การเรียนรู้รูปแบบสถาปัตยกรรม
  แนวทาง CSS ให้ฐานความรู้ที่ดีและแนวปฏิบัติที่ดีที่สุดสำหรับการเขียน CSS คุณภาพสูงตามรูปแบบการเขียนโปรแกรมทั่วไปและหลักการทางสถาปัตยกรรม
• ฝึกฝนและปรับปรุง
  ทำงานในโครงการส่วนตัวหรือจัดการกับความท้าทายจาก Frontend Mentor เพื่อพัฒนาทักษะของคุณ เริ่มต้นด้วยโครงการง่ายๆ (ส่วนประกอบเดียวหรือส่วนเดียว) และเน้นที่การเขียน CSS ที่ดีที่สุด ลองใช้วิธีการต่างๆ ใช้รูปแบบสถาปัตยกรรมต่างๆ ค่อยๆ ปรับปรุงโค้ด และเรียนรู้วิธีเขียน CSS คุณภาพสูงอย่างมีประสิทธิภาพ
• เรียนรู้จากความผิดพลาด
  เชื่อฉันสิ คุณจะเขียน CSS ที่มีคุณภาพต่ำจริงๆ เมื่อคุณเริ่มต้น คุณจะต้องพยายามสองสามครั้งเพื่อให้ถูกต้อง ใช้เวลาสักครู่และคิดเกี่ยวกับสิ่งที่ผิดพลาด วิเคราะห์จุดอ่อน คิดเกี่ยวกับสิ่งที่คุณสามารถทำแตกต่างไปจากเดิมและอย่างไร และพยายามหลีกเลี่ยงข้อผิดพลาดเดียวกันนี้ในอนาคต

สิ่งสำคัญคือต้อง สร้างกฎเกณฑ์และมาตรฐาน CSS ภายในภายในทีมหรือแม้แต่สำหรับทั้งบริษัท มาตรฐานทั่วทั้งบริษัท ลักษณะโค้ด และหลักการที่ชัดเจนสามารถให้ประโยชน์มากมาย เช่น:

• รูปแบบและคุณภาพของโค้ดที่เป็นหนึ่งเดียวและสม่ำเสมอ
• โค้ดเบสที่เข้าใจง่ายและแข็งแกร่ง
• การเริ่มต้นโครงการที่คล่องตัว
• การตรวจสอบโค้ดที่ได้มาตรฐานที่สมาชิกในทีมทุกคนสามารถทำได้ ไม่ใช่แค่ Lead Frontend Developer หรือ Developer ที่มีประสบการณ์มากกว่า

Kirby Yardley ได้ทำงานเกี่ยวกับการปรับโครงสร้างระบบการออกแบบ Sundance Institute และ CSS และได้ชี้ให้เห็นถึงความสำคัญของการกำหนดกฎเกณฑ์ภายในและแนวทางปฏิบัติที่ดีที่สุด

“หากไม่มีกฎเกณฑ์และกลยุทธ์ที่เหมาะสม CSS ก็คือภาษาที่นำไปใช้ในทางที่ผิด นักพัฒนามักจะเขียนรูปแบบเฉพาะสำหรับองค์ประกอบหนึ่งโดยไม่ต้องคิดอย่างวิพากษ์วิจารณ์ว่าโค้ดนั้นสามารถนำกลับมาใช้ใหม่ได้อย่างไรในองค์ประกอบอื่น ๆ (...) หลังจากการวิจัยและไตร่ตรองมากมายเกี่ยวกับวิธีที่เราต้องการสร้างสถาปัตยกรรม CSS ของเรา เราจึงตัดสินใจใช้วิธีที่เรียกว่า ITCSS “

ย้อนกลับไปที่ตัวอย่างก่อนหน้าจากทีมงานที่ trivago การกำหนดกฎเกณฑ์และแนวทางภายในได้รับการพิสูจน์แล้วว่าเป็นขั้นตอนที่สำคัญสำหรับกระบวนการปรับโครงสร้างใหม่

“เราแนะนำไลบรารีรูปแบบ เริ่มใช้การออกแบบอะตอมมิกในเวิร์กโฟลว์ของเรา สร้างแนวทางการเข้ารหัสใหม่ และปรับวิธีการต่างๆ เช่น BEM และ ITCSS เพื่อสนับสนุนเราในการรักษาและพัฒนา CSS/UI ของเราในวงกว้าง”

ไม่จำเป็นต้องตรวจสอบและบังคับใช้กฎและมาตรฐานทั้งหมดด้วยตนเอง เครื่องมือ CSS linting เช่น Stylelint มีกฎที่มีประโยชน์ซึ่งจะช่วยให้คุณตรวจสอบข้อผิดพลาดและบังคับใช้มาตรฐานภายในและแนวทางปฏิบัติที่ดีที่สุดของ CSS ทั่วไป เช่น การไม่อนุญาตการบล็อกโค้ด CSS และความคิดเห็น การไม่อนุญาตตัวเลือกที่ซ้ำกัน การจำกัดหน่วย การตั้งค่าความเฉพาะเจาะจงสูงสุดของตัวเลือกและความลึกของการซ้อน การสร้าง รูปแบบชื่อตัวเลือก ฯลฯ

บทสรุป

ก่อนตัดสินใจเสนอตัวปรับโครงสร้างโค้ดเบสแบบละเอียดหรือเขียน CSS ใหม่ทั้งหมด เราจำเป็นต้อง เข้าใจปัญหาของฐานโค้ดปัจจุบัน ก่อน เพื่อที่เราจะสามารถหลีกเลี่ยงปัญหาเหล่านี้ได้ในอนาคตและมีข้อมูลที่วัดผลได้สำหรับกระบวนการ CSS codebase อาจประกอบด้วยตัวเลือกที่มีความจำเพาะสูงที่ซับซ้อนจำนวนมาก ซึ่งทำให้เกิดผลข้างเคียงและจุดบกพร่องที่ไม่คาดคิดเมื่อเพิ่มคุณสมบัติใหม่ บางที codebase อาจประสบปัญหาจากโค้ดที่ซ้ำกันจำนวนมากที่สามารถย้ายไปยังคลาสยูทิลิตี้แยกต่างหาก หรืออาจเป็นการผสมผสานของ ข้อความค้นหาสื่อต่างๆ ทำให้เกิดข้อขัดแย้งที่ไม่คาดคิด

เครื่องมือที่มีประโยชน์ เช่น CSS Stats และ Wallace สามารถให้ภาพรวมระดับสูงทั่วไปของ CSS codebase และให้ข้อมูลเชิงลึกโดยละเอียดเกี่ยวกับสถานะและสถานภาพของ codebase เครื่องมือเหล่านี้ยังมี สถิติที่วัดได้ ซึ่งสามารถใช้เพื่อกำหนดเป้าหมายสำหรับกระบวนการปรับโครงสร้างใหม่และติดตามความคืบหน้าในการจัดโครงสร้างใหม่

หลังจากกำหนดเป้าหมายและขอบเขตการปรับโครงสร้างใหม่แล้ว สิ่งสำคัญคือต้อง กำหนดหลักเกณฑ์ภายในและแนวทางปฏิบัติที่ดีที่สุดสำหรับ CSS codebase — หลักการตั้งชื่อ หลักการทางสถาปัตยกรรม ไฟล์ และโครงสร้างโฟลเดอร์ ฯลฯ ซึ่งจะทำให้มั่นใจถึงความสอดคล้องของโค้ด สร้างรากฐานหลักภายในโครงการซึ่งสามารถจัดทำเป็นเอกสารได้ และสามารถใช้สำหรับการปฐมนิเทศและการตรวจสอบโค้ด CSS การใช้เครื่องมือ linting เช่น Stylelint สามารถช่วยบังคับใช้แนวทางปฏิบัติที่ดีที่สุดทั่วไปของ CSS เพื่อทำให้กระบวนการตรวจสอบโค้ดเป็นไปโดยอัตโนมัติบางส่วน

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

อ้างอิง

• “การจัดการโครงการ CSS ด้วย ITCSS” Harry Roberts
• “การปรับโครงสร้าง CSS ขนาดใหญ่ที่ Trivago” Christoph Reinartz
• “ระบบออกแบบ Sundance.org และ CSS Refactor” Kirby Yardley
• “จาก Semantic CSS สู่ Tailwind: Refactoring The Netlify UI Codebase” Charlie Gerard และ Leslie Cohn-Wein
• “เครื่องมือตรวจสอบ CSS” Iris Lješnjanin