12 กุมภาพันธ์ 2567 นักเขียนนิรนาม
การพัฒนาเว็บในปัจจุบันเริ่มซับซ้อนเกินไปจริงหรือไม่

เฟรมเวิร์ก (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