คำตอบจากมุมมองส่วนหน้า:
อย่าฟังทุกคนว่าไม่สามารถทำได้เพราะบริการเว็บของมหาวิทยาลัยซานฟรานซิสโกที่ฉันได้เขียนในปี 1996 ในที่สุดก็ไปสวรรค์บนอินเทอร์เน็ตเมื่อสองสามปีที่แล้วและไม่จำเป็นต้องแก้ไขความเข้ากันได้ของเบราว์เซอร์เดียวในเวลานั้น ; นั่นเกือบครึ่งหนึ่งของเป้าหมาย 40 ปีของคุณ และส่วนหน้าแบบอิง JavaScript นี้ฉันสร้างขึ้นในปี 1998 สำหรับโครงการ Stanford Research Institute ถูกแทนที่ด้วยบางสิ่งที่กระพริบตาในอีกไม่กี่ปีต่อมา แต่ไม่มีเหตุผลที่ UI ดั้งเดิมจะไม่สามารถทำงานได้ในปัจจุบันด้วยการแก้ไขความเข้ากันได้เล็กน้อย
เคล็ดลับคือเพื่อให้แน่ใจว่าแอปของคุณใช้มาตรฐาน W3C / ECMA ที่รองรับเท่านั้นและมีการออกแบบที่สะอาดภายใต้การควบคุมของคุณ ในขณะที่แอพพลิเคชั่นบนเว็บจำนวนมากที่เขียนถึงเทคโนโลยียุค 90 ที่ทันสมัยไม่สามารถทำงานได้ดีหรือในทุกวันนี้แอพพลิเคชั่นบนเว็บยุค 90 ที่เขียนตามมาตรฐานที่สำคัญยังคงทำอยู่ พวกเขาอาจดูPassé แต่พวกเขาทำงาน
เป้าหมายที่นี่ไม่ได้เขียนแอปพลิเคชันเว็บที่จะขึ้นไปบนเซิร์ฟเวอร์ของพวกเขาและอยู่ที่นั่นเป็นเวลา 40 ปีโดยที่ไม่มีใครแตะต้องอีกเลย มันคือการสร้างรากฐานที่ยังคงสามารถใช้งานได้นับทศวรรษซึ่งสามารถเติบโตเพื่อรองรับคุณสมบัติใหม่โดยไม่ต้องสร้างใหม่ตั้งแต่ต้น
ก่อนอื่นคุณต้องใช้รหัสมาตรฐานอย่างเป็นทางการและมาตรฐานอย่างเป็นทางการเท่านั้น ไม่มีคุณสมบัติของ JavaScript ที่ไม่ได้เป็นส่วนหนึ่งของมาตรฐาน ECMAScript ที่ได้รับการยอมรับ ES5.1 เป็นรุ่นปัจจุบันและได้รับการสนับสนุนโดยทั่วไปดังนั้นจึงปลอดภัยที่จะกำหนดเป้าหมาย HTML5, CSS และ Unicode เวอร์ชันปัจจุบันก็ดีเช่นกัน ไม่มีคุณลักษณะ JavaScript, CSS3 หรือ HTML ทดลอง (คุณสมบัติที่มีคำนำหน้าผู้ขายหรือไม่มีข้อตกลง 100% ระหว่างเบราว์เซอร์) และไม่มีความเข้ากันได้เฉพาะเบราว์เซอร์ คุณสามารถเริ่มใช้คุณสมบัติใหม่ได้เมื่ออยู่ในมาตรฐานและทุกคนรองรับได้โดยไม่ต้องขึ้นหน้า
การสนับสนุน ES5 จะหมายถึงการลดลงของ IE8 หรือเก่ากว่าซึ่งฉันแนะนำต่อไปเนื่องจากต้องการแฮ็กเฉพาะเบราว์เซอร์ซึ่งจะไร้ประโยชน์ในอีกไม่กี่ปีข้างหน้า ผมขอแนะนำอย่างเคร่งครัดโหมด ES5 สำหรับโอกาสที่ดีที่สุดที่ยืนยาวซึ่งอันที่จริงชุดพื้นฐานความเข้ากันได้เบราว์เซอร์ของคุณในIE10 และรุ่นล่าสุดของคนอื่น เบราว์เซอร์เหล่านั้นยังมีการสนับสนุนดั้งเดิมสำหรับคุณลักษณะการตรวจสอบความถูกต้องของฟอร์มและตัวยึดตำแหน่ง HTML5 จำนวนมากซึ่งจะมีประโยชน์เป็นเวลานาน
รุ่นใหม่ของ ECMAScript รักษาความเข้ากันได้กับรุ่นเก่าดังนั้นมันจะง่ายกว่ามากที่จะนำคุณสมบัติที่จะเกิดขึ้นถ้ารหัสของคุณถูกเขียนตามมาตรฐานปัจจุบัน ตัวอย่างเช่นคลาสที่กำหนดโดยใช้classไวยากรณ์ที่จะเกิดขึ้นจะสามารถใช้แทนกันได้อย่างเต็มที่กับคลาสที่กำหนดด้วยconstructor.prototypeไวยากรณ์ปัจจุบัน ดังนั้นในห้าปีนักพัฒนาสามารถเขียนคลาสลงในรูปแบบ ES6 บนพื้นฐานแบบไฟล์ต่อไฟล์โดยไม่ทำลายอะไรเลย - แน่นอนว่าคุณมีการทดสอบหน่วยที่ดี
ประการที่สองหลีกเลี่ยงเฟรมเวิร์กแอป JavaScript ที่ทันสมัยโดยเฉพาะหากพวกเขาเปลี่ยนวิธีที่คุณใช้รหัสแอปของคุณ แบ็คโบนเป็นสิ่งที่โกรธแค้นจากนั้น SproutCore และ Ember เป็นและตอนนี้ Angular เป็นกรอบที่ทุกคนชื่นชอบในการโปรโมต อาจมีประโยชน์ แต่ก็มีบางอย่างที่เหมือนกัน: พวกเขามักจะทำลายแอพและต้องการเปลี่ยนรหัสเมื่อมีเวอร์ชันใหม่ออกมา ฉันเพิ่งอัปเดตแอป Angular 1.1 เป็น 1.2 และต้องมีการเขียนใหม่ ในทำนองเดียวกันการเปลี่ยนจาก Backbone 2 เป็น 3 ต้องมีการเปลี่ยนแปลง HTML มากมาย มาตรฐานมีการเคลื่อนไหวช้าด้วยเหตุผล แต่กรอบการทำงานเหล่านี้เคลื่อนไหวอย่างรวดเร็วและสิ่งที่ทำลายเป็นระยะมีค่าใช้จ่าย
ยิ่งกว่านั้นมาตรฐานทางการใหม่มักจะทิ้งกรอบเก่าไว้แล้วและเมื่อสิ่งนั้นเกิดขึ้นกรอบเหล่านั้นจะกลายพันธุ์ (โดยมีการเปลี่ยนแปลงที่แตกหัก) หรือถูกทิ้งไว้เบื้องหลัง คุณรู้ไหมว่าจะเกิดอะไรขึ้นกับห้องสมุดสัญญาการแข่งขันทั่วโลกเมื่อ ECMAScript 6 ได้รับการยอมรับและเบราว์เซอร์ทั้งหมดสนับสนุนคลาส Promise ที่เป็นมาตรฐาน พวกเขาจะล้าสมัยและนักพัฒนาจะหยุดอัปเดต หากคุณเลือกเฟรมเวิร์กที่ถูกต้องรหัสของคุณอาจปรับตัวได้ดีพอและถ้าคุณเดาได้ไม่ดีคุณจะต้องดูการปรับโครงสร้างที่สำคัญ
ดังนั้นหากคุณคิดที่จะใช้ห้องสมุดหรือกรอบงานของบุคคลที่สามถามตัวเองว่าการลบในอนาคตนั้นยากแค่ไหน หากเป็นเฟรมเวิร์กอย่าง Angular ที่ไม่สามารถลบออกได้โดยไม่ต้องสร้างแอปขึ้นใหม่จากศูนย์นั่นเป็นสัญญาณที่ดีที่ไม่สามารถใช้ในสถาปัตยกรรม 40 ปีได้ หากเป็นวิดเจ็ตปฏิทินบุคคลที่สามที่คุณสรุปด้วยมิดเดิลแวร์ที่กำหนดเองบางส่วนการแทนที่จะใช้เวลาสองสามชั่วโมง
สามให้โครงสร้างแอปที่ดีและสะอาด แม้ว่าคุณจะไม่ได้ใช้เฟรมเวิร์กแอพคุณก็ยังสามารถใช้ประโยชน์จากเครื่องมือของนักพัฒนาสร้างสคริปต์และการออกแบบที่ดี ฉันเป็นแฟนตัวยงของการจัดการการปิดของชุดเครื่องมือเนื่องจากมีน้ำหนักเบาและค่าใช้จ่ายจะถูกลบออกอย่างสมบูรณ์เมื่อสร้างแอปของคุณ LessCSS และ SCSS ยังเป็นเครื่องมือที่ยอดเยี่ยมสำหรับการจัดระเบียบสไตล์ชีทของคุณและสร้างสไตล์ชีท CSS ตามมาตรฐานสำหรับการเปิดตัว
คุณยังสามารถจัดระเบียบรหัสของคุณเองเป็นคลาสแบบใช้ครั้งเดียวด้วยโครงสร้าง MVC นั่นจะทำให้ง่ายขึ้นมากที่จะหวนคืนสู่อนาคตอีกหลายปีและรู้ว่าคุณกำลังคิดอะไรอยู่เมื่อคุณเขียนบางสิ่งและแทนที่เฉพาะส่วนที่ต้องการ
คุณควรปฏิบัติตามคำแนะนำของ W3C และป้องกันไม่ให้ข้อมูลนำเสนอตกอยู่ในความสมบูรณ์ของ HTML (นั่นรวมถึงกลโกงเช่นการให้องค์ประกอบชื่อคลาสในปัจจุบันเช่น "ข้อความสีเขียวขนาดใหญ่" และ "สองคอลัมน์กว้าง") หาก HTML ของคุณมีความหมายและ CSS เป็นการนำเสนอจะง่ายกว่ามากในการบำรุงรักษาและปรับใช้ สู่แพลตฟอร์มใหม่ในอนาคต นอกจากนี้ยังจะเพิ่มการสนับสนุนสำหรับเบราว์เซอร์พิเศษสำหรับคนตาบอดหรือคนพิการอีกด้วย
ประการที่สี่ทำการทดสอบอัตโนมัติและตรวจสอบให้แน่ใจว่าคุณมีความครอบคลุมที่เกือบเต็ม เขียนหน่วยทดสอบสำหรับทุกคลาสไม่ว่าจะเป็นฝั่งเซิร์ฟเวอร์หรือใน JavaScript ที่ส่วนหน้าตรวจสอบให้แน่ใจว่าแต่ละคลาสมีประสิทธิภาพตามสเป็คในทุกเบราว์เซอร์ที่รองรับ ทำการทดสอบเหล่านี้โดยอัตโนมัติจาก build ของคุณสำหรับทุกการกระทำ สิ่งนี้สำคัญสำหรับทั้งอายุการใช้งานและความน่าเชื่อถือเนื่องจากคุณสามารถตรวจจับข้อบกพร่องได้ตั้งแต่เนิ่น ๆ แม้ว่าเบราว์เซอร์ปัจจุบันจะบดบัง ทั้งกรอบการทดสอบ JSUnit ของจัสมินและ Google Closure นั้นดี
คุณจะต้องทำการทดสอบการใช้งาน UI แบบเต็มซึ่ง Selenium / WebDriver นั้นเก่ง โดยพื้นฐานแล้วคุณเขียนโปรแกรมที่ผ่าน UI ของคุณและใช้งานราวกับว่าบุคคลกำลังทดสอบ ต่อสายเหล่านั้นขึ้นไปยังบ็อตสร้าง
ท้ายสุดดังที่คนอื่น ๆ ได้กล่าวถึงข้อมูลของคุณคือราชา ลองคิดถึงรูปแบบการจัดเก็บข้อมูลของคุณและตรวจสอบให้แน่ใจว่ามันถูกสร้างขึ้นเพื่อความทนทาน ตรวจสอบให้แน่ใจว่าสคีมาข้อมูลของคุณนั้นมั่นคงและตรวจสอบให้แน่ใจว่าได้ทดสอบอย่างละเอียดในทุกการกระทำ และตรวจสอบให้แน่ใจว่าสถาปัตยกรรมเซิร์ฟเวอร์ของคุณสามารถปรับขนาดได้ สิ่งนี้สำคัญกว่าทุกอย่างที่คุณทำในส่วนหน้า