दायरे से बाहर

एक प्रोग्रामर के रूप में मेरा विकास 2005 में शुरू हुआ और आज भी जारी है।
निस्संदेह, कई पाठक अधिक व्यापक अनुभव, लेकिन भाषण देने में सक्षम होंगे
कुछ और बात करेंगे। मेरी पेशेवर वृद्धि एक दिलचस्प अवधि के साथ हुई -
Runet में प्रोग्रामिंग की संस्कृति में सुधार, अगर आप इसे कॉल कर सकते हैं।
पेशेवर हमेशा से रहे हैं, लेकिन आज औसत प्रोग्रामर का ज्ञान (में)
वैसे भी, सर्वश्रेष्ठ क्षेत्रों के क्षेत्र में) तब की तुलना में अतुलनीय है।

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

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

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

अल्पसंख्यक अधिकारों में एक लघु भ्रमण

क्या आपको TDD पसंद नहीं है? प्रक्रियात्मक शैली में कोड लिखना पसंद है? EJB का उपयोग नहीं?
ऐ-ऐ-ऐ, यह कैसे हो सकता है कि तेरे पैरों के नीचे की धरती नहीं जल रही है। किसी भी समाज में विभाजित है
समूह, और यदि आप एक समूह में शामिल होने के लिए तैयार नहीं हैं, तो आपको खुशी से रैंक किया जाएगा
एक और। कहीं और, जहां व्यवहार का तर्क जैविक पर आधारित है
पैटर्न, समूहों के बीच प्रतिस्पर्धा है। समूहों में से एक
पूर्ण सत्य की स्थिति, शेष के मानद पुरस्कार जीतता है
मानव जाति के शत्रु घोषित किए जाते हैं, सर्वोत्तम मज़ाकिया तौर पर।

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

जब तक प्रवृत्ति "सही कोड लिखें" से "कोड लिखें,"
वर्तमान समस्या को हल करना ”, हम साक्षात्कार के साथ टेस्ट कोड लिखने के लिए बर्बाद हैं
एक ऐसे पैटर्न को लागू करना जो हमारे लिए कभी भी उपयोग में न आए
एक भयानक सपना, और फिर, नौकरी के लिए आवेदन करने के बाद, कोई कम प्रसिद्ध स्टैंप टेस्ट नहीं,
कोड के पोषित 100% कवरेज को प्राप्त करने के लिए कुछ भी नहीं परीक्षण।

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

ओलंपस के शीर्ष पर

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

और आज हमारे पास सिफारिशों का एक सेट है जो अच्छे के नियम बन गए हैं
विकास में स्वर। शायद ये नियम अच्छे हैं, आइए उनकी सीमाओं को रेखांकित करने की कोशिश करें
अनुप्रयोगों:

1) स्थैतिक टाइपिंग वाली भाषाएँ - मुख्य रूप से C ++ और Java।

2) बड़े सॉफ्टवेयर उत्पादों पर आधारित विनिमेयता
परियोजना में शामिल प्रोग्रामर।

3) सॉफ्टवेयर उत्पादों को आगे के विकास और दीर्घकालिक के लिए डिज़ाइन किया गया है
समर्थन करते हैं।

4) काफी सख्त विश्वसनीयता आवश्यकताओं के लिए डिज़ाइन किया गया सॉफ्टवेयर - कॉर्पोरेट
सामान्य रूप से समाधान।

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

काला बाजार

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

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

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

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

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

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

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

हाँ, क्या पाप छुपाना है, अपने समय में विनम्र सेवक सम्मान 2 के साथ विफल रहा
महीने भर की फ्रीलांस परियोजनाएं, सभी बोधगम्य समय सीमा से अधिक और शर्म के साथ भी
कम उत्पादकता के कारण दो नौकरियों से बाहर कर दिया गया था। कारण सरल है - मैं
हर काम को समझदारी से करने की कोशिश की।

उद्योग अश्लीलता

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

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

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

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

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

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

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

हेयूरिस्टिक नपुंसकता

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

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

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

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

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

अपार आलिंगन करो

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

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

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

ए) कुटिल लिखित गैर-एक्स्टेंसिबल कोड के मामले में, हमें
कार्यक्षमता

बी के साथ बहुत सी कठिनाइयाँ आती हैं ) एक्स्टेंसिबल कोड बनाने के मामले में, पुनर्लेखन लागत
कोड लिखने के प्रारंभिक चरण में रखी गई है

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

आवेदन का क्षेत्र

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

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

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

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

क्या करें?

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

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