स्टार्टअप विकसित करने से पहले हम 15 बातें जानना चाहेंगे

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

1. बहुभाषावाद

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

2. समय क्षेत्र

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

3. स्केलेबिलिटी के बारे में सोचें

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

4. आउटपुट सब कुछ एपीआई के लिए

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

5. हिमस्खलन प्रश्न - रेडिस में

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

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

रेडिस के अलावा, अन्य समान उत्पाद हैं, लेकिन, दुर्भाग्य से, हमने उनके साथ काम नहीं किया।

6. न्यूनतम उपयोगकर्ता सहभागिता और तकनीकी सहायता

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

7. प्रोजेक्ट फाइलों में अव्यवस्था से बचें

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

8. जावास्क्रिप्ट टेम्पलेट इंजन का उपयोग करें

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

9. अधिकतम स्वच्छ जंक डेटा

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

इसमें वह मामला भी शामिल है जब मुख्य रिकॉर्ड डेटाबेस से हटा दिया जाता है, लेकिन अन्य तालिकाओं में इससे संबंधित रिकॉर्ड हटाए नहीं जाते हैं: इस प्रकार, डेटा की अखंडता का उल्लंघन होता है। MySQL में, इस उद्देश्य के लिए ट्रिगर और विदेशी कुंजियों का उपयोग किया जा सकता है।

10. एकीकृत डिजाइन - सब कुछ में

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

11. शैलियों के लिए लेस का उपयोग करें।

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

12. तार्किक मूल्य निर्धारण

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

13. आप कैसे आंकड़े इकट्ठा करेंगे, इसके बारे में तुरंत सोचें

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

14. केवल उन विशेषताओं को संशोधित करें जो अन्य ग्राहकों के लिए उपयोगी होंगी।

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

15. उन लोगों के बारे में सोचें जो विकास में शामिल होंगे

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