मैं बारह साल से प्रोग्रामिंग कर रहा हूं और कई भाषाओं के साथ काम कर चुका हूं। इनमें , , , , और अंत में शामिल हैं। हर भाषा या ढांचे के अपने नियम होते हैं। उदाहरण के लिए, फ़ंक्शन नामों के लिए उपयोग करता है। C C++ Java Python C# JavaScript रस्ट स्नेक-केस का हालाँकि, कुछ नियम, उपकरण और पैटर्न हैं जिनकी मैं सराहना करने के लिए बढ़ा हूँ। मैं इन्हें अपने फ्रंटएंड एप्लिकेशन में शामिल करता हूं। ये नियम मेरे साथ अधिक प्रतिध्वनित होते हैं और कोडिंग को एक आसान प्रक्रिया बनाते हैं। यहाँ कुछ हैं जो मुझे विशेष रूप से पसंद हैं: कार्यात्मक प्रोग्रामिंग मेरी पहली युक्ति सी से आती है, जो पहली भाषा मैंने सीखी। याद रखें जब हम लिखते थे? इसके बारे में सोचकर ही मुझे ठंड लग जाती है। जब रिएक्ट ने कार्यात्मक घटकों पर स्विच किया, तो इसने कोड को न केवल पढ़ने में आसान बना दिया, बल्कि परीक्षण करना भी आसान बना दिया। रिएक्ट विद क्लासेस यह कार्यात्मक प्रोग्रामिंग के सिद्धांतों के साथ भी बेहतर तालमेल बिठाता है। यह दृष्टिकोण फ्रंटएंड फ्रेमवर्क के साथ बहुत अच्छा काम करता है क्योंकि वे अक्सर कोड के पुन: प्रयोज्य टुकड़े बनाने पर ध्यान केंद्रित करते हैं। फ्रंटएंड डेवलपमेंट में कार्यात्मक प्रोग्रामिंग का उपयोग करना हमेशा मेरे लिए इस अवधारणा को समझने और नई फ्रंटएंड सुविधाओं का निर्माण करने के लिए एक सहायक रणनीति रही है। कार्यात्मक प्रोग्रामिंग सिद्धांतों का पालन करना मेरे हर फ्रंटएंड एप्लिकेशन में होना चाहिए। यदि आप कार्यात्मक प्रोग्रामिंग से परिचित नहीं हैं, तो मैं इसे एक्सप्लोर करने की अत्यधिक अनुशंसा करता हूं। यह बिंदु इस सूची की शुरुआत में अकारण नहीं है। इससे आपकी विकास प्रक्रिया में जो लाभ हो सकते हैं वे काफी हैं। और अधिक कोड फ़ॉर्मेटर्स जब मैंने पहली बार प्रोग्रामिंग शुरू की, तो मैंने कोड स्वरूपण पर ज्यादा ध्यान नहीं दिया। मुझे लगता है कि यह सब विश्वविद्यालय में शुरू हुआ जहां मैं एक सफेद विषय के साथ अपने कूल पर सी ++ सीख रहा था। कोडब्लॉक आईडीई देखते हुए, मैं देख सकता हूं कि मैंने फ़ॉर्मेटिंग के लिए केवल रिक्त स्थान का उपयोग किया है। मैंने इसका स्वचालित रूप से ध्यान रखने के लिए किसी भी उपकरण का उपयोग नहीं किया। 2016 से GitHub पर अपने पुराने कोड को अब, मुझे एहसास हुआ कि यह एक गलती थी। यदि आप अपने प्रोजेक्ट में कुछ स्वचालित कर सकते हैं, तो आपको निश्चित रूप से करना चाहिए। अब, मैं हर प्रोजेक्ट की शुरुआत में हमेशा और स्थापना करता हूं। यदि आप इस पर बहुत अधिक समय खर्च नहीं करना चाहते हैं, तो आप की तरह पूर्व-निर्मित कॉन्फ़िगरेशन का उपयोग कर सकते हैं। Prettier ESLint की Airbnb मेरा विश्वास करो, आपको इसका पछतावा नहीं होगा! ओह, और अपने IDE में फाइल सेव एक्शन पर एक ऑटोफॉर्मेटिंग सेट करना न भूलें! पूर्व-प्रतिबद्ध क्रियाएँ अब जब आपके पास शानदार फ़ॉर्मैटर हैं, तो चलिए उन्हें स्वचालित करते हैं! मुझे ठीक से याद नहीं है कि मैंने कब प्री-कमिट हुक का उपयोग करना शुरू किया, लेकिन वे मेरी परियोजनाओं में बहुत मददगार रहे हैं। मैन्युअल रूप से प्रारूपित क्यों करें जब इसे प्रत्येक प्रतिबद्धता से पहले स्वचालित किया जा सकता है? और जैसे टूल्स इस ऑटोमेशन को संभव बनाते हैं। हस्की लिंट-स्टेज्ड फाइलनामों के लिए कबाब-केस भले ही कई प्रशंसक और आलोचक हैं, फिर भी मैं सकारात्मक पर ध्यान देना पसंद करता हूं। कोणीय अक्सर बड़ी कंपनियों और बड़े अनुप्रयोगों के लिए पहली पसंद होता है। मुझे लगता है कि एंगुलर में किए गए कई फैसले चीजों को बनाए रखने में आसान रखने के लिए थे। एंगुलर के इसलिए मैंने अपने सभी दृश्यपटल परियोजनाओं के लिए कबाब-केस का उपयोग करने का निर्णय लिया। यह कुछ लाभ प्रदान करता है, जैसे: : मुझे इस बारे में चिंता करने की ज़रूरत नहीं है कि पास्कल-केस, ऊंट-केस, या सांप-केस (यदि आप चाहें) का उपयोग करें। कबाब-केस के साथ, बस एक ही विकल्प है। सादगी : यदि आप एक टीम पर काम कर रहे हैं, तो कबाब-केस जैसी एकल नामकरण प्रथा को अपनाने से यह सुनिश्चित करने में मदद मिल सकती है कि सभी एक ही पृष्ठ पर हैं और परियोजना व्यवस्थित रहती है। यह न भूलें कि आप पैकेज का उपयोग करके एस्लिंट नियम के माध्यम से कबाब-केस का उपयोग करने के लिए बाध्य कर सकते हैं: संगति यूनिकॉर्न 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ], : विभिन्न ऑपरेटिंग सिस्टम फ़ाइल नामों को अलग-अलग तरीके से संभालते हैं। उदाहरण के लिए, विंडोज़ पूंजीकरण के बारे में परवाह नहीं करता है, लेकिन लिनक्स करता है। कबाब-केस का उपयोग करके, जो लोअरकेस अक्षरों और हाइफ़न का उपयोग करता है, मैं किसी भी मुद्दे से बचता हूँ। क्रॉस-प्लेटफ़ॉर्म संगतता : गिट में लोअरकेस से अपरकेस में फ़ाइल का नाम बदलने में समस्या है। कबाब-केस का उपयोग करने से मुझे इसकी चिंता करने की आवश्यकता नहीं है। कोई गिट समस्या नहीं मैं चीजों को सरल रखना पसंद करता हूं। अगर मैं अपने जीवन को आसान बना सकता हूं और इससे कुछ लाभ प्राप्त कर सकता हूं, तो मैं इसके लिए पूरी तरह तैयार हूं। फ़ाइल प्रकारों के लिए टैग का उपयोग करना एक और चीज जो मैंने एंगुलर से उधार ली है कि वे फाइलों का नाम कैसे देते हैं। कोणीय एक तरह से फाइलों के नामकरण की सिफारिश करता है जो उनके कार्य और प्रकार को दर्शाता है। मुझे लगता है कि इससे मेरे लिए नेविगेट करना और प्रोजेक्ट की संरचना को समझना आसान हो जाता है। कोणीय में, फ़ाइल नाम में आमतौर पर तीन भाग होते हैं: सुविधा क्षेत्र, फ़ाइल की भूमिका और फ़ाइल का प्रकार। उदाहरण के लिए, दिखाता है कि फ़ाइल फीचर के लिए एक घटक है और यह एक टाइपस्क्रिप्ट फ़ाइल है। के लिए एक सेवा है। heroes.component.ts heroes heroes.service.ts heroes मैं का बहुत बड़ा प्रशंसक नहीं हूं, लेकिन मैं अपने रिएक्ट घटकों के लिए समान संरचना का उपयोग करता हूं। यहाँ एक उदाहरण है: services my-component ├── my-component.component.tsx ├── my-component.type.ts ├── my-component.style.css ├── my-component.spec.tsx └── my-component.story.mdx मैं इस पैटर्न का उपयोग अपने हुक और कार्यों के लिए भी करता हूं। यह पैटर्न मुझे उनसे संबंधित फाइलों के बगल में अपना परीक्षण करना भी सिखाता है। स्वचालित कोड जनरेशन मैंने पहले जिस पैटर्न का उल्लेख किया है वह बहुत मददगार है, लेकिन हम इसे स्वचालन के साथ और भी बेहतर बना सकते हैं। , और मैं हमेशा ऐसा करने के लिए उपयोग करता हूं। प्लॉप का टेम्प्लेट सिस्टम बहुत शक्तिशाली है, लेकिन सबसे महत्वपूर्ण बात यह है कि यह समय बचाता है। कोणीय सीएलआई उपयोगकर्ताओं को स्वचालित रूप से कोड उत्पन्न करने देता है प्लॉप का स्वचालन के साथ, मुझे किसी घटक की मूल संरचना के बारे में सोचने में अधिक समय नहीं देना पड़ता है। यह कार्य स्वचालित हो सकता है, जो मुझे उस पर ध्यान केंद्रित करने की अनुमति देता है जो मैं वास्तव में करना चाहता हूं। एक 'डोमेन' का उपयोग करना मैं यहाँ विस्तार से यह नहीं बताने जा रहा हूँ कि क्या है। यदि आप इसके बारे में अधिक जानना चाहते हैं, तो मैं पढ़ने की सलाह देता हूं। अभी, मैं फुल-स्टैक डेवलपर्स की एक टीम के साथ काम कर रहा हूं, और हमने पाया है कि हमारे फ्रंटएंड प्रोजेक्ट में एक लेयर होना वास्तव में उपयोगी है। domain इस लेख को डोमेन यह वह जगह है जहां हम अपने सभी मुख्य प्रकार और संचालन डालते हैं। यह हमारे ऐप में 'सत्य के स्रोत' के रूप में कार्य करता है। यदि आप देखना चाहते हैं कि मैं अपने ऐप्स में 'डोमेन' को कैसे प्रबंधित करता हूं, तो आप देख सकते हैं। मैं इस विषय का वर्णन करने में बहुत समय बिताता हूँ। इस लेख को अपनी वास्तुकला का परीक्षण के साथ हमारे काम में, हमें एक बार एक समस्या का सामना करना पड़ा जहां तर्क कई परतों में मिश्रित हो गया, जैसे कि हमारे डोमेन के अंदर रिपॉजिटरी में परिभाषित एक प्रकार का उपयोग करना। यह एक स्वच्छ वास्तुकला के दृष्टिकोण से वर्जित है, लेकिन हर कोई गलती करता है। कोटलिन तभी हमने खोज की, जो हमारे आर्किटेक्चर की इकाई परीक्षण के लिए एक उपकरण है। यह मूल रूप से जांचता है कि क्या हम अपनी वास्तुकला का सही ढंग से पालन कर रहे हैं। आर्कयूनिट की यदि आप एक निश्चित आर्किटेक्चर को बनाए रख रहे हैं, तो यह जाँचने के लिए एक उपकरण होना उपयोगी हो सकता है कि क्या यह किसी बिंदु पर तोड़ा नहीं गया है। इस संबंध में जैसा उपकरण अमूल्य हो सकता है। निर्भरता-क्रूजर और यह आपकी फ्रंटएंड परियोजनाओं को बढ़ाने के लिए अन्य भाषाओं और रूपरेखाओं से पैटर्न की मेरी आवश्यक सूची को समाप्त करता है। मुझे उम्मीद है कि आपको यह जानकारी मददगार लगी होगी और इनमें से कम से कम एक रणनीति ने आपको इसे अपने काम में लागू करने के लिए प्रेरित किया होगा!
