एक कोणीय डेवलपर के लिए 22 युक्तियाँ। भाग २

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

1. पुन: उपयोग के लिए उपयुक्त छोटे घटक

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

घटकों के साथ काम करते समय, निम्नलिखित सामान्य नियम का पालन किया जाना चाहिए: घटक पेड़ में सबसे गहरा नेस्टेड घटक सबसे "बेवकूफ" भी होना चाहिए।

Ations स्पष्टीकरण

पुन: उपयोग करने वाले घटक कोड दोहराव को कम करते हैं, जो परियोजना के समर्थन और परिवर्तनों को सरल करता है।

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

2. घटकों द्वारा हल किए गए कार्यों के बारे में

जब भी संभव हो, डेटा की कल्पना करने के लिए उपयोग किए जाने वाले तर्क के घटकों के अलावा उपस्थिति से बचें।

Ations स्पष्टीकरण

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

व्यवसाय तर्क, जब अलग-अलग सेवाओं के रूप में प्रस्तुत किया जाता है, तो आमतौर पर यूनिट टेस्ट करना आसान होता है। इस दृष्टिकोण के साथ, इसे विभिन्न घटकों द्वारा पुन: उपयोग किया जा सकता है जिन्हें समान क्षमताओं की आवश्यकता होती है।

3. महान तरीकों के बारे में

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

Ations स्पष्टीकरण

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

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

4. DRY सिद्धांत

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

Ations स्पष्टीकरण

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

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

5. कैशिंग तंत्र

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

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

Ations स्पष्टीकरण

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

6. पैटर्न में तर्क

यदि आपके टेम्प्लेट में कम से कम कुछ तर्क हैं, यहां तक ​​कि एक सरल && अभिव्यक्ति है, तो इस तर्क को निकाला जाना चाहिए और उपयुक्त घटक में डाल दिया जाना चाहिए।

Ations स्पष्टीकरण

यदि टेम्पलेट में तर्क है, तो इसका मतलब है कि इस तरह के टेम्पलेट को इकाई परीक्षण के अधीन नहीं किया जा सकता है, और इस प्रकार, टेम्पलेट का कोड बदलते समय त्रुटियों की संभावना बढ़ जाती है।

▍Do

 //  <p *ngIf="role==='developer'"> Status: Developer </p> //  public ngOnInit (): void {   this.role = 'developer'; } 

▍Posle

// टेम्पलेट
<p * ngIf = "showDeveloperStatus"> स्थिति: डेवलपर

 //  public ngOnInit (): void {   this.role = 'developer';   this.showDeveloperStatus = true; } 

7. लाइनों के साथ काम करें

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

Ations स्पष्टीकरण

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

▍Do

 private myStringValue: string; if (itShouldHaveFirstValue) {  myStringValue = 'First'; } else {  myStringValue = 'Second' } 

▍Posle

 private myStringValue: 'First' | 'Second'; if (itShouldHaveFirstValue) {  myStringValue = 'First'; } else {  myStringValue = 'Other' } //     Type '"Other"' is not assignable to type '"First" | "Second"' (property) AppComponent.myValue: "First" | "Second" 

8. आवेदन राज्य प्रबंधन के बारे में

साइड इफेक्ट को लागू करने के लिए अपने आवेदन की स्थिति और @ ngrx / प्रभावों को नियंत्रित करने के लिए @ ngrx / store का उपयोग करने पर विचार करें। राज्य परिवर्तनों को क्रियाओं द्वारा वर्णित किया जाता है और शुद्ध कार्यों द्वारा निष्पादित किया जाता है जिन्हें रिड्यूसर कहा जाता है।

Ations स्पष्टीकरण

@ ngrx / store एक स्थान पर एप्लिकेशन की स्थिति से संबंधित तर्क को अलग करता है और इसे पूरे प्रोजेक्ट में समान बनाता है। यहां, इसके अलावा, एक मेमोएज़ेशन मैकेनिज्म है जो स्टोरेज के साथ काम करते समय काम करता है, जो एप्लिकेशन के प्रदर्शन को बेहतर बनाता है। @ Ngrx / store तंत्र, Angular की परिवर्तन का पता लगाने की रणनीति के साथ मिलकर, तेज़ अनुप्रयोगों की ओर ले जाता है।

9. आवेदन राज्य की अपरिहार्यता के बारे में

@ Ngrx / store का उपयोग करते समय , एप्लिकेशन स्थिति को अपरिवर्तनीय बनाने के लिए ngrx-store-freeze लाइब्रेरी का उपयोग करने पर विचार करें। यह लाइब्रेरी अपवादों को फेंककर राज्य के उत्परिवर्तन को रोकती है। यह आवेदन की स्थिति में आकस्मिक परिवर्तनों से बचा जाता है जो अप्रत्याशित परिणामों की ओर ले जाता है।

Ations स्पष्टीकरण

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

10. अनुप्रयोग परीक्षण उपकरण

परीक्षण अनुप्रयोगों के लिए विशेष उपकरणों का उपयोग करें। उनमें से जेस्ट और कर्म हैं ।

Ations स्पष्टीकरण

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

कर्मा के परीक्षण धावक को एंगुलरजेएस टीम द्वारा विकसित किया गया था। परीक्षणों को चलाने के लिए, उसे एक वास्तविक ब्राउज़र और DOM की आवश्यकता होती है। कर्म आपको विभिन्न ब्राउज़रों में परीक्षण चलाने की अनुमति देता है। उदाहरण के लिए, जेस्ट को ज़रूरत नहीं है, उदाहरण के लिए, उपयोगकर्ता इंटरफ़ेस या phantom.js के बिना क्रोम ब्राउज़र, क्योंकि इस ढांचे के काम करने के लिए केवल Node.js प्लेटफ़ॉर्म की आवश्यकता है।

11. सर्वर रेंडरिंग

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

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

Ations स्पष्टीकरण

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

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

परिणाम

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

प्रिय पाठकों! यदि आप कोणीय डेवलपर समुदाय के साथ अनुप्रयोगों को बेहतर बनाने के लिए उपयोगी सुझाव साझा कर सकते हैं, तो कृपया ऐसा करें।