वेब विकास 10 कोडिंग एंटीपार्टर्न आपको बचना चाहिए

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

डिजाइन पैटर्न आम तौर पर होते हैं पुन: प्रयोज्य समाधान कुछ परिदृश्यों के लिए, यह हो सकता है आमतौर पर आने वाली समस्याओं को हल करने के लिए काम में आते हैं, और हमारे कोड को अनुकूलित करने में हमारी सहायता कर सकते हैं.

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

एंटीपैटर्न क्या हैं?

अवधि “antipattern” 1998 में एंटीपैटर्न्स नामक पुस्तक में गढ़ा गया था। यह संदर्भित करता है पुन: उपयोग किए गए समाधान जो शुरू में उपयोगी लगते हैं, लेकिन बाद में पता चला अच्छे से अधिक नुकसान करने के लिए.

यह विभिन्न कारणों से हो सकता है, उदाहरण के लिए यदि हम सही संदर्भ, सेटिंग, या समय में पैटर्न का उपयोग नहीं करते हैं (अतीत में प्रभावी होने वाले समाधान हमेशा वर्तमान में काम नहीं कर सकते हैं), या अन्य मामलों में पूरे प्रतिमान शुरू से ही खराब था.

एंटीपैटर्न भी अक्सर कहा जाता है विफलता के पैटर्न. अच्छी खबर यह है कि यह है उन्हें पहचानना और उनसे बचना संभव है.

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

1. समयपूर्व अनुकूलन

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

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

यदि हम एक प्रभावी वास्तुकला स्थापित करने से पहले प्रदर्शन के लिए अनुकूलन करते हैं, तो हम कर सकते हैं कम कोड पठनीयता, बनाना डिबगिंग और रखरखाव कठिन है, तथा अधूरा भाग जोड़ें हमारे कोड के लिए.

समय से पहले अनुकूलन को रोकने के लिए यह एक अच्छा विचार है कि YAGNI (आपको इसकी आवश्यकता नहीं है) प्रोग्रामिंग सिद्धांत का पालन करें, जो करने की सलाह देता है “हमेशा उन चीजों को लागू करें जब आपको वास्तव में उनकी आवश्यकता होती है, कभी नहीं जब आप सिर्फ यह सोचते हैं कि आपको उनकी आवश्यकता है.”

2. पहिए का पुनरुद्धार

“पहिया बदलते” कभी कभी एंटीपैटर्न भी कहा जाता है “वैक्यूम में डिजाइनिंग”. यह तब होता है जब हम चाहते हैं सब कुछ अपने आप से करो तथा खरोंच से सब कुछ लिखें, पहले से मौजूद तरीकों, एपीआई या पुस्तकालयों की तलाश किए बिना.

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

3. निर्भरता नर्क

के विपरीत है “पहिया बदलते” एंटीपैटर्न एक और आम एंटीपैटर्न कहा जाता है “निर्भरता नरक”.

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

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

4. स्पेगेटी कोड

“स्पेगेटी कोड” शायद सबसे प्रसिद्ध कोडिंग एंटीपैटर्न है। ये बताता है एक अनुप्रयोग जो एक उचित वास्तुकला की कमी के कारण डिबग या संशोधित करना कठिन है.

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

स्पेगेटी कोड आमतौर पर उपजा है विभिन्न खराब कोडिंग प्रथाओं का संयोजन, जैसे कि कोड में उचित सशर्त ब्लॉक नहीं होते हैं, जिसमें बहुत से गोटो स्टेटमेंट, अपवाद और थ्रेड होते हैं, जिनमें कुछ अन्य भाग होते हैं, वस्तुओं के बीच कम से कम संबंध होते हैं, ऐसे कार्य या तरीके होते हैं जिनका पुन: उपयोग नहीं किया जा सकता है, या ठीक से दस्तावेज नहीं किया जाता है या बिल्कुल भी.

5. क्रमपरिवर्तन द्वारा प्रोग्रामिंग

“क्रमपरिवर्तन द्वारा प्रोग्रामिंग” या “दुर्घटना से प्रोग्रामिंग” ऐसा तब होता है जब हम छोटे संशोधनों के साथ क्रमिक परीक्षण करके, एक-एक करके उनका आकलन करके और अंत में पहले काम करने वाले को लागू करके समस्या का हल खोजने का प्रयास करते हैं।.

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

6. कॉपी और पेस्ट प्रोग्रामिंग

“प्रोग्रामिंग को कॉपी और पेस्ट करें” तब होता है जब हम अपने आप को दोहराएं नहीं दोहराते हैं (DRY) कोडिंग सिद्धांत, और सामान्य समाधान बनाने के बजाय, हम पहले से ही मौजूद कोड स्निपेट को अलग-अलग स्थानों पर डालते हैं, और बाद में दिए गए संदर्भ में फिट करने के लिए उन्हें संपादित करते हैं।.

यह अभ्यास एक कोड में परिणाम अत्यधिक दोहराव है, सम्मिलित कोड भागों के रूप में आमतौर पर केवल मामूली विसंगतियों में भिन्न होते हैं.

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

7. कार्गो-कल्ट प्रोग्रामिंग

का नाम “कार्गो-पंथ प्रोग्रामिंग” नामक एक विशिष्ट नृवंशविज्ञान घटना से आता है “कार्गो पंथ”. कार्गो पंथ द्वितीय विश्व युद्ध के बाद दक्षिण प्रशांत में दिखाई दिए, जब उन्नत सभ्यताओं के साथ जबरन संपर्क ने यह सोचने के लिए नेतृत्व किया कि निर्मित उत्पादों, जैसे कि कोका-कोला, टीवी और द्वीपों के लिए मालवाहक जहाजों द्वारा लाए गए रेफ्रिजरेटर, अलौकिक द्वारा बनाए गए थे। तरीकों; और अगर वे पश्चिमी देशों के रीति-रिवाजों के समान जादुई संस्कार करते हैं, तो माल से भरा माल फिर से आ जाएगा.

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

कई मामलों में डेवलपर्स बस किसी भी वास्तविक उद्देश्य के बिना उस समय कूल्हे क्या करते हैं. यह अभ्यास न केवल बुरा है क्योंकि यह हमारे आवेदन को शानदार ढंग से फूला हुआ बनाता है, लेकिन यह आसानी से हमारे कोड में नए बग भी पेश कर सकता है.

8. लावा प्रवाह

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

यह आमतौर पर साथ होता है लीगेसी कोड, या जब कोड किसी और ने लिखा था (आमतौर पर उचित दस्तावेज के बिना), या जब परियोजना विकास से उत्पादन के चरण में बहुत तेजी से चली गई.

एंटीपैटर्न का नाम ज्वालामुखी से आने वाले लावा से होता है, यानी पहली बार में यह बहुत सावधानी बरतते हुए जल्दी और द्रवित हो जाता है, लेकिन बाद में यह जम जाता है और निकालना मुश्किल हो जाता है.

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

9. हार्ड कोडिंग

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

हार्ड कोड के साथ मुख्य समस्या यह है कि यह केवल एक निश्चित वातावरण में ठीक से काम करता है, और कम से किसी भी समय स्थितियां बदलती हैं, हमें संशोधित करने की आवश्यकता है स्रोत कोड, आमतौर पर कई अलग-अलग स्थानों में.

10. सॉफ्ट कोडिंग

यदि हम हार्ड कोडिंग के नुकसान से बचने की बहुत कोशिश करते हैं, तो हम आसानी से एक और एंटीपैटर्न में भाग सकते हैं जिसे कहा जाता है “नरम कोडिंग”, जो इसके ठीक विपरीत है.

मुलायम कोडिंग में, हम उन चीजों को डालते हैं जो स्रोत कोड में बाहरी स्रोतों में होनी चाहिए, उदाहरण के लिए हम डेटाबेस में व्यावसायिक तर्क संग्रहीत करते हैं। सबसे आम कारण है कि हम ऐसा क्यों करते हैं, यह डर है कि भविष्य में व्यावसायिक नियम बदल जाएंगे, इसलिए हमें कोड को फिर से लिखना होगा.

चरम मामलों में, एक नरम कोडित कार्यक्रम कर सकते हैं इतना सारगर्भित और दृढ़ हो गया है कि इसे समझना लगभग असंभव है (विशेष रूप से नई टीम के सदस्यों के लिए), और बेहद बनाए रखने और डिबग करने के लिए मुश्किल है.