विरोधी प्रतिरूप
सॉफ्टवेयर इंजीनियरिंग, परियोजना प्रबंधन और व्यावसायिक प्रक्रियाओं में एक विरोधी पैटर्न एक आवर्ती समस्या के लिए एक सामान्य प्रतिक्रिया है जो आमतौर पर अप्रभावी होती है और अत्यधिक प्रतिकूल होने का जोखिम होता है।[1][2] कंप्यूटर प्रोग्रामर एंड्रयू कोएनिग (प्रोग्रामर) द्वारा 1995 में गढ़ा गया यह शब्द, डिज़ाइन पैटर्न (पुस्तक) नामक पुस्तक से प्रेरित था (जो सॉफ़्टवेयर विकास में कई डिज़ाइन पैटर्न पर प्रकाश डालता है जिसे इसके लेखक अत्यधिक विश्वसनीय और प्रभावी मानते हैं) और सबसे पहले जर्नल ऑफ़ ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में उनके लेख में प्रकाशित।[3] 1996 में ऑब्जेक्ट वर्ल्ड वेस्ट कॉन्फ्रेंस में माइकल एक्रोयड द्वारा प्रस्तुत एक और पेपर में भी विरोधी पैटर्न का दस्तावेजीकरण किया गया।[3]
हालाँकि, 1998 की पुस्तक एंटीपैटर्न्स ने इस विचार को लोकप्रिय बनाया और सॉफ्टवेयर आर्किटेक्चर और प्रोजेक्ट प्रबंधन को शामिल करने के लिए सॉफ्टवेयर डिजाइन के क्षेत्र से परे इसका दायरा बढ़ाया।[3] अन्य लेखकों ने पर्यावरण/संगठनात्मक/सांस्कृतिक विरोधी पैटर्न को शामिल करने के लिए इसे और आगे बढ़ाया है।[4]
परिभाषा
डिज़ाइन पैटर्न के लेखकों के अनुसार, एंटी-पैटर्न में दो प्रमुख तत्व होते हैं जो इसे एक बुरी आदत, बुरे अभ्यास या बुरे विचार से अलग करते हैं:
- एंटी-पैटर्न आमतौर पर इस्तेमाल की जाने वाली प्रक्रिया, संरचना या कार्रवाई का पैटर्न है, जो शुरू में किसी समस्या के लिए उचित और प्रभावी प्रतिक्रिया प्रतीत होने के बावजूद, अच्छे परिणामों की तुलना में अधिक बुरे परिणाम देता है।
- उस समस्या का एक और समाधान मौजूद है जिसे एंटी-पैटर्न संबोधित करने का प्रयास कर रहा है। यह समाधान प्रलेखित है, दोहराने योग्य है, और जहां विरोधी पैटर्न नहीं है वहां प्रभावी साबित हुआ है।
जो आमतौर पर उपयोग किया जाता है उसके लिए एक मार्गदर्शिका पैटर्न के समान तीन नियम हैं: एक विरोधी पैटर्न होने के लिए इसे कम से कम तीन बार घटित होते देखा जाना चाहिए।[5]
उपयोग
किसी समस्या स्थान का विश्लेषण करने और विशेषज्ञ ज्ञान प्राप्त करने के लिए विरोधी पैटर्न का दस्तावेजीकरण एक प्रभावी तरीका हो सकता है।[6]
जबकि कुछ एंटी-पैटर्न विवरण केवल पैटर्न के प्रतिकूल परिणामों का दस्तावेजीकरण करते हैं, अच्छा एंटी-पैटर्न दस्तावेज़ीकरण एंटी-पैटर्न को सुधारने का एक विकल्प या साधन भी प्रदान करता है।[7]
सॉफ्टवेयर इंजीनियरिंग विरोधी पैटर्न
सॉफ़्टवेयर इंजीनियरिंग में, एंटी-पैटर्न में मिट्टी की बड़ी गेंद (कमी) डिज़ाइन शामिल है; भगवान आपत्ति (जहाँ एक एकल वर्ग (प्रोग्रामिंग) कई वर्गों में वितरित नियंत्रण के बजाय कंप्यूटर प्रोग्राम में सभी नियंत्रण संभालता है); और पोल्टरजिस्ट (क्षणिक नियंत्रक वर्ग जो केवल कक्षाओं पर अन्य तरीकों को लागू करने के लिए मौजूद हैं)।[7]
कीचड़ का बड़ा गोला
यह एक सॉफ्टवेयर प्रणाली को इंगित करता है जिसमें बोधगम्य वास्तुकला का अभाव है। हालाँकि सॉफ़्टवेयर इंजीनियरिंग के दृष्टिकोण से अवांछनीय है, व्यावसायिक दबाव, डेवलपर टर्नओवर (रोज़गार) और सॉफ्टवेयर एन्ट्रापी के कारण ऐसी प्रणालियाँ व्यवहार में आम हैं।
यह शब्द ब्रायन फूटे (कंप्यूटर वैज्ञानिक) और जोसेफ योडर के 1997 के इसी नाम के पेपर में लोकप्रिय हुआ, जो इस शब्द को परिभाषित करता है:
A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated.
The overall structure of the system may never have been well defined.
If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.
— Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on Patterns Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997
फूटे और योडर ने इस प्रकार की वास्तुकला के लिए 'मिट्टी की बड़ी गेंद' शब्द के प्रवर्तक के रूप में ब्रायन मैरिक को श्रेय दिया है।[8]
परियोजना प्रबंधन विरोधी पैटर्न
एंटीपैटर्न पुस्तक में शामिल परियोजना प्रबंधन विरोधी पैटर्न में ब्लोहार्ड जाम्बोरे (उद्योग पंडितों की अधिकता), विश्लेषण पक्षाघात, व्यूग्राफ इंजीनियरिंग (प्रस्तुतीकरण बनाने में बहुत अधिक समय और वास्तविक सॉफ्टवेयर पर पर्याप्त नहीं), डेथ बाय प्लानिंग (इसी तरह, बहुत अधिक) शामिल हैं योजना बनाना), सफलता का डर (परियोजना पूरी होने के निकट अतार्किक भय), द कॉर्नकोब (लोगों के साथ कठिनाइयाँ), बौद्धिक हिंसा (शब्दजाल या रहस्यमय प्रौद्योगिकी के उपयोग के माध्यम से डराना), अतार्किक प्रबंधन (बुरी प्रबंधन आदतें), धुआँ और दर्पण (अत्यधिक उपयोग) सेल्सपर्सन द्वारा डेमो और प्रोटोटाइप के), थ्रो इट ओवर द वॉल (बिना खरीद-फरोख्त के डेवलपर्स पर सनक सॉफ्टवेयर इंजीनियरिंग प्रथाओं को थोपना), फायर ड्रिल (छोटे संकटों के कारण लंबी अवधि की एकरसता), द फ्यूड (प्रबंधकों के बीच संघर्ष), और ई -मेल खतरनाक है (गलत सलाह वाले ई-मेल संदेशों से उत्पन्न स्थितियाँ)।[4]
यह भी देखें
- कोड गंध - ख़राब प्रोग्रामिंग का लक्षण
- डिज़ाइन गंध
- गहरा पैटर्न
- सॉफ्टवेयर विकास दर्शन की सूची - सॉफ्टवेयर विकास के लिए दृष्टिकोण, शैलियाँ, सिद्धांत और दर्शन
- स्थैतिक कोड विश्लेषण के लिए उपकरणों की सूची
- सॉफ्टवेयर सड़ गया
- सॉफ्टवेयर पीटर सिद्धांत
- क्षमता अपरिपक्वता मॉडल
- आईएसओ/आईईसी 29110: बहुत छोटी संस्थाओं (वीएसई) के लिए सॉफ्टवेयर जीवन चक्र प्रोफाइल और दिशानिर्देश
- इनोवेटर की दुविधा
संदर्भ
क्या समर्थन करता है
- ↑ Budgen 2003, p. 225.
- ↑ Ambler 1998, p. 4.
- ↑ 3.0 3.1 3.2 Neill, Laplante & DeFranco 2011, p. 4.
- ↑ 4.0 4.1 Neill, Laplante & DeFranco 2011, p. 5.
- ↑ Neill, Laplante & DeFranco 2011, p. 6.
- ↑ Jimenez 2006.
- ↑ 7.0 7.1 Demeyer 2008, p. 102.
- ↑ Foote, Brian; Yoder, Joseph (26 June 1999). "मिट्टी की बड़ी गेंद". laputan.org. Retrieved 14 April 2019.
स्रोत
- Neill, Colin J.; Laplante, Philip A.; DeFranco, Joanna F. (2011). एंटीपैटर्न: सॉफ्टवेयर संगठनों और लोगों का प्रबंधन. Applied Software Engineering Series (second ed.). CRC Press. ISBN 9781439862162.
- Budgen, D. (2003). सॉफ्टवेर डिज़ाइन. Harlow, Eng.: Addison-Wesley. p. 225. ISBN 0-201-72219-4.
जैसा कि लॉन्ग (2001) में बताया गया है, डिज़ाइन विरोधी पैटर्न 'स्पष्ट, लेकिन गलत, आवर्ती समस्याओं के समाधान' हैं।
- Ambler, Scott W. (1998). प्रक्रिया पैटर्न: ऑब्जेक्ट प्रौद्योगिकी का उपयोग करके बड़े पैमाने पर सिस्टम का निर्माण. Cambridge, UK: Cambridge University Press. p. 4. ISBN 0-521-64568-9.
...आवर्ती समस्याओं को हल करने के लिए सामान्य दृष्टिकोण जो अप्रभावी साबित होते हैं। इन दृष्टिकोणों को एंटीपैटर्न कहा जाता है।
- Jimenez, Edward (2006-04-24). "एंटीपैटर्न". एंटीपैटर्न. Retrieved 24 April 2006.
- Demeyer, Serge (2008). "ObjectOriented Reengineering". In Mens, Tom; Demeyer, Serge (eds.). सॉफ्टवेयर विकास. Springer Science + Business Media. ISBN 9783540764403.
अग्रिम पठन
- Koenig, Andrew (March–April 1995). "Patterns and Antipatterns". Journal of Object-Oriented Programming. 8 (1): 46–48.
- Later re-printed in: Rising, Linda (1998). The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press. p. 387. ISBN 0-521-64818-1.
An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution, but isn't one.
- Later re-printed in: Rising, Linda (1998). The patterns handbook: techniques, strategies, and applications. Cambridge, U.K.: Cambridge University Press. p. 387. ISBN 0-521-64818-1.
- Laplante, Phillip A.; Neill, Colin J. (2005). Antipatterns: Identification, Refactoring and Management. Auerbach Publications. ISBN 0-8493-2994-9.
- Brown, William J.; Malveau, Raphael C.; McCormick, Hays W.; Thomas, Scott W. (2000). Hudson, Theresa Hudson (ed.). Anti-Patterns in Project Management. John Wiley & Sons. ISBN 0-471-36366-9.
- Stamelos, Ioannis (January 2010). "Software project management anti-patterns". Journal of Systems and Software. 83 (1): 52–59. doi:10.1016/j.jss.2009.09.016.