फ्रंट-एंड परिप्रेक्ष्य से उत्तर:
हर किसी को यह कहते हुए न सुनें कि यह नहीं किया जा सकता है, क्योंकि एक प्रयोगात्मक सैन फ्रांसिस्को स्टेट यूनिवर्सिटी की वेब सेवा जिसे मैंने 1996 में लिखा था, अंत में कुछ साल पहले इंटरनेट स्वर्ग में चली गई थी, और उस समय में एक भी ब्राउज़र संगतता को ठीक करने की आवश्यकता नहीं थी ; यह आपके 40 साल के लक्ष्य का लगभग आधा है। और यह स्टैनफोर्ड रिसर्च इंस्टीट्यूट प्रोजेक्ट के लिए 1998 में किए गए जावास्क्रिप्ट-आधारित फ्रंट-एंड को कुछ साल बाद कुछ फ्लैशियर के साथ बदल दिया गया था, लेकिन कोई कारण नहीं है कि मूल यूआई अभी भी मामूली संगतता सुधारों के साथ आज भी नहीं चल सकता है।
चाल यह सुनिश्चित करने के लिए है कि आपका ऐप केवल व्यापक रूप से समर्थित W3C / ECMA मानकों का उपयोग करता है और आपके नियंत्रण में एक साफ डिजाइन है। जबकि ट्रेंडी 90-युग की तकनीक के लिए लिखे गए बहुत सारे वेब ऐप अच्छी तरह से काम नहीं करेंगे या आज के समय में, प्रमुख मानकों को लिखे गए 90-युग के वेब ऐप अभी भी करते हैं। वे निष्क्रिय दिख सकते हैं, लेकिन वे काम करते हैं।
यहां लक्ष्य एक वेब ऐप लिखना नहीं है जो उनके सर्वर पर जाएगा और 40 साल तक बिना किसी को फिर से इसे छूए रहेगा। यह एक नींव का निर्माण करना है जो अभी भी लाइन के नीचे दशकों तक उपयोग में हो सकता है, जो खरोंच से पुनर्निर्माण किए बिना नई सुविधाओं का समर्थन करने के लिए बढ़ सकता है।
सबसे पहले, आपको आधिकारिक मानकों और केवल आधिकारिक मानकों पर कोड करना होगा । कोई जावास्क्रिप्ट सुविधाएँ एक अनुसमर्थित ECMAScript मानक का हिस्सा नहीं हैं; ES5.1 वर्तमान संस्करण है और आम तौर पर समर्थित है ताकि लक्ष्य के लिए सुरक्षित हो। इसी तरह, HTML5, CSS और यूनिकोड के वर्तमान संस्करण अच्छे हैं। कोई प्रयोगात्मक जावास्क्रिप्ट, CSS3 या HTML सुविधाएँ (वेंडर-उपसर्ग वाले या ब्राउज़रों के बीच 100% समझौते के बिना)। और कोई ब्राउज़र-विशिष्ट संगतता हैक नहीं करता है। एक बार मानक में होने के बाद आप एक नई सुविधा का उपयोग करना शुरू कर सकते हैं और हर कोई बिना उपसर्ग के इसका समर्थन करता है।
ES5 सपोर्ट का मतलब IE8 या उससे पहले ड्राप करना होगा, जो मैं वैसे भी सुझाव देता हूं क्योंकि इसके लिए ब्राउज़र-विशिष्ट हैक्स की आवश्यकता होती है जो कुछ वर्षों में बेकार हो जाएंगे। मैं दीर्घायु में सबसे अच्छे मौके के लिए ES5 के स्ट्रिक्ट मोड का सुझाव देता हूं, जो वास्तव में IE10 और अन्य सभी के हाल के संस्करणों में आपके आधारभूत ब्राउज़र संगतता को निर्धारित करता है । उन ब्राउज़र को एचटीएमएल 5 के कई फॉर्म सत्यापन और प्लेसहोल्डर सुविधाओं के लिए मूल समर्थन भी है, जो बहुत लंबे समय तक उपयोगी होंगे।
ECMAScript के नए संस्करण पुराने संस्करणों के साथ संगतता बनाए रखते हैं, इसलिए यदि आपके कोड को वर्तमान मानकों के अनुसार लिखा गया है, तो आगामी सुविधाओं को अपनाना बहुत आसान होगा। उदाहरण के लिए, आगामी classसिंटैक्स का उपयोग करके परिभाषित कक्षाएं वर्तमान constructor.prototypeसिंटैक्स के साथ परिभाषित कक्षाओं के साथ पूरी तरह से विनिमेय होंगी । इसलिए पांच साल में एक डेवलपर कुछ भी बिना - निश्चित रूप से यह मानकर ईएस 6 प्रारूप में कक्षाओं को फाइल-बाय-फाइल के आधार पर फिर से लिख सकता है कि आपके पास भी अच्छी यूनिट परीक्षण हैं।
दूसरा, ट्रेंडी जावास्क्रिप्ट ऐप फ्रेमवर्क से बचें, खासकर यदि वे आपके ऐप को कोड करने के तरीके को बदलते हैं। बैकबोन सभी क्रोध था, फिर स्प्राउटकोर और एम्बर थे, और अब एंगुलर की रूपरेखा हर किसी को बढ़ावा देने के लिए प्यार करती है। वे उपयोगी हो सकते हैं, लेकिन उनके पास भी कुछ सामान्य है: वे अक्सर ऐप को तोड़ते हैं और नए संस्करणों के आने पर कोड परिवर्तन की आवश्यकता होती है और उनकी लंबी उम्र संदिग्ध होती है। मैंने हाल ही में एक कोणीय 1.1 ऐप को 1.2 पर अपडेट किया, और काफी कुछ फिर से लिखना पड़ा। इसी तरह, बैकबोन 2 से 3 में जाने के लिए बहुत से HTML परिवर्तनों की आवश्यकता होती है। एक कारण के लिए मानक धीमी गति से चल रहे हैं, लेकिन ये ढांचे तेजी से आगे बढ़ते हैं और समय-समय पर टूटने वाली चीजें लागत होती हैं।
साथ ही, नए आधिकारिक मानक अक्सर पुराने ढाँचों को अप्रचलित छोड़ देते हैं, और जब ऐसा होता है तो वे ढाँचे या तो बदल जाते हैं (परिवर्तनों को तोड़ने के साथ) या पीछे रह जाते हैं। आप जानते हैं कि ECMAScript 6 के अनुसमर्थन के बाद दुनिया के सभी प्रतिस्पर्धी वादे पुस्तकालयों का क्या होने वाला है और सभी ब्राउज़र इसके मानकीकृत वादे वर्ग का समर्थन करते हैं? वे अप्रचलित हो जाएंगे और उनके डेवलपर्स उन्हें अपडेट करना बंद कर देंगे। यदि आपने सही ढाँचा चुना है तो आपका कोड पर्याप्त रूप से अनुकूल हो सकता है, और यदि आपने खराब अनुमान लगाया है तो आप एक बड़े रिफैक्टिंग को देख रहे होंगे।
इसलिए यदि आप थर्ड-पार्टी लाइब्रेरी या फ्रेमवर्क को अपनाने की सोच रहे हैं, तो अपने आप से पूछें कि भविष्य में इसे निकालना कितना कठिन होगा। अगर यह एंगुलर जैसा ढाँचा है जिसे कभी भी आपके ऐप को स्क्रैच के पुनर्निर्माण के बिना हटाया नहीं जा सकता है, तो यह एक अच्छा संकेत है कि इसे 40 साल की वास्तुकला में इस्तेमाल नहीं किया जा सकता है। यदि यह एक तृतीय-पक्ष कैलेंडर विजेट है जिसे आपने कुछ कस्टम मिडलवेयर के साथ अमूर्त किया है, तो इसे बदलने में कुछ घंटे लगेंगे।
तीसरा, इसे एक अच्छी, स्वच्छ ऐप संरचना दें। यहां तक कि अगर आप ऐप फ्रेमवर्क का उपयोग नहीं कर रहे हैं, तब भी आप डेवलपर टूल का लाभ उठा सकते हैं, स्क्रिप्ट का निर्माण कर सकते हैं, और एक अच्छा साफ डिजाइन बना सकते हैं। मैं व्यक्तिगत रूप से क्लोजर टूलकिट के निर्भरता प्रबंधन का प्रशंसक हूं क्योंकि यह हल्का है और इसका ओवरहेड आपके ऐप के निर्माण पर पूरी तरह से हटा दिया गया है। लेससीएसएस और एससीएसएस आपकी स्टाइलशीट को व्यवस्थित करने और रिलीज के लिए मानक-आधारित सीएसएस स्टाइलशीट के निर्माण के लिए भी महान उपकरण हैं।
आप MVC संरचना के साथ एकल-उपयोग कक्षाओं में अपना स्वयं का कोड भी व्यवस्थित कर सकते हैं। इससे भविष्य में कई वर्षों तक वापस आने में बहुत आसानी होगी और पता चलेगा कि आप क्या सोच रहे थे जब आपने कुछ लिखा था, और केवल उन हिस्सों को बदलने के लिए जिन्हें इसकी आवश्यकता है।
आपको W3C की सलाह का भी पालन करना चाहिए और प्रस्तुति संबंधी जानकारी को अपने HTML से पूरी तरह से बाहर रखना चाहिए। (इसमें "बड़ा-हरा-पाठ" और "दो-कॉलम-चौड़ा" जैसे तत्वों को प्रस्तुत करने वाले वर्ग नाम दिए गए हैं।) यदि आपका एचटीएमएल शब्दार्थिक है और सीएसएस प्रस्तुतिकरण है, तो इसे बनाए रखना और अनुकूलित करना बहुत आसान होगा। भविष्य में नए प्लेटफार्मों के लिए। अंधे या विकलांग लोगों के लिए विशेष ब्राउज़रों के लिए समर्थन जोड़ना भी आसान होगा।
चौथा, अपने परीक्षणों को स्वचालित करें और सुनिश्चित करें कि आपके पास लगभग पूर्ण कवरेज है। हर वर्ग के लिए इकाई परीक्षण लिखें, चाहे सर्वर-साइड या जावास्क्रिप्ट में। सामने के छोर पर, सुनिश्चित करें कि प्रत्येक समर्थित ब्राउज़र में प्रत्येक वर्ग अपनी कल्पना के अनुसार करता है। हर कमिट के लिए अपने बिल्ड बॉट से इन परीक्षणों को स्वचालित करें। यह दीर्घायु और विश्वसनीयता दोनों के लिए महत्वपूर्ण है, क्योंकि आप वर्तमान ब्राउज़रों को अस्पष्ट करते हुए भी बग को जल्दी पकड़ सकते हैं। जैस्मीन और गूगल क्लोजर की JSUnit आधारित परीक्षण रूपरेखा दोनों अच्छी हैं।
आप पूर्ण UI कार्यात्मक परीक्षण भी चलाना चाहेंगे, जो सेलेनियम / वेबड्राइवर अच्छे हैं। मूल रूप से, आप एक प्रोग्राम लिखते हैं जो आपके UI के माध्यम से कदम रखता है और इसका उपयोग करता है जैसे कि कोई व्यक्ति इसका परीक्षण कर रहा था। निर्माण बॉट के लिए भी उन्हें तार।
अंत में, जैसा कि दूसरों ने उल्लेख किया है कि आपका डेटा राजा है। अपने डेटा स्टोरेज मॉडल के माध्यम से सोचें और सुनिश्चित करें कि यह पिछले तक बनाया गया है। सुनिश्चित करें कि आपका डेटा स्कीमा ठोस है, और यह सुनिश्चित करें कि हर कमिट पर अच्छी तरह से परीक्षण किया गया है। और सुनिश्चित करें कि आपका सर्वर आर्किटेक्चर स्केलेबल है। यह सामने वाले छोर पर आपके द्वारा किए जाने वाले कार्यों से भी अधिक महत्वपूर्ण है।