एक प्रोग्रामर के 3 पाप: हार्डकोडिंग, गवनोकोडिंग और शिज़ोकोडिंग

प्रोग्रामिंग में आपके द्वारा सामना की जाने वाली 3 कोड समस्याएं हैं: हार्डकोड, गोवनोकॉड और शिज़ोकॉड।

चलिए इसके बारे में बात करते हैं।

hardcoding

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

आमतौर पर, इस वर्ग की समस्याओं का जल्दी पता लगाया जाता है और आसानी से इलाज किया जाता है।

Govnokod

यह एक अधिक कठिन समस्या है। अक्सर व्यक्तिपरक। मोटे तौर पर, यह सिर, टीम या समुदाय में अपनाई गई कोड की शैली का उल्लंघन है।

प्लेटफ़ॉर्म के आधार पर और कभी-कभी प्लेटफ़ॉर्म के आधार पर भी कोड की विभिन्न शैलियाँ होती हैं:

• सिम्फनी कोडिंग मानक
• वर्डप्रेस कोडिंग मानक
• PSR - PHP मानक अनुशंसाएँ

यह php दुनिया से है। अन्य समुदायों में, स्थिति समान है। इसमें टैब के बारे में कहानियां, 2 स्पेस के बाद टैब या 4 स्पेस के बाद टैब आदि शामिल हैं।

यहां शुद्ध कोड की समस्या उत्पन्न होती है ... उदाहरण के लिए, 3-4 पृष्ठों के लंबे कार्य, जिसकी आलोचना की जाती है। यह हमेशा निश्चित रूप से खराब नहीं होता है, लेकिन अक्सर ऐसे कार्यों को कम करना संभव होता है, उन्हें छोटे कार्यों की एक श्रृंखला में विभाजित करना, जिनमें से प्रत्येक अपनी समस्या को हल करता है।

आमतौर पर, विशिष्ट टीम में स्वीकृत मानकों के सॉफ्टवेयर और नियंत्रण के माध्यम से इन समस्याओं का आसानी से इलाज किया जाता है।

एरोबेटिक्स, जब एक डेवलपर परियोजना के आधार पर कोड की विभिन्न शैलियों के बीच स्विच कर सकता है।

यह बुरा है जब डेवलपर टीम द्वारा अपनाई गई कोड शैली का उल्लंघन करता है या अपने पसंदीदा (अक्सर केवल सीखा हुआ) कोड शैली को एकमात्र सही मानता है।

कोई सही कोड शैली नहीं हैं। टीम में स्वीकृत शैली या आम तौर पर स्वीकृत शैली हैं।

इसके अलावा एक अपेक्षाकृत सरल समस्या और आसानी से हल।

Shizokod

यह एक कम लोकप्रिय समस्या है, लेकिन अक्सर सबसे महंगी है।

स्किज़ोकोड - सिज़ोफ्रेनिया की अवधारणा से आता है। विकिपीडिया से निचोड़:

सिज़ोफ्रेनिया (अन्य ग्रीक से: ”" विभाजित "," विभाजित "+ renρήν -" मन, सोच, विचार "), पहले से ही अव्यक्त। मनोभ्रंश praecox ("समय से पहले मनोभ्रंश") या सिज़ोफ्रेनिया एक अंतर्जात बहुरूपिक मानसिक विकार या मानसिक विकारों का समूह है जो सोच प्रक्रियाओं के टूटने और भावनात्मक प्रतिक्रियाओं से जुड़ा है।

2 महत्वपूर्ण बिंदु हैं: विभाजन और मनोभ्रंश। जो स्किज़ोकोड के कारण हैं।

एक आदर्श कोड वह होता है जिसे लिखा नहीं जाता है। Schizocoders इस अवधारणा से परिचित नहीं हैं।

संक्षेप में, स्किज़ोकोड एक कोड है जो ओक्टम के रेजर सिद्धांत का उल्लंघन करता है।

विकिपीडिया से निचोड़:

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

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

काल्पनिक समस्याएं - खराब सॉफ्टवेयर की जड़

2 मुख्य लक्षण हैं: बैसाखी पर साइकिल का आविष्कार और अमूर्त की परतों का गुणा।

बैसाखी पर साइकिल का आविष्कार

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

उदाहरण:

• अपने स्वयं के सीएमएस / पीटीएम फ्रेमवर्क को लिखना जो मौजूदा हैं, एक घातक दोष है
• सिम्फनी ब्लॉग इस तथ्य के बावजूद कि पूरी दुनिया इसके लिए वर्डप्रेस का उपयोग करती है।
• Laravel पर ऑनलाइन स्टोर, इस तथ्य के बावजूद कि WooCommerce (दुनिया में नंबर 1) है, Magento (भी अच्छा), 1C-Bitrix (सबसे खराब, लारवेल से बेहतर)
• मैं एक स्थिति से मिला जब लेआउट बूटस्ट्रैप पर था, लेकिन डेवलपर ने लेबल के लिए अपनी शैली लिखने का फैसला किया। बूटस्ट्रैप में पहले से मौजूद लेबल वर्ग को जोड़ने से आपको क्या रोका गया?
• निरर्थक कार्यों, विधियों और कक्षाओं में कैलकुलस नहीं होते हैं जो तैयार किए गए पुस्तकालयों और उपयोग किए गए प्लेटफार्मों में विधियों का उपयोग करके बचा जा सकता है

अमूर्तता की परतों का अनियंत्रित प्रसार: अतिरिक्त कक्षाएं, विरासत, तरीके

चौकस पाठक govnokod के साथ एक संघर्ष नोटिस सकता है। एक मामले में, समस्या यह है कि फ़ंक्शन या वर्ग बहुत लंबा है, लेकिन समस्या यह है कि इसके विपरीत संस्थाओं का अत्यधिक विखंडन है।

यहां यह ध्यान दिया जाना चाहिए कि यह चरम सीमाओं में से एक है, जिसकी सीमा हमेशा निरीक्षण करना आसान नहीं है।

एक तरफ, 3 पृष्ठों या एक वर्ग पर एक फ़ंक्शन के साथ सब कुछ हल करने की कोशिश करना बुरा है जिसमें HTML और टेम्पलेट यांत्रिकी शामिल हैं और कहीं न कहीं यह कोड कई कार्यों / वर्गों / घटकों में तोड़ने के लिए अधिक लाभदायक है, जिनमें से प्रत्येक अपनी समस्या हल करता है। यह एक अति है।

दूसरी ओर, सरल कोड को 5 वर्गों में तोड़ना बुरा है, जिनमें से प्रत्येक में 3-4 लाइनों के 3-4 तरीके हैं, कई बेकार विरासतों के साथ, जब आप न्यूनतम विरासत के साथ एक या दो कर सकते हैं या विरासत के बिना भी अगर इससे बचा जा सकता है।

शानदार और बुरे अमूर्त के परिणाम

अच्छे कारण के बिना तरीकों, वर्गों, वंशानुक्रम का प्रसार - यह शानदार कोड और अमूर्त की परतों की वृद्धि है।

हर चीज की कीमत होती है, साथ ही अतिरिक्त सार भी:

• नए डेवलपर प्रशिक्षण लाड़
• अधिक कोड, विफलता के अधिक बिंदु, अधिक त्रुटियां
• निदान और कोड डीबगिंग जटिल है

सोचा समस्या

अमूर्तता, विरासत, तरीकों की अधिक परतें, समस्याओं के परिवर्तन, सुधार और निदान के लिए अधिक विचारशील ईंधन की आवश्यकता होती है।

और ईंधन की काम करने की मात्रा परिमित है और अक्सर इसकी कमी विकास की बहुत बड़ी लागत को पूरा करती है।

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

एक वीडियो जो बताता है कि ईंधन क्या सोच रहा है और 1 मिनट के लिए एक सरल व्यायाम देता है, जो आपको एक सरल उदाहरण पर ईंधन की कमी की भावना को याद करने की अनुमति देता है:

क्या यह OOP, कक्षाओं और विरासत में चल रहा है?

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

OOP, कक्षाएं, और वंशानुक्रम न तो खराब हैं और न ही अच्छे हैं। ये उपकरण हैं। मैं व्यक्तिगत रूप से उनका उपयोग करता हूं।

हालाँकि, मेरे अपने कई नियम हैं:

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

सारांश

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

मेरी अभिव्यक्ति सरल है:

• किसी अन्य बैसाखी बाइक का आविष्कार करने से पहले सर्वश्रेष्ठ नस्ल सिद्धांत सीखना सबसे अच्छा है, जिसकी किसी को भी आवश्यकता नहीं है
• चलो कम schizocode लिखें
• आइए ओक्टम के रेजर सिद्धांत का अनुपालन करना सीखें और बिना किसी कारण के कोड को जटिल न करें
• आइए हमारे विचारों और हमारी टीम को बचाएं

खैर, मैं घोषणापत्र और इसकी आलोचना के समर्थन में टिप्पणी करने में प्रसन्नता होगी।