लंबे जीवनकाल के लिए वेब एप्लिकेशन विकसित करना (20+ वर्ष)

160

मैं वर्तमान में सरकारी भूमि नियोजन के लिए एक वेब एप्लिकेशन विकसित कर रहा हूं। अनुप्रयोग अधिकतर ब्राउज़र में चलता है, डेटा को लोड करने और सहेजने के लिए ajax का उपयोग करता है।

मैं प्रारंभिक विकास करूंगा, और फिर स्नातक (यह एक छात्र का काम है)। इसके बाद, बाकी टीम आवश्यकतानुसार सामयिक सुविधा जोड़ देगी। उन्हें पता है कि कोड कैसे करना है, लेकिन वे ज्यादातर भूमि-नियोजन विशेषज्ञ हैं।

जिस गति से जावास्क्रिप्ट तकनीकें बदलती हैं, उसे देखते हुए, मैं कैसे कोड लिख सकता हूं जो अभी भी 20 साल अभी तक काम करेगा? विशेष रूप से, जो पुस्तकालयों, प्रौद्योगिकियों और डिजाइन विचारों का उपयोग मैं अपने कोड को भविष्य में प्रूफ करने के लिए (या बचना) करूं?

javascript web-development future-proof

— सज्जन
स्रोत

94

मैंने 1966 के अंत में फोरट्रान में प्रोग्रामिंग शुरू की, इसलिए मेरे पास इस तरह के मुद्दे के बारे में सोचने के लिए बहुत समय था। यदि आप कभी भी एक 50% से अधिक जवाब दे सकते हैं, तो कृपया मुझे बताएं। इस बीच, लगभग निश्चित अपरिहार्य

— किशोरावस्था

11

सॉफ्टवेयर इंजीनियरिंग में हमेशा के लिए कुछ भी नहीं। बैंकों में केवल HOST और क्योंकि कोई भी ऐसे महत्वपूर्ण सिस्टम को अपडेट करने की हिम्मत नहीं करता है। खैर, मुझे लगता है कि मल्लाह में चल रहे कार्यक्रम की भी गिनती है।

— Laiv

9

@ लिव कुछ समय पहले, मैंने वैक्स / वीएमएस पर चल रहे स्विफ्ट मैसेजिंग का उपयोग करके बैंकर्स ट्रस्ट के लिए मनी ट्रांसफर एप्लिकेशन पर काम किया। कुछ साल बाद, स्विफ्ट eol'ed (जीवन के अंत) सभी VMS समर्थन करते हैं। लड़का, कि कुछ समस्याओं का कारण बना ... और मुझे BTCo में एक और अनुबंध प्रदान किया। जैसा मैंने ऊपर कहा, "नौकरी की सुरक्षा" :)। वैसे भी, मेरी बात यह है कि महत्वपूर्ण वित्तीय बाजार एप्लिकेशन अप्रचलन के लिए प्रतिरक्षा नहीं हैं।

— जॉन फोर्कोश

102

"कोड लिखें जो अगले डेवलपर समझ सकता है" के बारे में कैसे? यदि और जब कोड इस बिंदु पर अप्रचलित हो जाता है कि उन्हें इसे अपडेट करने के लिए प्रोग्रामर खोजने की आवश्यकता होगी, तो सबसे अच्छा परिदृश्य यह है कि वे समझेंगे कि आपका कोड क्या कर रहा है (और शायद कुछ निर्णय क्यों किए गए थे)।

— डेविड स्टार्क

38

बस सादे पुराने HTML का उपयोग करें, कोई जेएस, कोई प्लगइन्स, कुछ भी नहीं फैंसी। यदि यह लिंक्स में काम करता है, तो यह सभी समय के लिए अच्छा है।

— गयुस

132

ऐसे जीवनकाल के लिए सॉफ्टवेयर की योजना बनाना मुश्किल है, क्योंकि हम नहीं जानते कि भविष्य क्या है। थोड़ा सा संदर्भ: जावा को 21 साल पहले 1995 में प्रकाशित किया गया था। XmlHttpRequest पहली बार इंटरनेट एक्सप्लोरर 5 के लिए मालिकाना एक्सटेंशन के रूप में उपलब्ध हुआ, जो कि 17 साल पहले 1999 में प्रकाशित हुआ था। सभी प्रमुख ब्राउज़रों में उपलब्ध होने तक लगभग 5 साल लग गए। आप जिस 20 साल की कोशिश कर रहे हैं, वह उस समय के बारे में है जब अमीर वेब एप्लिकेशन भी मौजूद हैं।

कुछ चीजें निश्चित रूप से तब से ही बनी हुई हैं। एक मजबूत मानकीकरण का प्रयास किया गया है, और अधिकांश ब्राउज़र विभिन्न मानकों में शामिल हैं। एक वेब साइट जो 15 साल पहले ब्राउज़रों में काम करती थी, अब भी वही काम करेगी, बशर्ते कि यह काम करे क्योंकि यह सभी ब्राउज़रों के सामान्य सबसेट को लक्षित करती है, न कि इसलिए कि यह प्रत्येक ब्राउज़र के लिए वर्कअराउंड का उपयोग करती है।

अन्य चीजें आईं और चली गईं - सबसे प्रमुख रूप से फ्लैश। फ्लैश में कई तरह की समस्याएं थीं, जिनके निधन के कारण। सबसे महत्वपूर्ण बात, यह एक ही कंपनी द्वारा नियंत्रित किया गया था। फ्लैश प्लेटफॉर्म के अंदर प्रतिस्पर्धा के बजाय, फ्लैश और एचटीएमएल 5 के बीच प्रतिस्पर्धा थी - और एचटीएमएल 5 जीता।

इस इतिहास से, हम कुछ सुराग एकत्र कर सकते हैं:

इसे सरल रखें: किसी भी वर्कअराउंड का उपयोग किए बिना, अभी क्या काम करें। यह व्यवहार भविष्य में बैकवर्ड-संगतता कारणों से लंबे समय तक उपलब्ध रहने की संभावना है।
स्वामित्व तकनीकों पर निर्भरता से बचें, और खुले मानकों को प्राथमिकता दें।

जावास्क्रिप्ट दुनिया आज पुस्तकालयों और चौखटे के एक उच्च प्रवाह के साथ अपेक्षाकृत अस्थिर है। हालांकि, उनमें से लगभग 20 वर्षों में कोई भी बात नहीं होगी - एकमात्र "फ्रेमवर्क" मैं निश्चित हूं कि अभी भी तब तक उपयोग किया जाएगा जब तक वेनिला जेएस है ।

यदि आप एक पुस्तकालय या उपकरण का उपयोग करना चाहते हैं क्योंकि यह वास्तव में विकास को बहुत आसान बनाता है, तो पहले सुनिश्चित करें कि यह आज के समर्थित मानकों पर बनाया गया है। फिर आपको लाइब्रेरी या टूल डाउनलोड करना होगा और इसे अपने स्रोत कोड के साथ शामिल करना होगा। आपके कोड रिपॉजिटरी में सिस्टम को चलाने योग्य बनाने के लिए आवश्यक सब कुछ शामिल होना चाहिए। बाहरी कुछ भी एक निर्भरता है जो भविष्य में टूट सकती है। इसका परीक्षण करने का एक दिलचस्प तरीका यह है कि अपने कोड को एक अंगूठे ड्राइव में कॉपी करें, एक अलग ऑपरेटिंग सिस्टम के साथ एक नए कंप्यूटर पर जाएं, इसे इंटरनेट से डिस्कनेक्ट करें, और देखें कि क्या आप अपने फ्रंटएंड को काम कर सकते हैं। जब तक आपकी परियोजना में सादे HTML + CSS + जावास्क्रिप्ट शामिल हैं, तब तक शायद कुछ पुस्तकालय, आप के पास होने जा रहे हैं।

— आमोन
स्रोत

4

वेनिला जेएस में बड़े पैमाने पर आवेदन अब तक नहीं हैं। ES6 पहले से ही किसी तरह समस्या को ठीक करता है, लेकिन एक कारण है कि टाइप या टाइपस्क्रिप्ट लोकप्रियता प्राप्त कर रहे हैं।

— एंडी

34

@ डेविडपैकर बिल्कुल, टाइपस्क्रिप्ट आदि महान हैं और विकास को आसान बनाते हैं। लेकिन जैसे ही मैं एक बिल्ड प्रक्रिया शुरू करता हूं, बिल्ड प्रक्रिया के लिए आवश्यक सभी उपकरण निर्भरता बन जाते हैं: एनओडीजेएस, गुलप, एनपीएम - जो कहते हैं कि एनपीएम 20 वर्षों में अभी भी ऑनलाइन होगा? मुझे निश्चित होने के लिए अपनी खुद की रजिस्ट्री चलानी होगी। यह असंभव नहीं है। लेकिन कुछ बिंदु, उन चीजों को छोड़ देना बेहतर है जो विकास को केवल तुरंत आसान बनाते हैं, लेकिन लंबे समय में नहीं।

— आमोन

30

@DavidPacker कई गतिशील भाषाएं हैं, और आश्चर्यजनक रूप से, कई सफल सिस्टम स्मॉलटॉक, रूबी, पर्ल, पायथन, यहां तक कि पीएचपी और जेएस के साथ बनाए गए हैं। जबकि सांख्यिकीय रूप से टाइप की जाने वाली भाषाएं अधिक रख-रखाव वाली होती हैं जबकि गतिशील भाषाएं तेजी से प्रोटोटाइप के लिए बेहतर होती हैं, लेकिन अनुवर्ती जेएस को लिखना असंभव नहीं है। एक संकलक की अनुपस्थिति में, टीम में उच्च मध्य कौशल, शिल्प कौशल, और स्पष्ट कोड संगठन पर अतिरिक्त जोर और भी महत्वपूर्ण हो जाता है। मुझे व्यक्तिगत रूप से लगता है कि प्रकार सब कुछ आसान बनाते हैं, लेकिन वे कोई चांदी की गोली नहीं हैं।

— आमोन

4

क्या मैंने "अलग-अलग मशीन पर usb और परीक्षण" पढ़ा है? क्यों न केवल वर्चुअलबॉक्स को स्पिन किया जाए या सिर्फ इनकॉग्निटो मोड (एथिक्स डिसेबल के साथ) का उपयोग किया जाए।

— 15

5

मुझे यकीन नहीं है कि वेनिला जेएस अब से 20 साल बाद एक निश्चित चीज होगी । इसका इतिहास पथरीला और प्रायोगिक था, और इसने रास्ते में भारी मात्रा में गड्ढा कर लिया था, यहां तक कि यह एक रमणीय और प्रभावी भाषा के रूप में उभरा है (मैं व्यक्तिगत रूप से जावास्क्रिप्ट या टाइपस्क्रिप्ट स्वयं पसंद करता हूं)। यह कल्पना करना मुश्किल नहीं है कि विक्रेता अच्छी तरह से कुछ या सभी cruft को खोद सकते हैं, चाहे इसका मतलब एक नई वैकल्पिक भाषा की पेशकश करना शुरू करना हो - जैसा कि Google को डार्ट के साथ प्रस्ताव करना प्रतीत होता है, हालांकि ऐसा लगता है कि कहीं भी नहीं गया है जेएस के हिस्से को हटाकर और फिर हटाकर।

— केरेन

178

आपके कोड के 20 साल तक जीवित रहने से भी अधिक महत्वपूर्ण यह है कि आपका डेटा 20 वर्षों तक जीवित रहता है। संभावना है, यह संरक्षण के लायक बात है। यदि आपके डेटा के साथ काम करना आसान है, तो नई तकनीक के साथ इसके ऊपर एक वैकल्पिक प्रणाली बनाना आसान होगा।

तो एक स्पष्ट और अच्छी तरह से प्रलेखित डेटा मॉडल के साथ शुरू करें।
ओरेकल ^[1] या SQL सर्वर जैसे एक स्थापित, अच्छी तरह से समर्थित डेटाबेस सिस्टम का उपयोग करें ।
बुनियादी सुविधाओं का उपयोग करें, आकर्षक नए लोगों को निचोड़ने की कोशिश न करें।
चतुर पर सरल पसंद करते हैं ।
स्वीकार करें कि प्रदर्शन जैसे पहलुओं की कीमत पर भविष्य की स्थिरता आ सकती है। उदाहरण के लिए, आपको संग्रहीत प्रक्रियाओं का उपयोग करने के लिए लुभाया जा सकता है, लेकिन ये भविष्य की स्थिरता को सीमित कर सकते हैं यदि वे किसी को सिस्टम को सरल भंडारण समाधान में स्थानांतरित करने से रोकते हैं।

एक बार जब आपके पास ऐसा हो जाता है, तो ऐप को भविष्य में प्रूफ करना सरल हो जाता है, क्योंकि यह डेटा मॉडल के आसपास एक आवरण है, और यदि 10 वर्षों में, कोई भी जावास्क्रिप्ट का उपयोग नहीं करता है, तो इसे बदला जा सकता है, उदाहरण के लिए, और आपको ऐप को माइग्रेट करना होगा WASM या कुछ और। चीजों को मॉड्यूलर रखना, कम अन्योन्याश्रित, आसान भविष्य के रखरखाव के लिए अनुमति देता है।

^[१] इस उत्तर के लिए अधिकांश टिप्पणियां ओरेकल को एक डीबी के लिए उपयोग करने के खिलाफ एक मजबूत रुख लेती हैं, जो पूरी तरह से वैध कारणों का हवाला देते हुए कहती हैं कि ओरेकल के साथ काम करने के लिए दर्द क्यों है, इसमें सीखने की अवस्था और स्थापना ओवरहेड है। ओरेकल को डीबी के रूप में चुनते समय ये पूरी तरह से वैध चिंताएं हैं, लेकिन हमारे मामले में, हम एक सामान्य उद्देश्य डीबी की तलाश नहीं कर रहे हैं, लेकिन एक जहां प्राथमिक चिंता कायम है । 70 के दशक के आखिर से ओरेकल लगभग हो गया है और आने वाले कई वर्षों तक प्रोबेल का समर्थन किया जाएगा, और इसमें सलाहकारों का एक बड़ा पारिस्थितिकी तंत्र और समर्थन विकल्प हैं जो आपको इसे चालू रखने में मदद कर सकते हैं। क्या यह कई कंपनियों के लिए एक गड़बड़ है? ज़रूर। लेकिन क्या यह आपके डेटाबेस को 20 साल तक चालू रखेगा ? बहुत संभावना है।

— अवनर शाहर-कश्तन
स्रोत

141

मुझे खेद है, लेकिन मुझे यह कहना होगा। यदि आप ओरेकल का उपयोग करते हैं, तो आप "आसानी से काम करना" के संबंध में पैर से सभी को शूट कर रहे हैं। ओरेकल के साथ काम करना आसान नहीं है। कार्यक्षमता का एक बड़ा सौदा है कि SQL सर्वर, PostgreSQL, और शायद भी MySQL सरल बनाने के लिए, Oracle या तो बाहर फ्लैट है या मुश्किल नहीं बनाता है। ओरेकल के साथ मेरे पास अन्य डीबी के साथ उतनी बेवकूफ समस्याएं नहीं हैं; यहां तक कि सिर्फ ग्राहक को स्थापित करने से बट में भारी दर्द होता है। यहां तक कि गुगली करना भी कठिन है। यदि आप "काम करना आसान है" चाहते हैं, तो ओरेकल से दूर रहें।

— jpmc26

4

डेटा को यथासंभव सरल रखने के लिए +1। इसके लिए मानक SQL का उपयोग करें जैसे कि oracle विशिष्ट + ऑपरेटर के बजाय OUTER JOIN का उपयोग करें । साधारण टेबल लेआउट का उपयोग करें। न अपने टेबल को पूर्ण अधिकतम स्तर तक सामान्य करें। यह तय करें कि क्या कुछ तालिकाओं में निरर्थक डेटा हो सकता है या यदि आपको वास्तव में एक नई तालिका बनानी चाहिए ताकि हर मूल्य केवल एक बार मौजूद हो। संग्रहीत कार्यविधियाँ विक्रेता विशिष्ट हैं ? यदि हाँ, तो उनका उपयोग न करें। पसंद की अपनी वर्तमान भाषा की सबसे बड़ी विशेषता का उपयोग न करें: मैंने OOP-Features के बिना अधिक COBOL प्रोग्राम देखे हैं, फिर उनके साथ। और पूरी तरह से ठीक है।

— some_coder

3

@ jpmc26 मैं ओरेकल के बारे में आपकी भावनाओं से सहमत हूं, लेकिन जैसा कि मैंने कहा, "साथ काम करना आसान है" यहां मुख्य आवश्यकता नहीं है। मैं यहां एक ठोस रूप से समर्थित मंच पसंद करता हूं, भले ही इसके साथ काम करने के लिए दर्द हो। क्योंकि जब 20 वर्षों में परिशोधन होता है, तो यह बहुत बुरा नहीं है।

— अवनर शाहर-कश्तन

8

दरअसल ओरेकल से बचें। आज अस्तित्व में एकमात्र डीबी है जो 20 वर्षों में एक बुरी पसंद की तरह नहीं दिखती है।

— जोशुआ

3

मुझे लगता है कि महान ओपन सोर्स DBMS जोड़ना बेहतर है क्योंकि वहाँ एक अच्छा मौका है कि वे मर नहीं होगा। यदि ओरेकल 10 साल में पैसा बनाना बंद कर देता है, तो 11 में चला जाएगा। PostreSQL शर्त लगाने के लिए सबसे अच्छा घोड़ा की तरह लगता है।

— शौतिह

36

अमोन द्वारा पिछला उत्तर महान है, लेकिन दो अतिरिक्त बिंदु हैं जिनका उल्लेख नहीं किया गया था:

यह केवल ब्राउज़रों के बारे में नहीं है; उपकरण भी मायने रखते हैं।

अमोन इस तथ्य का उल्लेख करता है कि "वेब साइट जिसने 15 साल पहले ब्राउज़रों के बीच काम किया था, वह अभी भी वही काम करेगी" , जो सच है। हालाँकि, बनाई गई वेबसाइटों को देखें, पंद्रह नहीं, बल्कि दस साल पहले, जो बनाते समय, अधिकांश उपयोगकर्ताओं के लिए अधिकांश ब्राउज़रों में काम करती थी। आज, उपयोगकर्ताओं का एक बड़ा हिस्सा उन वेबसाइटों का उपयोग करने में सक्षम नहीं होगा, इसलिए नहीं कि ब्राउज़र बदल गए, बल्कि इसलिए कि उपकरणों ने किया। वे वेबसाइटें मोबाइल उपकरणों की छोटी स्क्रीन पर भयानक दिखेंगी , और अंत में यह बिल्कुल भी काम नहीं करेगा कि डेवलपर्स ने जावास्क्रिप्ट clickइवेंट पर भरोसा करने का फैसला किया , बिना उस tapघटना को जानना भी महत्वपूर्ण है।
आप एक गलत विषय पर ध्यान केंद्रित कर रहे हैं।

प्रौद्योगिकी परिवर्तन एक बात है, लेकिन एक अधिक महत्वपूर्ण आवश्यकताओं का परिवर्तन है । उत्पाद को स्केल करने की आवश्यकता हो सकती है, या अतिरिक्त सुविधाओं की आवश्यकता हो सकती है, या इसके वर्तमान सुविधाओं को बदलने की आवश्यकता हो सकती है।

इससे कोई फर्क नहीं पड़ता कि ब्राउज़र, या डिवाइस, या W3C, या ... जो कुछ भी होगा।

यदि आप अपने कोड को एक तरह से लिखते हैं तो इसे रिफैक्ट किया जा सकता है , उत्पाद तकनीक के साथ विकसित होगा।

यदि आप अपना कोड इस तरह से लिखते हैं कि कोई भी इसे समझ नहीं सकता है और इसे बनाए रख सकता है, तो प्रौद्योगिकी कोई मायने नहीं रखती है: कोई भी पर्यावरणीय परिवर्तन आपके आवेदन को वैसे भी नीचे लाएगा, जैसे कि एक अलग ऑपरेटिंग सिस्टम में माइग्रेशन, या प्राकृतिक डेटा वृद्धि के रूप में एक साधारण चीज भी। ।

एक उदाहरण के रूप में, मैं दस साल के लिए सॉफ्टवेयर विकास में काम करता हूं। दर्जनों और दर्जनों परियोजनाओं के बीच, केवल दो थे जिन्हें मैंने प्रौद्योगिकी के कारण बदलने का फैसला किया , अधिक सटीक क्योंकि PHP पिछले दस वर्षों में बहुत विकसित हुआ। यह ग्राहक का निर्णय भी नहीं था: यदि साइट PHP के नेमस्पेस या क्लोजर का उपयोग करती है तो वह कम देखभाल नहीं करेगा। हालांकि, नई आवश्यकताओं और मापनीयता से संबंधित परिवर्तन, बहुत सारे थे!

— आर्सेनी मूरज़ेंको
स्रोत

4

विभिन्न स्क्रीन आकारों को अपनाना एक सामान्य समस्या है। मोबाइल इस समय सम्मोहित चीज है, लेकिन अगर आप इस वेबसाइट को एक पूर्ण स्क्रीन ब्राउज़र विंडो में देख रहे हैं जिसमें पर्याप्त रिज़ॉल्यूशन वाली स्क्रीन है, तो बहुत सारी खाली (व्यर्थ) जगह है। लेआउट बदलना और जानकारी कैसे उपलब्ध पिक्सल का सबसे अच्छा उपयोग करने के लिए प्रस्तुत किया गया है वास्तव में स्मार्ट तरीके से कभी नहीं हुआ। मोबाइल ने यह स्पष्ट किया। लेकिन दूसरी दिशा में सोचना हाथ में लिए सवाल के लिए अधिक महत्वपूर्ण हो सकता है।

— नल

9

@null: जब मैं आपकी टिप्पणी से सहमत हूं, तो StackExchange वेबसाइटें आपकी बात का सर्वश्रेष्ठ चित्रण नहीं हो सकती हैं। डेटा को प्रदर्शित करने के लिए, मेरा मानना है कि StackExchange डिजाइनरों / डेवलपर्स ने इसे प्रदर्शित करने का एक बड़ा काम किया क्योंकि इसे प्रदर्शित करने की आवश्यकता है, जिसमें बड़े मॉनिटर भी शामिल हैं। आप मुख्य कॉलम को व्यापक नहीं बना सकते हैं, क्योंकि पाठ को पढ़ना अधिक कठिन हो जाएगा, और आप कई कॉलमों का उपयोग नहीं कर सकते क्योंकि यह छोटे प्रश्नों और उत्तरों के लिए अच्छा नहीं लगेगा।

— बजे आर्सेनी मूरज़ेंको

एक अन्य अच्छा उदाहरण 'होवर' घटना है जिसका उपयोग अक्सर मेनू सिस्टम में किया जाता था। उनमें से कई मेनू स्पर्श उपकरणों के साथ बुरी तरह से विफल हो जाते हैं।

— जस्टास

आप उपकरणों के बारे में 110% (या अधिक) सही हैं, और मैं आपको दशकों पुराने उदाहरण प्रदान कर सकता हूं। 1980 के उत्तरार्ध में मैंने आईबीएम मेनफ्रेम और सिंक्रोनस 3270 टर्मिनलों पर चलने वाले CICS के अनुप्रयोगों पर काम किया। CICS क्षेत्र सर्वर-साइड एप्स के अनुरूप है, जो एक समय में डेटा को स्क्रीन-फुल भेजकर सिंक्रोनस टर्मिनलों को भेजता है, जो इस प्रकार समर्पित-डिवाइस-ब्राउज़र के अनुरूप होते हैं। और CICS प्रोग्रामिंग शायद 80% Cobol, 20% PL / 1 थी। उन दोनों भाषाओं में आजकल ज्यादातर अप्रचलित हैं, और 1990 के शुरुआती दिनों में यूनिक्स वर्कस्टेशन (सूर्य और अपोलो) की उपस्थिति ने

— सिक्स को

31

आप पिछले 20 वर्षों की योजना नहीं बनाते हैं। सादा और सरल। इसके बजाय आप अपने लक्ष्यों को कंपार्टमेंटलाइज़ेशन में शिफ्ट करें।

क्या आपका ऐप डेटाबेस अज्ञेयवादी है? यदि आपको अभी डेटा-बेस स्विच करना था, तो आप कर सकते थे। क्या आपकी तर्क भाषा अज्ञेय है। अगर आपको अभी पूरी तरह से नई भाषा में ऐप को फिर से लिखना है, तो क्या आप कर सकते थे? क्या आप SRP और DRY जैसे अच्छे डिज़ाइन दिशानिर्देशों का पालन कर रहे हैं?

मेरे पास 20 साल तक के लिए परियोजनाएं हैं, और मैं आपको बता सकता हूं कि चीजें बदल जाती हैं। पॉप-अप की तरह। 20 साल पहले आप एक पॉप-अप पर भरोसा कर सकते थे, आज आप नहीं कर सकते। XSS 20 साल पहले की बात नहीं थी, अब आपको CORS का हिसाब देना होगा।

तो आप जो करते हैं वह सुनिश्चित करता है कि आपका तर्क अच्छी तरह से अलग हो गया है, और आप किसी भी तकनीक का उपयोग करने से बचते हैं जो आपको एक विशिष्ट विक्रेता के लिए लॉक कर देता है।

यह कई बार बहुत मुश्किल हो सकता है। उदाहरण के लिए .NET तर्क और MSSQL डेटाबेस एडॉप्टर के लिए विधि को उजागर करने में बहुत अच्छा है जो अन्य एडेप्टर में समकक्ष नहीं है। MSSQL आज एक अच्छी योजना की तरह लग सकता है लेकिन क्या यह 20 साल तक रहेगा? कौन जाने। अनुप्रयोग के अन्य भागों से डेटा परत पूरी तरह से अलग होने के लिए इसे कैसे प्राप्त करें, इसका एक उदाहरण। फिर, सबसे खराब स्थिति, आपको केवल संपूर्ण डेटा परत को फिर से लिखना होगा, आपके बाकी आवेदन अप्रभावित रहते हैं।

दूसरे शब्दों में इसे कार की तरह समझें। आपकी कार इसे 20 साल नहीं बनाने जा रही है। लेकिन, नए टायर, नए इंजन, नए ट्रांसमिशन, नई खिड़कियां, नए इलेक्ट्रॉनिक्स, आदि के साथ। यही कार बहुत लंबे समय तक सड़क पर हो सकती है।

— coteyr
स्रोत

2

"यदि आपको अभी डेटा-बेस स्विच करना था, तो क्या आप कर सकते हैं" यह पूरा करना असंभव है यदि आप एक समय में एक पंक्ति में सीआरयूडी से अधिक कुछ भी करते हैं।

— jpmc26

1

ORM के बहुत से डेटाबेस अज्ञेयवादी हैं। मैं गौरीटी पर काम कर रही परियोजनाओं में से किसी एक को दे सकता हूं जिसे मैं बिना किसी प्रयास के SQLLite, MySql और Postgre से स्विच कर सकता हूं।

— कॉटियर

5

और जब आप एक बार में एक ही रिकॉर्ड पर साधारण CRUD से अधिक करते हैं, तो ORMs नौकरी के लिए बहुत अच्छे साधन बन जाते हैं। इसलिए मैंने इसे क्वालिफाई किया। मैंने कोशिश की। जैसे-जैसे क्वेरी जटिलता बढ़ती जाती है, यहां तक कि सर्वश्रेष्ठ ओआरएम केवल प्रश्न लिखने की तुलना में अधिक मुसीबत बन जाते हैं, और यहां तक कि अगर आप अपनी क्वेरी को उन पर मजबूर करते हैं, तो आप बहुत जल्दी डेटाबेस विशिष्ट विशेषताओं या अनुकूलन का उपयोग करके खुद को पाते हैं।

— jpmc26

1

"जटिल" को परिभाषित करें। क्या यह थोक ऑपरेशन था? क्या इसमें खिड़की के प्रश्न शामिल थे? सबक्वेरी? सीटीई? यूनियन? जटिल समूह की स्थिति? प्रत्येक पंक्ति और समुच्चय पर जटिल गणित? एक क्वेरी में कितने जुड़ते हैं? किस तरह के जोड़? एक बार में कितनी पंक्तियों को संसाधित किया गया था? कुल मिलाकर, एकल पंक्ति CRUD पर कुछ भी कहना (आप पर ध्यान दें, इसका अर्थ प्रति पंक्ति एक पंक्ति है, प्रति वेब अनुरोध या जो कुछ भी नहीं है।) हाइपरबोले का एक सा है, लेकिन जब ओआरएम अधिक परेशानी वाला हो जाता है, तो उसकी तुलना में सड़क बहुत कम होती है। आपको लगता है। और एक क्वेरी अच्छा प्रदर्शन करने के लिए कदम बहुत बार डेटाबेस विशिष्ट हैं।

— jpmc26

4

"क्या आपका ऐप डेटाबेस अज्ञेयवादी है? यदि आपको अभी डेटा-बेस को स्विच करना था, तो क्या आप कर सकते हैं? क्या आपका तर्क अज्ञेयवादी है। यदि आपको अभी पूरी तरह से नई भाषा में ऐप को फिर से लिखना पड़ा, तो क्या आप कर सकते थे?" - यह पूरी तरह से सलाह है! जो भी आप प्रोग्रामिंग भाषाओं या डेटाबेस का सबसे बड़ा सामान्य भाजक सोचते हैं, उसके लिए अपने आप को कृत्रिम रूप से बाधा न डालें - यह आपको पहिया को लगातार मजबूत करने के लिए मजबूर करेगा। इसके बजाय, अपनी प्रोग्रामिंग भाषा और पसंद के डेटाबेस में वांछित व्यवहार को व्यक्त करने के लिए प्राकृतिक तरीके को खोजने का प्रयास करें।

— fgp

12

@Amon और कुछ अन्य लोगों के उत्तर बहुत अच्छे हैं, लेकिन मैं आपको यह सुझाव देना चाहता था कि आप इसे दूसरे दृष्टिकोण से देखें।

मैंने बड़े निर्माताओं और सरकारी एजेंसियों के साथ काम किया है जो 20 साल से अधिक समय से उपयोग किए जा रहे कार्यक्रमों या कोड-बेस पर भरोसा कर रहे थे, और उन सभी में एक चीज समान थी - कंपनी ने हार्डवेयर को नियंत्रित किया। जब आप इसे चलाते हैं तो नियंत्रण के लिए 20+ वर्षों तक चलने और निकालने के लिए कुछ करना मुश्किल नहीं होता है। इन समूहों के कर्मचारियों ने आधुनिक मशीनों पर कोड विकसित किए जो कि तैनाती मशीनों की तुलना में सैकड़ों गुना तेज थे ... लेकिन समय के साथ तैनाती मशीनें जमी हुई थीं।

आपकी स्थिति जटिल है, क्योंकि एक वेबसाइट का मतलब है कि आपको दो वातावरणों की योजना बनाने की आवश्यकता है - सर्वर और ब्राउज़र।

जब सर्वर पर आता है, तो आपके पास दो सामान्य विकल्प होते हैं:

विभिन्न समर्थन कार्यों के लिए ऑपरेटिंग सिस्टम पर निर्भर है जो बहुत तेज हो सकता है, लेकिन इसका मतलब है कि ओएस को "समय में जमे हुए" होने की आवश्यकता हो सकती है। यदि ऐसा है, तो आप सर्वर के लिए OS इंस्टॉलेशन के कुछ बैकअप तैयार करना चाहेंगे। अगर 10 साल में कुछ दुर्घटनाग्रस्त हो जाता है, तो आप किसी को ओएस को फिर से स्थापित करने की कोशिश में पागल नहीं होना चाहते हैं या एक अलग वातावरण में काम करने के लिए कोड को फिर से लिखना चाहते हैं।
किसी दिए गए भाषा / ढांचे के भीतर संस्करण पुस्तकालयों का उपयोग करें, जो धीमे हैं, लेकिन एक आभासी वातावरण में पैक किया जा सकता है और संभवतः विभिन्न ऑपरेटिंग सिस्टम या आर्किटेक्चर पर चलाया जा सकता है।

जब यह ब्राउज़र की बात आती है, तो आपको सर्वर पर सब कुछ होस्ट करने की आवश्यकता होगी (यानी आप फ़ाइलों को होस्ट करने के लिए एक वैश्विक सीडीएन का उपयोग नहीं कर सकते हैं)। हम मान सकते हैं कि भविष्य के ब्राउज़र अभी भी HTML और जावास्क्रिप्ट (कम से कम संगतता के लिए) चलाएंगे, लेकिन यह वास्तव में एक अनुमान / धारणा है और आप इसे नियंत्रित नहीं कर सकते।

— जोनाथन वानास्को
स्रोत

11

आपको सुरक्षा पर भी विचार करना होगा। एक 20 वर्षीय असमर्थित ओएस संभवतः सुरक्षा छेद से भरा होगा। मैंने एक कंपनी के लिए काम किया और यह समस्या विरासत में मिली। सरकारी एजेंसी, प्राचीन OS (सभी लंबे वर्चुअलाइज्ड, सौभाग्य से), लेकिन यह एक बड़ी समस्या थी, और सॉफ्टवेयर को पूरी तरह से फिर से लिखने के कारण अपग्रेड करना असंभव था (सैकड़ों अलग-अलग स्पेगेटी-कोड PHP स्क्रिप्ट, जिनमें से प्रत्येक में डेटाबेस कॉल था नए ड्राइवर ने समर्थन / थरथराहट का उपयोग नहीं किए गए पदावनत कार्यों का उपयोग करते हुए हार्डकोड किया।

यदि आप ओएस मार्ग पर जाते हैं, तो सबसे अच्छा आप उम्मीद कर सकते हैं कि सुरक्षा पैच लागू किए गए थे, और यह कि भविष्य के रखवाले नेटवर्किंग परत पर सामान को ढालने में सक्षम होंगे। लंबे समय में इस तरह से काम करने के लिए सामान की योजना बनाने के लिए (ओपी एक बड़े बजट की अनुपस्थिति में, जैसा कि ओपी एक छात्र है) आपको मूल रूप से यह स्वीकार करने की आवश्यकता है कि आपका आवेदन और सर्वर अंततः असुरक्षित हो जाएगा। उदाहरण के लिए, 20 वर्षों में सर्वर पर एसएसएल संस्करण के लिए अंततः ज्ञात कारनामों का अस्तित्व होगा ... लेकिन ओएस 10 वर्षों में ओपनसीएल संस्करणों के साथ संगत नहीं हो सकता है। यह सब ट्रेडऑफ को कम करने के बारे में है।

— जोनाथन वानास्को

@ फाइटरजेट, आप हमेशा एक समर्थित ओएस पर एक फ़ायरवॉल चला सकते हैं, फिर आपके पास एसक्यूएल इंजेक्शन आदि के अलावा कुछ जोखिम भी हैं जिन्हें आपको वैसे भी कोडित करना चाहिए।

— इयान

@ इयान: काश। एक फ़ायरवॉल था। लेकिन मैंने कोड नहीं लिखा, मुझे यह विरासत में मिला। और हाँ, हजारों SQL भेद्यताएँ थीं जो मैं चाहता था कि मैं तय कर सकता था, लेकिन असली समस्या यह थी कि कोड PHP4 के एक विशेष संस्करण पर निर्भर था (जिसे हमेशा के लिए हटा दिया गया है और सुरक्षा छेदों से भरा है) और एक डेटाबेस ड्राइवर का विशेष संस्करण (जो नए OS पर काम नहीं करता था), जिसने हमें डेटाबेस के नए संस्करण में अपग्रेड करने से रोका ... बात यह है कि, कुछ उसी पर निर्भर रहना, जो हमेशा काम नहीं करता है। चलो बस कहते हैं कि मुझे खुशी है कि मैं अब वहां काम नहीं करता।

1

@ फाइटरजेट वास्तव में मेरे बारे में बात करने का एक बहुत अच्छा उदाहरण है। आपने विरासत कोड को समाप्त कर दिया है जो केवल PHP4 के एक विशेष संस्करण पर काम करता है और एक चालक जो केवल एक विशेष OS पर चलता है ... इसलिए आप सर्वर को अपग्रेड नहीं कर सकते हैं। मैं किसी को भी ऐसा करने की वकालत नहीं करूंगा, लेकिन ऐसा होता है। -- बहुत। एफडब्ल्यूआईडब्ल्यू, मैं आपसे सहमत हूं, लेकिन मैं उन प्रकार के परिदृश्यों के बारे में सोचने के लिए अपना जवाब देना चाहता था, न कि सिफारिश करना।

— जोनाथन वानास्को

6

अधिकांश अनुप्रयोगों का मूल डेटा है। डेटा हमेशा के लिए है। कोड अधिक व्यय योग्य , परिवर्तनशील, निंदनीय है। डेटा को संरक्षित किया जाना चाहिए, हालांकि। इसलिए वास्तव में ठोस डेटा मॉडल बनाने पर ध्यान दें। स्कीमा और डेटा को साफ रखें। प्रत्याशित, कि एक ही डेटाबेस के शीर्ष पर एक नया अनुप्रयोग बनाया जा सकता है।

एक डेटाबेस चुनें जो अखंडता बाधाओं को लागू करने में सक्षम है। समय बीतने के साथ ही अड़चन का उल्लंघन होता है। किसी ने नोटिस नहीं किया। विदेशी कुंजियों, अद्वितीय बाधाओं, चेक बाधाओं और संभवतः सत्यापन के लिए ट्रिगर जैसी सुविधाओं का अधिकतम उपयोग करें। क्रॉस-टेबल विशिष्टता बाधाओं को लागू करने के लिए अनुक्रमित विचारों का दुरुपयोग करने के लिए कुछ तरकीबें हैं।

तो शायद आपको यह स्वीकार करने की आवश्यकता है कि आवेदन कुछ समय में फिर से लिखा जाएगा। यदि डेटाबेस साफ है, तो थोड़ा माइग्रेशन का काम होगा। श्रम और उत्पन्न दोषों के संदर्भ में पलायन बेहद महंगा है।

प्रौद्योगिकी के नजरिए से यह एक अच्छा विचार हो सकता है कि सर्वर पर अधिकांश एप्लिकेशन को रखा जाए और क्लाइंट पर जावास्क्रिप्ट रूप में नहीं। आप शायद वर्चुअलाइजेशन के लिए धन्यवाद के लिए एक ही ओएस उदाहरण में एक ही एप्लिकेशन को चला सकते हैं । यह वास्तव में अच्छा नहीं है, लेकिन यह गारंटी है कि ऐप बिना किसी महंगे रखरखाव और हार्डवेयर लागत के 20 साल बाद काम करेगा। ऐसा करने से आपके पास कम से कम पुराने और कामकाजी कोड को चलाने के लिए सुरक्षित और सस्ता कमबैक है।

इसके अलावा, मुझे लगता है कि कुछ प्रौद्योगिकी स्टैक दूसरों की तुलना में अधिक स्थिर हैं । मैं कहूंगा कि .NET के पास वर्तमान में सबसे अच्छा संभव पश्चगामी संगतता कहानी है। Microsoft इसके बारे में गंभीर है। जावा और सी / सी ++ वास्तव में भी स्थिर हैं। पायथन ने यह साबित कर दिया है कि पायथन 3 के टूटने के परिवर्तनों के साथ यह बहुत अस्थिर है। जावास्क्रिप्ट वास्तव में मेरे लिए काफी स्थिर है क्योंकि वेब को तोड़ना किसी भी ब्राउज़र विक्रेता के लिए एक विकल्प नहीं है। आप शायद प्रयोगात्मक या कायरता पर भरोसा नहीं करना चाहिए। ("कायरता" को "मुझे पता है कि जब मैं इसे देखता हूं" के रूप में परिभाषित किया जा रहा है)।

— usr
स्रोत

.net बैकवर्ड कम्पैटिबिलिटी स्टोरी के बारे में - मुझे नहीं लगता कि मैंने एक जावा ऐप देखा है जो इसके विपरीत, जावा के पुराने संस्करण के लिए पूछेगा। यह जावा 9 या उससे आगे के साथ बदल सकता है, लेकिन ऐसा अभी तक नहीं हुआ है।

— eis

यह अभ्यास में आश्चर्यजनक रूप से संगत है, और एक पुराने संस्करण को एक तरफ स्थापित करना कोई समस्या नहीं है। यह भी ध्यान दें, कि .NET BCL जावा निर्मित कक्षाओं की तुलना में मेरे अनुमान से 10-100x बड़ा है।

— usr

पश्चगामी संगतता का अर्थ है कि पुराने संस्करण को भी स्थापित करने की आवश्यकता नहीं होनी चाहिए। लेकिन हम मूल प्रश्न से हटते हैं, यह वास्तव में ओपी के लिए प्रासंगिक नहीं है।

— ईस

0

अन्य उत्तर समझ में आते हैं। हालाँकि, मुझे लगता है कि ग्राहक प्रौद्योगिकी पर टिप्पणी जटिल चीजों पर है। मैं पिछले 16 वर्षों से डेवलपर के रूप में काम कर रहा हूं। मेरे अनुभव में, जब तक आप अपने क्लाइंट कोड को सहज रखते हैं, तब तक आपको ठीक होना चाहिए। तो कोई "हैक" फ्रेम / iframes, आदि के साथ .. केवल ब्राउज़रों में अच्छी तरह से परिभाषित कार्यों का उपयोग करें।

आप उन्हें काम करने के लिए हमेशा ब्राउज़र में संगतता मोड का उपयोग कर सकते हैं।

अपनी बात को साबित करने के लिए, कुछ महीनों पहले मैंने एक कस्टमर के लिए जावास्क्रिप्ट कोड में एक सहस्राब्दी बग तय किया, जो 17 साल से अपना वेब ऐप चला रहा है। अभी भी हाल की मशीनों, हाल के डेटाबेस, हाल के ऑपरेटिंग सिस्टम पर काम करता है।

निष्कर्ष: इसे सरल और साफ रखें और आपको ठीक होना चाहिए।

— जोनाथन वैन डी वेन
स्रोत

1

फ़्रेम और आइफ्रेम HTML कल्पना में बहुत अच्छी तरह से परिभाषित किए गए हैं। क्या उन्हें अनुपयुक्त बनाता है?

— उत्सुकतादिनी

3

@curiousdannii: यह iframes का उपयोग इतना अधिक नहीं है (फ़्रेम HTML5 में अब समर्थित नहीं हैं), क्योंकि फ़्रेम और iframes का उपयोग स्क्रिप्टिंग आदि के माध्यम से अतुल्यकालिक रूप से सामग्री को लोड करने के लिए किया जाता है। यह अब महान काम कर सकता है, लेकिन यह हमेशा काम करेगा सुरक्षा परिवर्तनों के अधीन रहें।

— जोनाथन वैन डे वीन

-2

कुछ स्वयंसिद्ध शब्द:

सत्य बच जाता है। इस संदर्भ में, यह एल्गोरिदम और डेटा मॉडल होगा - जो सच्चाई से आपकी समस्या के "क्या" और "कैसे" का प्रतिनिधित्व करता है। यद्यपि, शोधन और सुधार या समस्या के विकास के लिए हमेशा क्षमता है।
भाषाएं विकसित होती हैं। यह कंप्यूटर भाषाओं के लिए उतना ही सही है जितना कि प्राकृतिक भाषाओं के लिए।
सभी प्रौद्योगिकी अप्रचलन के लिए कमजोर है। यह सिर्फ कुछ प्रौद्योगिकियों के लिए दूसरों की तुलना में अधिक समय लग सकता है

सबसे अधिक स्थिर प्रौद्योगिकियां और मानक (जो कम से कम अप्रचलन के लिए कमजोर होते हैं) वे होते हैं जो गैर-मालिकाना होते हैं और सबसे व्यापक रूप से अपनाए जाते हैं। व्यापक रूप से गोद लेने, लगभग किसी भी परिवर्तन के खिलाफ जड़ता अधिक से अधिक। मालिकाना "मानक" हमेशा उनके मालिक और प्रतिस्पर्धी बलों के भाग्य और सनक के लिए कमजोर होते हैं।

कंप्यूटर उद्योग में बीस साल बहुत लंबा समय है। पांच साल अधिक यथार्थवादी लक्ष्य है। पांच साल के समय में, आपके आवेदन को हल करने के लिए पूरी समस्या को पूरी तरह से परिभाषित किया जा सकता है।

उदाहरण के लिए कुछ उदाहरण:

C और C ++ लंबे समय से आसपास हैं। हर प्लेटफॉर्म पर इनका कार्यान्वयन है। C ++ का विकास जारी है, लेकिन "यूनिवर्सल" फीचर्स (जो सभी प्लेटफॉर्म पर उपलब्ध हैं) बहुत ज्यादा गारंटीकृत हैं, जिन्हें कभी नहीं हटाया जाएगा।

फ्लैश लगभग एक सार्वभौमिक मानक बन गया, लेकिन यह मालिकाना है। लोकप्रिय मोबाइल प्लेटफार्मों पर इसका समर्थन नहीं करने के कॉर्पोरेट निर्णयों ने मूल रूप से हर जगह इसे बर्बाद कर दिया है - यदि आप वेब के लिए लेखक हैं, तो आप अपनी सामग्री सभी प्लेटफार्मों पर उपलब्ध चाहते हैं; आप नहीं चाहते कि प्रमुख बाजार मोबाइल बन जाए।

Microsoft और Intel के स्वामित्व के बावजूद WinTel (Windows / x86), कम-से-इष्टतम प्लेटफ़ॉर्म पर शुरू होने के बावजूद (16 बिट आंतरिक / 8 बिट बाहरी 8088 बनाम समकालीन Apple Macintosh 32 बिट आंतरिक / 16 बिट बाहरी 68000), और अपरदन। एप्पल के लिए उपभोक्ता बाजार में व्यापार प्लेटफार्मों के लिए एक वास्तविक विकल्प है। उस समय (25 वर्ष) में, पिछड़े अनुकूलता के प्रति प्रतिबद्धता ने दोनों के भविष्य के विकास को बढ़ावा दिया है और काफी आत्मविश्वास से प्रेरित किया है कि पुराने बॉक्स पर काम करने वाले अभी भी नए पर काम करेंगे।

अंतिम विचार

व्यापार तर्क को लागू करने के लिए जावास्क्रिप्ट सबसे अच्छा विकल्प नहीं हो सकता है। डेटा अखंडता और सुरक्षा के कारणों के लिए, व्यापार तर्क सर्वर पर किया जाना चाहिए, इसलिए क्लाइंट-साइड जावास्क्रिप्ट को यूआई व्यवहार तक सीमित किया जाना चाहिए। सर्वर पर भी, जावास्क्रिप्ट सबसे अच्छा विकल्प नहीं हो सकता है। यद्यपि छोटी परियोजनाओं के लिए अन्य ढेर (जावा या सी #) के साथ काम करना आसान है, लेकिन इसमें औपचारिकता का अभाव है जो चीजों को अधिक जटिल होने पर आपको बेहतर, अधिक संगठित समाधान लिखने में मदद कर सकता है।

— Zenilogix
स्रोत