प्रोग्रामिंग में स्टीरियोटाइप सोच

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



1. विधि कोड को मॉनिटर स्क्रीन पर फिट होना चाहिए।
इसे शाब्दिक रूप से भी न लें। मैं इसे इस प्रकार बताऊंगा: आपको ऐसी विधियाँ नहीं लिखनी चाहिए जो अनुप्रयोग तर्क के संदर्भ में एक से अधिक स्पष्ट ठोस कार्यवाही करती हों। यानी यदि परिस्थितियां ऐसी हैं कि आपका तरीका 300 से कम रेखाओं का नहीं हो सकता है, तो इसे अलग तरीकों से विभाजित न करें। ऐसे तरीकों के नाम डेवलपर को कुछ भी नहीं बताएंगे। आप केवल कोड में भ्रम पैदा करेंगे। आखिरकार, इन तरीकों को केवल एक विशिष्ट क्रम में कहा जा सकता है, जो अनुक्रम की अपरिवर्तनीय श्रृंखला का निर्माण करता है।
एक बार मुझे एप्लिकेशन लॉजिक विधि के लिए कुछ अतिरिक्त अधिभार जोड़ने की जरूरत थी, जिसने UI, सार्वजनिक और व्यवस्थापक भागों की परत को प्रभावित किया। मैं जल्दी से व्यवस्थापक नियंत्रक को समझ गया। लेकिन जनता के साथ समस्याएं थीं।
एक विधि कॉल जिसे मुझे बदलने की आवश्यकता हो सकती है। मैं एक रहस्यमय तरीके से था जिसमें केवल एक क्रिया के माध्यम से एक लूप था जो मुझे कुछ भी नहीं बताता था। लेकिन वह 10 लाइनों का था! यह समझने के लिए कि यहां क्या हो रहा था, मैं एक स्तर पर गया, जहां इस पद्धति को कहा जाता है ... फिर मुझे डीजा वु का एक तेज अर्थ मिला - फिर से एक छोटा सा फेसलेस विधि में संचालन का एक छोटा रहस्यमय सेट। और इन कोडों में से कई में मेरे व्यापार तर्क पद्धति को कितना बुरा कहा गया। मुझे एक स्पष्ट और ठोस विधि को पढ़ने से बचाने के लिए इस कार्यान्वयन के लेखक के लिए धन्यवाद, भले ही यह मॉनिटर स्क्रीन पर फिट न हो। एक एड़ी के साथ इसे बदलना, लानत है क्या।

2. स्टेटिक खराब है!
मेरे आस-पास कई प्रोग्रामर हैं जो इस बात से सहमत हैं, आप में से भी मुझे लगता है। मुझे यह भी पता नहीं है कि इस स्टीरियोटाइप के पैर कहाँ से बढ़ते हैं। मैंने केवल एक वज़नदार तर्क सुना - स्टेटिक्स को परीक्षणों के साथ कवर करना कठिन है। केवल सामान्य ज्ञान मुझे बताता है कि मुख्य बिंदु को ध्यान में नहीं रखा गया है: प्राथमिक क्या है और द्वितीयक क्या है। यानी किसके अनुकूल होना चाहिए। यह वही है कि मानव शरीर को उन कपड़ों के अनुकूल होना चाहिए जो हम स्टोर में खरीदते हैं।
वैसे, इस स्टीरियोटाइप का यहां एक और दिलचस्प बदलाव है: स्टेटिक्स खराब हैं, और विस्तार के तरीके शांत हैं! <विडंबना> यह नहीं हो सकता ... </ irony>

3. मेरे कार्यान्वयन में जितने अधिक पैटर्न का उपयोग किया गया है, मैं एक प्रोग्रामर के रूप में बेहतर हूं।
आत्म-पुष्टि का एक बहुत ही दिलचस्प तरीका। अपने FAQ को छोड़ें और एक सहकर्मी पर दया करें, जो 5 वें रैपर को हिलाकर आपके कार्यान्वयन में बदलाव करने की कोशिश करेगा, सबसे अधिक संभावना है कि वह सोचेंगे: "मेरी राय में, मैं हार गया ... मैं इस परियोजना के लिए खोज का उपयोग करूंगा, और सभी चीजों को सच के साथ प्रतिस्थापित करना होगा। झूठी, स्पष्ट कार्यक्षमता में। "
पेटरन का उपयोग तब करें जब वह यहां उपयुक्त न हो, लेकिन जब आपको इसके उपयोग में कोई ठोस लाभ दिखाई दे तो <irony> या जब आप अपने कोड </ irony> का अतिरिक्त स्तर बनाना चाहें।

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

5. हम पहले कोड (इकाई ढांचे के बारे में बात) से प्यार करते हैं!
हमेशा कोड को पहले एक समझदार दृष्टिकोण के रूप में माना जाता है। मेरे लिए, कोड प्राथमिक है। मेरे लिए यह महत्वपूर्ण है कि मैं कोड में डेटा को कैसे हेरफेर करूंगा। एक डेटाबेस डेटा के समानांतर उपयोग के लिए सिर्फ एक बॉक्स है। आज मैं एक बॉक्स का उपयोग करता हूं, कल दूसरे का। लेकिन मैं मानता हूं, 5 साल पहले, कोड के लिए मेरी प्रतिबद्धता पर प्रतिबंध लगा दिया गया था। इस दृष्टिकोण ने सहकर्मियों से उपहास किया, या मेरी अक्षमता का संकेत दिया। यह डेटाबेस प्रोग्राम कोड पर कैसे निर्भर करेगा, और इसके विपरीत नहीं?
अब, जब Microsoft ने पहले कोड को बढ़ावा देना शुरू किया, तो हर कोई इसके समर्थक बन गए। यानी बहुमत की राय को उलट दिया गया है। क्या आईटी में कुछ बदला है? विज्ञापन कंपनी माइक्रोसॉफ्ट की गिनती नहीं। स्टीरियोटाइप बदल गया है।

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