वेब-ऐप के "भविष्य-प्रूफ" न होने का डर


106

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

जैसा कि मैंने एप्लिकेशन को डिज़ाइन करना जारी रखा है, प्रोजेक्ट के लिए किसी भी समय अपने आप को समझाने के लिए यह कठिन होता जा रहा है, जो कि शुरुआती चरण में हुआ है। प्रोजेक्ट से जुड़ा हुआ और मेरे द्वारा पहले ही लिखे गए कोड से, मुझे डर है कि मेरे द्वारा किए जाने वाले सभी अतिरिक्त काम निकट भविष्य में समाप्त हो जाएंगे, जब ऐप बड़े पैमाने पर नहीं बढ़ता है और साथ ही साथ व्यापार बढ़ता है।

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

मैंने जनवरी में एक पूर्ण-स्टैक डेवलपर के रूप में इंटर्नशिप उतारी है, जहां मैं फ्रंट-एंड फ्रेमवर्क सीखना शुरू करूंगा, लेकिन ऐप को खत्म करने का दबाव बढ़ रहा है, और मैं ऐप को पूरी तरह से समाप्त करने और शुरू करने पर विचार कर रहा हूं, जो कुछ मैंने पहले किया है। वर्तमान में एप्लिकेशन PHP और jQuery (AJAX कॉल के लिए) में बनाया गया है और अपने डेटाबेस के लिए MySQL का उपयोग करता है। मैं इस मानसिक अवरोध को कैसे दूर कर सकता हूं, इस बारे में कोई भी विचार और यह सुनिश्चित करने के लिए कि मेरा ऐप स्केलेबल होगा? अग्रिम में धन्यवाद।


93
एक रूपरेखा का उपयोग करना सस्ता होना है, उद्देश्यपूर्ण रूप से बेहतर नहीं है। व्यवसाय हमेशा पूछेगा "क्यों सस्ता नहीं" क्योंकि यह उनका काम है। "क्यों यह ढांचा ऐसा नहीं है, या कस्टम" का जवाब देने के लिए कई वर्षों का अनुभव होता है। आप संभवतः एक छात्र / प्रशिक्षु के रूप में उस प्रश्न का कोई सार्थक उत्तर नहीं दे सकते हैं क्योंकि आपने पर्याप्त परियोजनाओं में भाग नहीं लिया है ताकि किसी समस्या के लिए एक दिया गया ढांचा कैसे काम करे। इस तरह के अनुभव के बिना, केवल एक चीज जो आप कर सकते हैं वह है किसी दिए गए ढांचे के विपणन के लिए शिकार करना।
Agent_L

24
भविष्य के बारे में केवल एक चीज आपको पता है कि आप इसके बारे में कुछ नहीं जानते हैं। तो बस वर्तमान में जीने के साथ आगे बढ़ें। भविष्य में आपको किक करने के तरीके मिल जायेंगे। हालांकि आप इससे बचने की कोशिश में कितना समय बर्बाद करते हैं!
एलेफोज़रो

20
"संलग्न होने के बाद ... कोड मैंने पहले ही लिखा है" यह हमारा स्वभाव है कि हम अपने काम से जुड़े और इसे बदलने के लिए प्रतिरोधी बनें। लेकिन अगर आप करते हैं, तो भी यह संस्करण नियंत्रण में रहता है। सॉफ़्टवेयर को बदलने का मतलब है, जैसा वास्तविक दुनिया करती है। कोड को हटाने या उस पर निर्माण करते समय इसे बदलने के लिए डरो मत।
बिट्सफ्लॉजिक एनसी

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

6
@james_pic आप एक मूल ढांचे के बिना वेब प्रोजेक्ट करते हैं (जैसे .NET में asp.net core और इसी तरह)? तो आप एक सरल http लाइब्रेरी के शीर्ष पर रूटिंग लॉजिक और अन्य सभी सामग्री को फिर से लागू करते हैं? यह अत्यधिक लगता है और मैं यह देखने में विफल रहता हूं कि आपको क्या लाभ देना चाहिए।
वू

जवाबों:


201

परफेक्ट अच्छे का दुश्मन है।

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


23
अच्छी बात। यदि आप 2 महीने व्यतीत करते हैं, तो इसे 1 सप्ताह के पुन: लिखने के लिए भविष्य-निर्माण करने की कोशिश कर रहे हैं, तो आप अपना समय 7 सप्ताह खो चुके हैं। स्वीकार करें कि परिवर्तन होंगे, और भविष्य में इसका प्रमाण केवल तभी होगा जब यह लगभग निश्चित हो कि इसे करने की आवश्यकता होगी।
नील

83
YAGNI, बेबी, YAGNI
केविन

32
"समय से पहले अनुकूलन " सभी बुराई की जड़ है । शायद यह ध्यान देने योग्य है कि आप 6 उपयोगकर्ताओं से एक मिलियन तक नहीं कूदेंगे। यदि 6 क्लाइंट एक डेवलपर के लिए भुगतान करने के लिए पर्याप्त हैं, तो जब तक आप 100 क्लाइंट तक नहीं पहुंचते, तब तक कोड को एक अलग संरचना की आवश्यकता हो सकती है ताकि एक ही समय में कई देवों को उस पर काम करने की अनुमति मिल सके। यह प्रदर्शन के अनुकूलन से काफी अलग है और एक मिलियन उपयोगकर्ताओं को घेरने की तुलना में बहुत पहले होता है।
आर। श्मिट्ज़

22
@ R.Schmitz यह उद्धरण इन दिनों पूरी तरह से अलग संदर्भ में इस्तेमाल किया जाता है, जिस तरह से नथ ने इसे कंप्यूटर प्रोग्रामिंग में एक कला के रूप में इस्तेमाल किया। नुथ पूरी तरह से "बस प्रोग्रामिंग शुरू करने और बाद में अनुकूलन के बारे में चिंता करने" के खिलाफ है। वह जो कह रहा है वह यह है कि लोग गलत समय पर कोड के गलत हिस्सों का अनुकूलन करते हैं। किसी भी तरह से इसका मतलब यह नहीं है कि कोड लिखने से पहले आपको यह सुनिश्चित करने के लिए अपनी वास्तुकला के बारे में सोचने में कुछ समय खर्च नहीं करना चाहिए। आप दूसरी भावना को पसंद कर सकते हैं, लेकिन आपको वहाँ रक्षक के रूप में नुथ का हवाला नहीं देना चाहिए।
वू

20
@ R.Schmitz वापस जब होरे / नथ ने उस बयान को "अनुकूलन" का मतलब बनाया था, तो चक्र गणना और अन्य चीजें जो हम आज किसी भी तरह से नहीं करते हैं, "कोडिंग शुरू करने से पहले एक अच्छी वास्तुकला के बारे में नहीं सोचते"। उद्धरण के रूप में अच्छी प्रणाली के डिजाइन के बारे में नहीं सोचने के लिए एक बहाने के रूप में उपयोग करना बस वह नहीं है जो उनके दिमाग में था।
वू

110

मैं इस मानसिक अवरोध को कैसे दूर कर सकता हूं, इस बारे में कोई भी विचार और यह सुनिश्चित करने के लिए कि मेरा ऐप स्केलेबल होगा?

इस समस्या का मूल कारण स्केलेबिलिटी नहीं है। मुद्दे का क्रूस सोच रहा है कि आप इसे पहली बार ठीक कर लेंगे

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

अब आप जो करने की कोशिश कर रहे हैं वह लिखने के लिए सही कोड के बारे में सोचने की कोशिश कर रहा है। लेकिन यहां तक ​​कि अगर आप ऐसा करने का प्रबंधन करते हैं, तो कौन कहता है कि आवश्यकताओं को बदलने की जरूरत नहीं है, या आपने गलत जानकारी या गलत सूचना के आधार पर अपने फैसले किए हैं?

आप गलतियाँ करने से बच नहीं सकते, भले ही वे आपकी गलती न हों। कोड लिखने पर ध्यान दें जिसमें बाद में चीजों को बदलना आसान हो, बजाय कोड लिखने की उम्मीद के जिसे आपको भविष्य में बदलने की आवश्यकता नहीं होगी।

परियोजना से जुड़ा हुआ है और मैंने पहले ही लिखा कोड,

इस भावना से मुझे पूरी सहानुभूति है। लेकिन आपके द्वारा लिखे गए कोड से जुड़ना एक समस्या है।

केवल एक चीज जो एक स्थिर होनी चाहिए वह एक विशिष्ट समस्या को हल करने की आपकी इच्छा है । आप उस समस्या को हल करने के बारे में कैसे जाते हैं यह केवल एक माध्यमिक चिंता है।

यदि कल एक नया टूल जारी किया जाता है जो आपके कोडबेस को 80% कम कर देता है, तो क्या आप परेशान होने वाले हैं कि आपका कोड अब उपयोग नहीं किया जाता है; या क्या आप खुश होने जा रहे हैं कि आपका कोडबेस छोटा और ज्यादा साफ-सुथरा / अधिक प्रबंधनीय हो गया है?

यदि पूर्व में, आपको कोई समस्या है: तो आप कोड के लिए समाधान नहीं देख रहे हैं । दूसरे शब्दों में, आप कोड पर ध्यान केंद्रित कर रहे हैं और बड़ी तस्वीर को नहीं देख रहे हैं (समाधान जो इसे प्रदान करना है)।

मुझे डर है कि मेरे द्वारा किए जाने वाले सभी अतिरिक्त काम निकट भविष्य में समाप्त हो जाएंगे, जब ऐप कारोबार के बढ़ने के साथ-साथ बड़े पैमाने पर नहीं होगा।

यह एक अलग दिन के लिए एक अलग समस्या है।

सबसे पहले, आप कुछ काम करते हैं। दूसरे , आप किसी भी तरह की खामियों को ठीक करने के लिए कोड को सुधार सकते हैं जो अभी भी दिखाई दे सकते हैं। वर्तमान में आप जो कर रहे हैं वह पहले कार्य पर वापस पकड़ रहा है फिर दूसरे कार्य को करने के डर से।

लेकिन अन्य विकल्प क्या है? आप भविष्य नहीं बता सकते । यदि आप अपना समय भविष्य की संभावनाओं को टटोलने में बिताते हैं, तो आप वैसे भी अनुमान लगाने वाले हैं । एक अनुमान हमेशा गलत गलत होने का खतरा है।

इसके बजाय, एप्लिकेशन बनाएं और साबित करें कि वास्तव में एक मुद्दा है। और एक बार जब समस्या स्पष्ट हो जाती है, तो आप इसे संबोधित करना शुरू करते हैं।

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

मैंने नियोक्ताओं से साक्षात्कार के दौरान किसी भी वेब फ्रेमवर्क का उपयोग न करने के लिए मेरी पसंद पर सवाल उठाया है, जिससे मुझे केवल अपने पिछले काम पर संदेह करना पड़ा है।

यहां महत्वपूर्ण हिस्सा यह नहीं है कि आप किस फ्रेमवर्क का उपयोग कर रहे हैं (कोई भी नियोक्ता जो उस पर आपका न्याय करता है वह अपना काम ठीक से नहीं कर रहा है)। यहाँ महत्वपूर्ण भाग यह जान रहा है कि आप क्या कर रहे हैं और क्यों कर रहे हैं

उदाहरण के लिए, आप विशेष रूप से मौजूदा ढाँचे से बच सकते हैं क्योंकि आप सीखना चाहते हैं कि एक ढाँचा पहले कठिन तरीके से उपयोगी क्यों है। या आप अपनी रूपरेखा बनाने की कोशिश कर रहे होंगे।

यहाँ केवल बुरा जवाब "मुझे नहीं पता" है, क्योंकि यह सूचित निर्णय लेने की कमी को दर्शाता है। यही कारण है कि है एक नियोक्ता के लिए एक लाल झंडा।

मैं बस किसी भी वेब फ्रेमवर्क को नहीं जानता, और यह नहीं जानता कि कौन सा उपयोग करना शुरू करना है।

यहां भी यही समस्या पैदा होती है। समाधान अधिक सोचने के लिए नहीं है, बल्कि कार्य करने के लिए है:

  • एकदम सही जवाब देना बंद करें
  • एक रूपरेखा चुनें। जब तक आपके पास प्राथमिकता नहीं होती है, तब तक एक यादृच्छिक चुनें। एक डार्टबोर्ड का उपयोग करें, एक डाई रोल करें, एक सिक्का फ्लिप करें, एक कार्ड चुनें।
  • इसका इस्तेमाल करें।
  • क्या आपको इसका उपयोग करना पसंद था? क्या आपको गुस्सा आता था?
  • इन खराब तत्वों को रोकने के तरीके देखें। क्या आपने फ्रेमवर्क का दुरुपयोग किया है, या यह केवल यह है कि फ्रेमवर्क को कैसे माना जाता है?
  • एक बार जब आपको लगता है कि आपके पास रूपरेखा पर पकड़ है (चाहे आप इसे पसंद करें या नहीं), एक नया ढांचा चुनें और चक्र को दोहराएं।

इस पर अधिक पढ़ने के लिए, कर रही मानसिकता> सोच मानसिकता पढ़ें । लेखक ने इसे मुझसे बेहतर समझा।

लेकिन ऐप को खत्म करने का दबाव बढ़ रहा है, और मैं ऐप को पूरी तरह से खत्म करने और शुरू करने पर विचार कर रहा हूं

जब तक वर्तमान कोडबेस एक पूरी तरह से अप्राप्य गड़बड़ है; आप विपरीत निर्णय ले रहे हैं।
डेवलपर्स अक्सर सोचते हैं कि चीजों को फेंकना बेहतर विकल्प होगा। यह बहुत ही सामान्य एहसास है। लेकिन यह शायद ही कभी सही विकल्प है।

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


9
खरोंच से शुरू करना शायद ही कभी सही विकल्प होता है: joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i
मार्टिन बोनर

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

4
@ मैं जो कुछ भी यहां लिखा गया है, उसमें से अधिकांश के साथ सहमत हूं, एक बात को छोड़कर: यदि आप एक रूपरेखा का चयन करते हैं और आप उनमें से किसी के बारे में कुछ नहीं जानते हैं, तो आप कम से कम उस ढांचे के गोद लेने के स्तर की जांच कर सकते हैं। उदाहरण के लिए, गितुब पर कितने तारे हैं? कितने मुद्दे हैं? कितने योगदानकर्ता हैं? अंतिम अद्यतन कब किया गया था? इन सवालों के जवाब देने से कम से कम एक फ्रेमवर्क चुनने में मदद मिल सकती है जिसके लिए आप सहायता प्राप्त कर सकते हैं, उन लोगों को किराए पर लें जो इसे बेहतर जानते हैं, आदि
Jalayn

@ यालयन एक मानेंगे कि एक शुरुआती व्यक्ति जिसके पास कोई foreknowledge नहीं है, के साथ शुरू करने के लिए अच्छी तरह से ज्ञात रूपरेखाओं पर ठोकर की संभावना है।
फ्लेटर

3
यह एक महान जवाब है क्योंकि यह एक अनुशासित और पद्धतिगत दृष्टिकोण को प्रोत्साहित करता है। इस तरह की सलाह को पूरी तरह से सराहने से पहले मुझे कई साल लग गए!
काशीराज

18

भारी मात्रा में धन के बावजूद फेसबुक और Google ने आपको समझाने के लिए विपणन में डाल दिया है अन्यथा, दो प्राथमिक कारणों से फ्रंट एंड फ्रेमवर्क मौजूद हैं:

  • सबसे पहले, हार्डवेयर / नेटवर्क को ऑफ-लोडिंग क्लाइंट और राज्य में लॉजिक के माध्यम से क्लाइंट-साइड ऑपरेशन की मांग करता है
  • दूसरा, पहले बिंदु का समर्थन करने के लिए आवश्यक अतिरिक्त ग्राहक तर्क के अनुसार, वे अलग-थलग निष्पादन संदर्भ प्रदान करते हैं ताकि आप किसी पृष्ठ को अन्य लोगों के कोड को बिना तोड़-फोड़ के रटना कर सकें।

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

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

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

वेनिला जेएस, और कुछ हद तक लेकिन अभी भी महत्वपूर्ण सीमा तक JQuery, उन समस्याओं से ग्रस्त नहीं है। कुछ उल्लेखनीय अपवादों के साथ, JQuery + AJAX अनुप्रयोग ब्राउज़र विशिष्ट व्यवहारों पर भरोसा नहीं करते हैं, और बाहरी निर्भरताएँ जहाँ समझदार हैं, 10-15 साल बाद काम करना जारी रखते हैं, क्योंकि वे मूल रूप से बहुत मामूली बदलावों के साथ लिखे गए थे।

फ़्रेमवर्क चल रहे, जटिल, सार्वजनिक रूप से वेब एप्लिकेशन का सामना करने वाले विशिष्ट स्टार्टअप के लिए बढ़िया हैं। वे बड़ी टीमों को एक साथ अच्छी तरह से समन्वयित करने देते हैं, विक्रेता के साथ अच्छी तरह से एकीकृत करते हैं फ्रेमवर्क जोड़ते हैं, और आपको प्रतिस्पर्धी रहने में मदद करने के लिए आकर्षक नए विगेट्स और डिज़ाइन प्रतिमानों का समर्थन करते हैं।

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

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


2
जब मुझे लगता है कि "रूपरेखा" मुझे लगता है कि jQuery या Angular या React जैसी चीजें हैं जहां यह उन चीजों के लिए बहुत सारे बिल्डिंग ब्लॉक प्रदान करता है जो अपने आप को लागू करने के लिए कष्टप्रद होंगे (और अक्सर सही ढंग से और क्रॉस-ब्राउज़र-संगत को लागू करने के लिए मुश्किल )।
शराबी

@fluffy क्या, विशेष रूप से, क्या आपको लगता है कि आपके लिए Angular या React करते हैं जो कि गैर-मोबाइल ब्राउज़र पर 2018 में वैनिला JS या JQuery में एक ही काम करने से काफी आसान है? FF / Chrome / Edge में इन दिनों w / o शिम पर पूरी तरह कार्यात्मक, छोटे ऐप्स बनाने के लिए पर्याप्त सामान्य सतह क्षेत्र से अधिक है।
आयरन ग्रेमलिन

3
@IronGremlin क्या आप मजाक कर रहे हैं? क्या आपने कभी दो-तरफ़ा डेटा बाइंडिंग या कोणीय / Vue / जो भी टेम्पलेट का उपयोग किया है? उन अनुप्रयोगों के लिए जहां ये सुविधाएँ उपयोगी हैं, वे एक बड़ा सरलीकरण हैं, और आपको भंगुर घटना-आधारित कोड से छुटकारा दिलाते हैं। अगला, सीपीयू। निश्चित रूप से, जेएस फ्रेमवर्क का उपयोग आमतौर पर सर्वर से कुछ भार लेता है, लेकिन यह विशुद्ध रूप से एक उप-उत्पाद है , और आप कहते हैं कि यह उनके लिए मुख्य कारण है। अगला, "सरल वास्तुकला (...) इस परियोजना के लिए एक बेहतर फिट लगता है"। ठीक है, यह एक बहुत दूर की बात है, यह देखते हुए कि हम परियोजना के बारे में कितना कम जानते हैं।
फ्राक्स

2
मेरा मतलब है, आप कहते हैं कि आपका मुख्य बिंदु "सब कुछ होना चाहिए या एक 'समृद्ध जेएस अनुप्रयोग' होना चाहिए"। मैं इस बात से सहमत हूं। हालाँकि, मुझे लगता है कि आपका उत्तर इसे ठीक से बताने में विफल है - यदि आप इसे संपादित करते हैं तो यह बहुत बेहतर होगा।
फ्राक्स

1
मैंने जेएस का उपयोग करने के कारण के रूप में सीपीयू को ग्राहक को उतारने के बारे में कभी नहीं सुना है - मैं कहूंगा कि जेएस के उपयोग की ऐतिहासिक प्रवृत्ति ग्राहक का सुझाव है कि (मैं नहीं कह रहा हूं (एक, ओवरराइडिंग) कारण), और बढ़ने लगा ब्राउज़र असंगतताओं के गॉर्डियन गाँठ के माध्यम से कटा हुआ jQuery के बाद से घातीय रूप से कभी भी।
राडारोब

7

आपके ऐप को "भविष्य के सबूत" के लिए सबसे अच्छी बात यह है कि ढीले युग्मन और चिंताओं को अलग करने के लिए आपके सिस्टम के डिजाइन में सर्वोत्तम प्रथाओं का पालन करना है। वहाँ कि अप्रचलित बनने से सुरक्षित है अपने अनुप्रयोग का कोई हिस्सा नहीं है, लेकिन बहुत आप कोड है कि कोड से कारण एक्स कि नहीं करता है के लिए अप्रचलित हो जाता है अलग करने के लिए क्या कर सकते हैं जरूरी एक्स से प्रभावित करने के लिए किया है किया

हालाँकि, मैं चाहूंगा कि आपकी चिंता आपके अनुभव और क्षमताओं की वृद्धि दर की तुलना में आपके ऐप की वृद्धि / मापनीयता के लिए कम होनी चाहिए। आप जिस मानसिक अवरोध का वर्णन करते हैं, वह मुझे लगता है जैसे या तो रणनीति के बिना कई ज्ञात अज्ञातताओं के ठहराव या जागरूकता सीखना या उनसे निपटने के लिए उपकरण।

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

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

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

  • यदि कल आप अपने सभी स्थिर संसाधनों (लिपियों, चित्रों, आदि) को एक अलग सर्वर, सामग्री वितरण नेटवर्क, आदि में स्थानांतरित कर देते हैं, या प्रदर्शन को बेहतर बनाने के लिए उन सभी को एक साथ पैकेज करने की कोशिश करने लगे तो क्या होगा?
  • यदि आप इस विजेट को अलग-अलग पृष्ठों पर, या एक ही पृष्ठ पर इसके कई उदाहरण देना शुरू करते हैं, तो क्या होगा?
  • आप विजेट के विभिन्न संस्करणों पर AB परीक्षण कैसे शुरू कर सकते हैं?

यदि इस में से कोई भी भारी लगता है, तो मेरा सुझाव है कि आपको अभी के लिए एक रूपरेखा का उपयोग करना चाहिए , आपके ऐप के लिए नहीं बल्कि आपके स्वयं के व्यक्तिगत विकास के लिए। जरूरी नहीं कि हालांकि शुरू हो। इसके बजाय अपने ऐप के विकास को निर्देशित करने में मदद करने के लिए पाठ्यक्रम के रूप में चौखटे का उपयोग करें।

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

विकास प्रक्रिया के हर चरण के दौरान पहले से मौजूद ज्ञान (रणनीतियों, सर्वोत्तम प्रथाओं, और कोड / लाइब्रेरी / चौखटे) को नियमित रूप से प्राप्त करके चाल को कम से कम करना है ताकि आप अपने आप को लगातार पहिया का फिर से आविष्कार न करें।

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

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


5

और सब से ऊपर, "बात खत्म करने और पुन: आरंभ" है कभी नहीं एक विकल्प ... सब के बाद, आप यह नहीं कहा कि आपके पास "एक आधा दर्जन ग्राहकों?" यदि आपने अभी तक विचार करने के लिए क्या रुके हुए हैं वे अपने घोषणाओं के बारे में सोच सकता है, यह देखते हुए कि वे अभी (शायद) कर रहे हैं "पूरी तरह से अपने काम से खुश ?!"

यहाँ एक सादृश्य है जो मुझे उपयोग करना पसंद है:

  • "मेरा काम लोगों के रहने के लिए घर बनाना है, लोगों के लिए व्यवसाय बनाना है, और इसी तरह।" मेरा काम उपयोगी काम करने के लिए "उन असंभव-छोटे, रेत के अति-महिमा वाले बिट्स" बनाना है। (जैसा कि जिप्सम वॉलबोर्ड, सिरेमिक टाइल, कंक्रीट ब्लॉक और 2x4 के घर-बिल्डरों के शिल्प घर हैं)

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

  • "फिर भी, प्रत्येक घर, एक बार बनाया गया, हमेशा के लिए रहने के बाद ।" आप उन्हें बेदखल नहीं कर सकते। एक बार जब आप इसे बना लेते हैं और चाबी सौंप देते हैं, "यह अब आपका घर नहीं है।" यह वही है जो अभी है, और यह बहुत लंबे समय तक खड़ा रहेगा।

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


3

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

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


3

मैंने सीखने की रूपरेखा के बारे में एक टिप्पणी लिखना शुरू कर दिया, लेकिन आखिरकार यह एक उत्तर की तरह लग रही चीज़ में बदल गया, इसलिए यहां यह है।

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

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

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


2

इस लेख को 2.5 साल पहले हैकर न्यूज़ पर बहुत अधिक ध्यान मिला: कोड लिखें जिसे हटाना आसान है, विस्तार करना आसान नहीं है। यह परिप्रेक्ष्य आपके वर्तमान कोडबेस से निपटने में आपकी मदद कर सकता है या नहीं कर सकता है, लेकिन भविष्य में, यह पूर्णतावाद / अति-इंजीनियरिंग से आने वाली निराशा को रोकने में मदद कर सकता है।

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

मुझे आपको यह बताने की आवश्यकता नहीं है कि कोड हटाने से इसे लिखने में अधिक मज़ा आता है।

(जोर मेरा)

पर हैकर समाचार लेख के धागे भी पढ़ने लायक हो सकता है।


-1

जहां तक ​​इसे भविष्य के प्रमाण बनाने और स्केल और फ्रेमवर्क सिद्धांतों को लागू करने का है, तो यह अपने आप पर एक लंबा काम है, मैं शायद इसके बारे में चिंता नहीं करूंगा, लेकिन अगर आपको यह करना चाहिए:

अपना कोड साफ रखें, SOLID, DRY सिद्धांतों> google का पालन करें।

जितनी जल्दी हो सके एक लोड-बैलेंसर लागू करें।

कम से कम दो वेब सर्वर खड़े करें, कोड में लोड संतुलन परिदृश्यों को संभालें।

और आखिरी लेकिन कम से कम नहीं, LAMP की तुलना में एक मिलियन उपयोगकर्ताओं को संभालने के लिए बेहतर ढेर हैं, लेकिन मुझे यकीन है कि यह पूरी तरह से संभव है।

मामला और बिंदु, देखें: https://stackoverflow.com/questions/1276/how-big-can-a-mysql-database-get-before-performance-starts-to-degrad बिंदु मान्य है, लेकिन 10 जीबी तुच्छ है परीक्षण विषय के रूप में।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.