เฟรมเวิร์ก (Frameworks) และเครื่องมือที่มีอยู่อย่างมากมายในปัจจุบันทำให้รู้สึกว่า การพัฒนาเว็บนั้นมีความซับซ้อนมากเกินไป ทำให้ในฐานะมือใหม่อาจเป็นเรื่องที่ชวนให้ปวดหัว เมื่อต้องพิจารณาสิ่งต่างๆ มากมาย
โดยล่าสุด Juan Diego Rodríguez ได้ออกมาสำรวจคำกล่าวอ้างที่ว่า การพัฒนาเว็บมีความซับซ้อนขนาดนั้นจริงๆ หรือไม่ และที่สำคัญที่สุดคือ เราจะป้องกันไม่ให้มันยากเกินกว่าที่เราคิดไว้ได้อย่างไร!
แล้วที่ผ่านมาการพัฒนาเว็บเป็นอย่างไร
ตัวอย่างเช่นเมื่อ 15 ปีที่แล้ว การเรียนรู้การพัฒนาส่วนหน้านั้นง่ายกว่ามาก ซึ่งเราสามารถเริ่มต้นเว็บไซต์ด้วยหน้า HTML แบบคงที่, CSS ขั้นต่ำสำหรับการจัดสไตล์ และการใช้ JavaScript (และบางทีอาจเป็น jQuery) เพื่อเพิ่มคุณสมบัติเชิงโต้ตอบ
ตั้งแต่แถบด้านข้างที่สลับไปจนถึงภาพหมุนและรูปแบบอื่นๆ นักพัฒนาทั่วไปของเราคาดหวังอะไรไปมากกว่านี้ไม่ได้อีกแล้ว อย่างอื่นถือว่า “ไปไกลกว่านั้น” แน่นอนว่าคุณสมบัติ CSS และ JavaScript แบบเนทีฟที่ยอดเยี่ยมที่เรามีในปัจจุบันยังไม่มีในสมัยนั้น แต่ก็ไม่จำเป็นสำหรับสิ่งที่ถือเป็นแนวทางปฏิบัติที่ดีที่สุดในปีที่ผ่านมา
ในปัจจุบัน เว็บและทุกสิ่งรอบตัวเปลี่ยนไปเมื่อมีการเพิ่มความสามารถ และผู้คนจำนวนมากขึ้นเรื่อยๆ ที่พึ่งพามัน เราได้สร้างโซลูชันใหม่ เครื่องมือใหม่ ขั้นตอนการทำงานใหม่ คุณลักษณะใหม่ และสิ่งอื่นใดใหม่ที่จำเป็นเพื่อรองรับเว็บที่ใหญ่ขึ้น และมีความต้องการมากขึ้น
Stacks เริ่มใหญ่ขึ้น
เป็นเพียงเหตุผลที่เฟรมเวิร์ก JavaScript มีขนาดใหญ่ขึ้นเมื่อเวลาผ่านไป เว็บเป็นสถานที่ขนาดใหญ่ และไม่มีเฟรมเวิร์กใดที่จะครอบคลุมทุกสิ่งได้ แต่พวกเขาพยายามและความซับซ้อนก็เพิ่มขึ้นตามลำดับ ดูเหมือนว่าขนาดของกรอบงานจะมีความสัมพันธ์แบบ 1 ต่อ 1 กับความซับซ้อนของมัน
แต่เฟรมเวิร์กหลักเป็นเพียงส่วนหนึ่งของเว็บแอป เทคโนโลยีอื่นๆ หลายอย่างประกอบกันเป็นเทคโนโลยีที่เรียกว่า “Stacks” และเมื่อเว็บได้รับผู้ใช้และเฟรมเวิร์กที่ตอบสนองความต้องการมากขึ้น เทคโนโลยี Stacks ก็ใหญ่ขึ้นเรื่อยๆ นั้นเอง
อย่างไรก็ตาม โปรเจกต์ใหม่น่าจะต้องใช้สถาปัตยกรรมเฉพาะเพื่อตอบสนองความต้องการ บริษัทเทคโนโลยียักษ์ใหญ่ต้องการสถาปัตยกรรมขนาดมหึมาในทุกโปรเจกต์ของตน
และ Stacks ของพวกเขาได้รับการออกแบบทางวิศวกรรมขั้นสูงเพื่อรองรับความสามารถในการปรับขนาดและการบำรุงรักษาที่ปลอดภัย อีกทั้งพวกเขายังมีฐานลูกค้าจำนวนมาก
ดังนั้น การรักษาฐานรหัสขนาดใหญ่จะง่ายขึ้นโดยมีรายได้มากขึ้น มีวิศวกรมากขึ้น และเห็นภาพปัญหาได้ชัดเจนยิ่งขึ้น เพื่อลดของเสีย กลุ่มเทคโนโลยีของบริษัทขนาดเล็กและโปรเจกต์สามารถและควรลดลง ไม่เพียงเพื่อให้ตรงกับขนาดความต้องการเท่านั้น แต่ยังรวมถึงความสามารถของนักพัฒนาในทีมด้วย
แล้วเราจะลดความซับซ้อนของ Codebase ของเราได้อย่างไร
เชื่อว่าเราสามารถลดปัญหาความซับซ้อนให้เป็นไปตามความปรารถนาส่วนตัวได้ และความต้องการที่รับรู้ได้แทนที่จะกำหนดขอบเขตโปรเจกต์ตามความต้องการ และประสบการณ์ของผู้ใช้อย่างเหมาะสม
เราสามารถทำอะไรได้บ้างเพื่อลดความซับซ้อนของโปรเจกต์ของเราเอง: สำหรับคำแนะนำต่อไปนี้จะเกี่ยวข้อง เมื่อเราสามารถควบคุมโปรเจกต์ของเราได้ เนื่องจากเป็นโปรเจกต์ส่วนตัว เป็นโปรเจกต์เล็กกว่าสำหรับทีมเล็กหรือเราสามารถควบคุมการตัดสินใจในองค์กรขนาดใดก็ตามที่เราอยู่
สำหรับขั้นตอนที่ยากที่สุดและสำคัญที่สุดคือ การตรวจจับเมื่อ Codebase ของเราเริ่มซับซ้อนโดยไม่จำเป็น มันเป็นขั้นตอนที่ยากที่สุดเนื่องจาก ไม่มีความแน่นอนว่าข้อกำหนดคืออะไรหรือสิ่งที่ผู้ใช้ต้องการ เราทำได้เพียงตั้งสมมติฐานเท่านั้น
แต่บางอย่างก็ชัดเจน เช่น สมมติว่าผู้ใช้จะต้องมีวิธีลงชื่อเข้าใช้แอป ส่วนอื่นๆ อาจไม่ชัดเจน เช่น แอปควรมีการส่งข้อความส่วนตัวระหว่างผู้ใช้หรือไม่ อื่นๆ ยังคงเข้าใจได้ไกล เช่น ผู้ใช้ที่เชื่อว่าต้องการเวลาแฝงที่ต่ำมากในหน้าอีคอมเมิร์ซ คุณสมบัติอื่นๆ อยู่ในขอบเขต "ดีที่มี"
อย่างไรก็ตามนั่นเป็นเรื่องเกี่ยวกับประสบการณ์ของผู้ใช้ แต่คำถามเดียวกันนี้เกิดขึ้นในด้านการพัฒนา:
1. แอปจำเป็นต้องมี SSR, SSG หรือทั้งสองอย่างผสมกันหรือไม่?
2. เราควรใช้การทดสอบแบบ end-to-end หรือการทดสอบหน่วยหรือไม่?
3. vanilla JavaScript เพียงพอแล้วหรือเราจะเพิ่ม TypeScript?
4. เราควรใช้ตัวประมวลผลล่วงหน้า CSS หรือเฟรมเวิร์ก CSS หรือเราสามารถทำได้โดยใช้โมดูล CSS เท่านั้น
5. เราควรใช้ Redis ที่ส่วนหลังเพื่อการสืบค้นฐานข้อมูลที่รวดเร็วขึ้น หรือนั่นมีขอบเขตมากเกินไปสำหรับงานหรือไม่
ดังนั้น คำถามเหล่านี้เป็นคำถามที่ถูกต้องที่ควรพิจารณาเมื่อพัฒนาเว็บไซต์ แต่...คำถามเหล่านี้อาจเบี่ยงเบนความสนใจของเราไปจากจุดหลักของเรา นั้นคือการทำสิ่งต่างๆ ให้สำเร็จ
“ทำแล้วย่อมดีกว่าสมบูรณ์แบบ” By Sheryl Sandberg
อย่างไรก็ตาม และแม้แต่แอปที่ใหญ่ที่สุดและซับซ้อนที่สุดก็เริ่มต้นจากข้อเสนอขั้นต่ำที่ทำซ้ำๆ ตลอดทาง
เราควรถามตัวเองด้วยว่าจะเกิดอะไรขึ้นหากไม่ได้เพิ่มฟีเจอร์หรือการพึ่งพาใดๆ ลงในโปรเจกต์ หากคำตอบคือ “ไม่มีอะไร” เราก็ควรเปลี่ยนความสนใจไปที่สิ่งอื่น
อีกคำถามที่น่าถาม คือ “ทำไมเราถึงเลือกที่จะเพิ่ม [X]?” เป็นเพราะนั่นคือสิ่งที่ได้รับความนิยมในขณะนี้หรือเพราะมันแก้ปัญหาที่ส่งผลกระทบต่อฟีเจอร์หลักหรือไม่?
อีกแง่มุมที่ต้องคำนึงถึงคือ เราคุ้นเคยกับเทคโนโลยีบางอย่างเพียงใด และให้ความสำคัญกับผู้ที่เรารู้จักและสามารถเริ่มใช้งานได้ทันที แทนที่จะต้องหยุดและเรียนรู้ข้อมูลเชิงลึกของกรอบงานใหม่
สรุปคือ: เราควรเลือกเครื่องมือให้เหมาะสมกับงาน ซึ่งจะตรงกับความต้องการและเหมาะกับโมเดลทางตรรกะของเรา ให้ความสำคัญกับความนิยมและความสามารถในการปรับขนาดของไลบรารีให้น้อยลง แต่มุ่งเน้นไปที่การทำให้แอปของเราไปถึงจุดที่ต้องขยายตั้งแต่แรก
---Wynnsoft Solution รับทำเว็บไซต์ รับทำ SEO รับทำการตลาดออนไลน์ รับทำโฆษณา Facebook รับทำเว็บไซต์ ขอนแก่น และรับทำเว็บไซต์ทั่วประเทศ—
ข้อมูลจาก: smashingmagazine