👵🏽 🚣🏾 🤷🏻 मैंने अपने पहले बड़े पैमाने के प्रोजेक्ट पर काम करते हुए जो सीखा ↩️ 🖖 🤽🏼

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

अपने मूल रूप में बांधें

प्रसंग

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

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

रास्ते की शुरुआत

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

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

और अब मजा शुरू होता है

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

# 1 दृश्य और बैकएंड के लिए पारंपरिक संरचनाओं का उपयोग करना सुनिश्चित करें, क्योंकि इंटरप्रोसेस संचार एक बेवकूफ चीज है

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

№2 डेटा बनाए रखना अखंडता को बनाए रखना बहुत मुश्किल है।

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

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

नंबर 3 इंटरफेस - जूते की तरह जो ऑर्डर करने के लिए सिलना है

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

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

नंबर 4 कोई बहुत अधिक सहिष्णुता नहीं है

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

नंबर 5 सही नहीं है? डरावना ना होना

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

इससे पहले कि हम अलविदा कहें

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

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

बाइंडर-स्थानीय (इलेक्ट्रॉन पर ग्राहक)

बाइंडर-वेब (प्रीटीनेस वेब पेज)

शेष दो में, मैंने सुरक्षा कारणों से कोड की पंक्तियों को स्वचालित रूप से गिनना शुरू नहीं किया।

बाइंडर आपी

जावास्क्रिप्ट: 21 फाइलें, 4117 लाइनें
अन्य फाइलें: ~ 150 लाइनें

बांधने की मशीन (अखंडता की जाँच के लिए सेवा)

जावास्क्रिप्ट: 16 फाइलें, 2374 लाइनें
अन्य फाइलें: ~ 140 लाइनें

कोड की लाइनों की कुल संख्या: 30,015

मैंने अपने पहले बड़े पैमाने के प्रोजेक्ट पर काम करते हुए जो सीखा

प्रसंग

रास्ते की शुरुआत

और अब मजा शुरू होता है

इससे पहले कि हम अलविदा कहें

More articles: