👩🏿‍⚖️ 🔡 🤟🏿 फ्रीलांसरों की एक टीम फुल-स्टैक जावास्क्रिप्ट अनुप्रयोगों को कैसे लिखती है, इसके बारे में एक कहानी 🆒 👶 🥙

सामग्री के लेखक, जिसका अनुवाद हम आज प्रकाशित करते हैं, का कहना है कि गीथहॉब रिपॉजिटरी , जिस पर उन्होंने काम किया और कई अन्य फ्रीलांसरों ने, विभिन्न कारणों से, 3 दिनों में लगभग 8,200 सितारे प्राप्त किए। यह रिपॉजिटरी HackerNews और GitHub ट्रेंडिंग पर पहले स्थान पर आया, और 20,000 Reddit उपयोगकर्ताओं ने इसके लिए मतदान किया।

यह भंडार पूर्ण-स्टैक अनुप्रयोगों को विकसित करने की कार्यप्रणाली को दर्शाता है, जिसे यह लेख समर्पित है।

प्रागितिहास

मैं काफी समय से इस सामग्री को लिखने जा रहा था। मेरा मानना है कि मुझे इससे बेहतर पल नहीं मिल सकता है, जब हमारा भंडार बहुत लोकप्रिय हो।

GitHub ट्रेंडिंग पर नंबर 1

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

अब मैं उन मूल सिद्धांतों के बारे में बात करूंगा जिनका उपयोग हम परियोजनाओं को विकसित करते समय करते हैं।

सरल, बेहतर।

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

इस सिद्धांत के संबंध में मेरे द्वारा की गई त्रुटियां इस प्रकार हैं:

DRY सिद्धांत को पूरा करने की अनुचित इच्छा। कभी-कभी कोड कॉपी करना और चिपकाना काफी सामान्य है। हर 2 कोड अंशों को सार करने की आवश्यकता नहीं है जो कुछ हद तक एक दूसरे के समान हैं। मैंने खुद यह गलती की है। सब, शायद, यह प्रतिबद्ध है। DRY एक अच्छा प्रोग्रामिंग दृष्टिकोण है, लेकिन एक असफल अमूर्त चुनना केवल स्थिति को खराब कर सकता है और कोड आधार को जटिल कर सकता है। यदि आप इन विचारों के बारे में अधिक जानना चाहते हैं, तो मैं केंट ए डोड्स एएचए प्रोग्रामिंग को पढ़ने की सलाह देता हूं।
उपलब्ध साधनों का उपयोग करने से इनकार करना। इस त्रुटि का एक उदाहरण map या filter बजाय reduce करने का उपयोग है। बेशक, reduce से map के व्यवहार को पुन: पेश किया जा सकता है। लेकिन इससे कोड के आकार में वृद्धि होने की संभावना है, और इस तथ्य से कि अन्य लोगों के लिए इस कोड को समझना अधिक कठिन होगा, यह देखते हुए कि "कोड की सादगी" एक व्यक्तिपरक अवधारणा है। कभी-कभी इसे reduce लिए उपयोग करना आवश्यक हो सकता है। और यदि आप एक श्रृंखला में संयुक्त map और filter कॉल का उपयोग करके सेट किए गए डेटा की प्रसंस्करण गति की तुलना करते हैं, और reduce उपयोग करते reduce , तो यह पता चलता है कि दूसरा विकल्प तेजी से काम करता है। reduce के विकल्प में reduce आपको एक बार मूल्यों के सेट को देखना होगा, दो को नहीं। हमसे पहले उत्पादकता और सादगी के बारे में एक बहस है। ज्यादातर मामलों में, मैं सादगी पसंद करूंगा और समय से पहले कोड अनुकूलन से बचने की कोशिश करूंगा, यानी मैं reduce बजाय एक map / filter जोड़ी चुनूंगा। और अगर यह पता चला कि map और filter का निर्माण सिस्टम की अड़चन बन गया, तो यह कोड को reduce के लिए अनुवाद reduce ।

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

समान संस्थाओं को एक दूसरे के करीब रखें

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

Itory रिपोजिटरी

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

Application आवेदन के ग्राहक भाग की परियोजना संरचना

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

एक्ट और रिड्यूसर उन परियोजनाओं में मौजूद हैं जो Redux का उपयोग करते हैं। मैं इस पुस्तकालय के बिना करने का प्रयास करता हूं। मुझे यकीन है कि उच्च गुणवत्ता वाले प्रोजेक्ट हैं जो समान संरचना का उपयोग करते हैं। मेरी कुछ परियोजनाओं में घटकों और कंटेनरों के लिए अलग-अलग फ़ोल्डर हैं। एक घटक फ़ोल्डर कुछ BlogPost जैसे कि BlogPost और Profile जैसी संस्थाओं के लिए फ़ाइलों को संग्रहीत कर सकता है। कंटेनर फ़ोल्डर में कंटेनर कोड BlogPostContainer और BlogPostContainer स्टोर करने वाली फाइलें होती हैं। कंटेनर सर्वर से डेटा प्राप्त करता है और इसे "बेवकूफ" चाइल्ड घटक को भेजता है, जिसका कार्य स्क्रीन पर इस डेटा को प्रदर्शित करना है।

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

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

आमतौर पर हम routes / screens फ़ोल्डर और components फ़ोल्डर का उपयोग करते routes । घटक फ़ोल्डर आमतौर पर Button या Input जैसी वस्तुओं के लिए कोड संग्रहीत करता है। इस कोड का उपयोग एप्लिकेशन के किसी भी पेज पर किया जा सकता है। मार्गों के लिए फ़ोल्डर में प्रत्येक फ़ोल्डर एक अलग एप्लिकेशन पेज है। उसी समय, घटक कोड और इस मार्ग से संबंधित एप्लिकेशन लॉजिक कोड वाली फाइलें एक ही फ़ोल्डर में स्थित होती हैं। और कई पृष्ठों पर उपयोग किए जाने वाले घटकों का कोड components फ़ोल्डर में आता है।

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

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

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

वास्तव में, कोड को फ़ाइलों में विघटित करने का प्रश्न सर्वोपरि नहीं है। असली सवाल यह है कि आपको घटकों को स्मार्ट और बेवकूफ बनाने की आवश्यकता क्यों है। इस अलगाव के क्या लाभ हैं? इस सवाल के कई जवाब हैं:

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

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

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

एक इकाई में "स्मार्ट" और "मूर्खतापूर्ण" घटकों की क्षमताओं के संयोजन का मजबूत बिंदु यह है कि यह विकास को गति देता है और यह कोड की संरचना को सरल करता है।

इसके अलावा, अगर ऐसी कोई आवश्यकता होती है, तो एक घटक को हमेशा दो अलग-अलग घटकों में विभाजित किया जा सकता है - "स्मार्ट" और "बेवकूफ"।

stylization

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

अनुप्रयोग के सर्वर भाग की .Project संरचना

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

 src │ app.js #     └───api #   Express      └───config #      └───jobs #    agenda.js └───loaders #     └───models #    └───services # - └───subscribers #      └───types #    (d.ts)  Typescript

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

कई बार प्रकार की परिभाषाओं को अधिलेखित न करें

हम अपनी परियोजनाओं में कई समाधानों का उपयोग करते हैं जो किसी प्रकार डेटा प्रकार से संबंधित हैं। ये TypeScript, GraphQL, डेटाबेस स्कीमा और कभी-कभी MobX हैं। परिणामस्वरूप, यह पता चल सकता है कि समान संस्थाओं के लिए प्रकार 3-4 बार वर्णित किए गए हैं। इस तरह की चीजों से बचना चाहिए। हमें ऐसे उपकरणों का उपयोग करने का प्रयास करना चाहिए जो स्वचालित रूप से टाइप विवरण उत्पन्न करते हैं।

सर्वर पर, इस उद्देश्य के लिए TypeORM / Typegoose और TypeGraphQL का संयोजन इस्तेमाल किया जा सकता है। यह उपयोग किए गए सभी प्रकारों का वर्णन करने के लिए पर्याप्त है। टाइप / टाइपोगो आपको डेटाबेस स्कीमा और संबंधित टाइपस्क्रिप्ट प्रकार का वर्णन करने की अनुमति देता है। TypeGraphQL GraphQL और TypeScript के प्रकार बनाने में मदद करेगा।

यहाँ एक फ़ाइल में TypeORM (MongoDB) और TypeGraphQL के प्रकार को निर्धारित करने का एक उदाहरण दिया गया है:

 import { Field, ObjectType, ID } from 'type-graphql' import { Entity, ObjectIdColumn, ObjectID, Column, CreateDateColumn, UpdateDateColumn, } from 'typeorm' @ObjectType() @Entity() export default class Policy { @Field(type => ID) @ObjectIdColumn() _id: ObjectID @Field() @CreateDateColumn({ type: 'timestamp' }) createdAt: Date @Field({ nullable: true }) @UpdateDateColumn({ type: 'timestamp', nullable: true }) updatedAt?: Date @Field() @Column() name: string @Field() @Column() version: number }

GraphQL कोड जनरेटर भी कई अलग अलग प्रकार उत्पन्न कर सकते हैं। हम क्लाइंट पर टाइपस्क्रिप्ट प्रकार बनाने के लिए इस टूल का उपयोग करते हैं, साथ ही सर्वर को एक्सेस करने वाले रिएक्ट हुक भी करते हैं।

यदि आप एप्लिकेशन की स्थिति को नियंत्रित करने के लिए MobX का उपयोग करते हैं, तो कोड की कुछ पंक्तियों का उपयोग करके, आप स्वचालित रूप से उत्पन्न TS प्रकार प्राप्त कर सकते हैं। यदि आप भी ग्राफकॉल का उपयोग करते हैं, तो आपको नए पैकेज - एमएसटी- जीक्यूएल पर एक नजर डालनी चाहिए, जो जीक्यूएल योजना से राज्य का पेड़ तैयार करता है।

इन उपकरणों का एक साथ उपयोग करना आपको बड़ी मात्रा में कोड को फिर से लिखने से बचाएगा और आपको सामान्य गलतियों से बचने में मदद करेगा।

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

जब भी संभव हो, स्वचालित कोड पीढ़ी के साधनों का सहारा लें

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

स्निपेट्स के साथ कई पैकेज हैं, लेकिन अपने स्वयं के स्निपेट बनाना आसान है। उदाहरण के लिए, स्निपेट जनरेटर का उपयोग करना।

यहाँ वह कोड है जो मुझे अपने पसंदीदा स्निपेट में से कुछ को VS कोड में जोड़ने की अनुमति देता है:

 { "Export default": {   "scope": "javascript,typescript,javascriptreact,typescriptreact",   "prefix": "eid",   "body": [     "export { default } from './${TM_DIRECTORY/.*[\\/](.*)$$/$1/}'",     "$2"   ],   "description": "Import and export default in a single line" }, "Filename": {   "prefix": "fn",   "body": ["${TM_FILENAME_BASE}"],   "description": "Print filename" }, "Import emotion styled": {   "prefix": "imes",   "body": ["import styled from '@emotion/styled'"],   "description": "Import Emotion js as styled" }, "Import emotion css only": {   "prefix": "imec",   "body": ["import { css } from '@emotion/styled'"],   "description": "Import Emotion css only" }, "Import emotion styled and css only": {   "prefix": "imesc",   "body": ["import styled, { css } from ''@emotion/styled'"],   "description": "Import Emotion js and css" }, "Styled component": {   "prefix": "sc",   "body": ["const ${1} = styled.${2}`", "  ${3}", "`"],   "description": "Import Emotion js and css" }, "TypeScript React Function Component": {   "prefix": "rfc",   "body": [     "import React from 'react'",     "",     "interface ${1:ComponentName}Props {",     "}",     "",     "const ${1:ComponentName}: React.FC<${1:ComponentName}Props> = props => {",     " return (",     " <div>",     " ${1:ComponentName}",     " </div>",     " )",     "}",     "",     "export default ${1:ComponentName}",     ""   ],   "description": "TypeScript React Function Component" } }

स्निपेट्स के अलावा, कोड जनरेटर समय बचाने में मदद कर सकते हैं। आप उन्हें खुद बना सकते हैं। मुझे इसके लिए प्लॉप का इस्तेमाल करना पसंद है।

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

कोड जनरेटर की एक और ताकत यह है कि वे टीम के विकास में एकरूपता में योगदान करते हैं। यदि हर कोई एक ही plop जनरेटर का उपयोग करता है, तो कोड सभी के लिए बहुत समान होगा।

ऑटो कोड स्वरूपण

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

परिणाम

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

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

प्रिय पाठकों! इस लेख में उल्लिखित पूर्ण-स्टैक जावास्क्रिप्ट अनुप्रयोगों को विकसित करने के लिए आप क्या सोचते हैं?

फ्रीलांसरों की एक टीम फुल-स्टैक जावास्क्रिप्ट अनुप्रयोगों को कैसे लिखती है, इसके बारे में एक कहानी