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

• टीडीडी - ठीक है, हर कोई जानता है कि, पहले हम परीक्षण लिखते हैं, और फिर बाकी कोड।
• BDD कुछ परिचित है, जैसे परीक्षण भी, लेकिन विशेष।
• टीडीडी - फिर से? इसलिए, यहां रुकें, यह परीक्षणों के बारे में बिल्कुल नहीं है। लेकिन इसे ही क्यों कहा जाता है?
• DDD - बाध्य संदर्भ, सर्वव्यापी भाषा, डोमेन ...
• एफडीडी - हां, यह कितना संभव है?
• एमडीडी - गंभीरता से, चार्ट आधारित?
• पीडीडी - ...

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

हम सबसे सरल से सबसे जटिल से परिचित होना शुरू कर देंगे, उपयोग के उदाहरणों और उनमें से प्रत्येक के पेशेवरों और विपक्षों पर विचार करेंगे।

टीडीडी - टेस्ट ड्रिवेन डेवलपमेंट

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

यह सरल और स्पष्ट लगता है। कई लोग विकास के इस दृष्टिकोण से परिचित हैं, और यहां तक ​​कि अंकल बॉब भी इसे सक्रिय रूप से बढ़ावा दे रहे हैं।

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

जब आप टीडीडी का उपयोग शुरू करते हैं, तो आप महसूस कर सकते हैं कि आप सामान्य से अधिक धीमी गति से चल रहे हैं। ऐसा इसलिए है क्योंकि आप "कम्फ़र्ट ज़ोन" के बाहर काम करेंगे, और यह बिल्कुल सामान्य है।

एक बार जब आपको लगता है कि लेखन परीक्षण वर्कफ़्लो का एक सरल और प्राकृतिक हिस्सा बन गया है, तो आपको अब प्रोजेक्ट पर काम करते समय टीडीडी का उपयोग करने के बारे में सोचने की ज़रूरत नहीं है, आपको पता है कि टीडीडी आपके काम में बह गया है।

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

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

आप कैंट बेक की किताब एक्सट्रीम प्रोग्रामिंग; टेस्टिंग के जरिए डेवलपमेंट पढ़कर टीडीडी सिद्धांतों के बारे में अधिक जान सकते हैं।

टीडीडी - प्रकार प्रेरित विकास

टाइप डेवलप्ड डेवलपमेंट को संक्षिप्त रूप में टेस्टिंग के माध्यम से डेवलप किया जाता है, इसलिए आमतौर पर पूरा नाम लिखा जाता है।

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

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

प्रकार का विकास एक आवेदन के निर्माण के लिए एक और अच्छी विधि है परीक्षण-आधारित विकास के साथ, प्रकार-आधारित विकास आपके कोड में आपका विश्वास बढ़ा सकता है और बड़े कोड आधार में परिवर्तन करते समय आपका समय बचा सकता है।

गतिशील टाइपिंग के साथ भाषाओं की केवल बढ़ती हुई जटिलता। उदाहरण के लिए, जावास्क्रिप्ट के लिए यह दृष्टिकोण टाइपस्क्रिप्ट के लिए लागू करने के लिए कठिन है।

हाइब्रिड पर टाइपिंग के बारे में एक उत्कृष्ट लेख है।

बीडीडी - व्यवहार प्रेरित विकास

कुछ पद्धतिगत समानता के कारण, TDD (टेस्ट ड्रिवेन डेवलपमेंट) और BDD (बिहेवियर ड्रिवेन डेवलपमेंट) अक्सर पेशेवरों द्वारा भी भ्रमित होते हैं। अंतर क्या है? दोनों दृष्टिकोणों की अवधारणाएं समान हैं, पहले परीक्षण किए जाते हैं और उसके बाद ही विकास शुरू होता है, लेकिन उनका उद्देश्य पूरी तरह से अलग है। टीडीडी उत्पाद के तकनीकी कार्यान्वयन स्तर पर प्रोग्रामिंग और परीक्षण के बारे में अधिक है, जब परीक्षण स्वयं डेवलपर्स द्वारा बनाए जाते हैं। BDD में एक परीक्षक या विश्लेषक शामिल होता है जो एक प्राकृतिक भाषा में उपयोगकर्ता-परिभाषित स्क्रिप्ट का वर्णन करता है - अगर मैं ऐसा कह सकता हूं, तो व्यवसाय की भाषा में।

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

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

स्क्रिप्ट ग्रंथ एक विशिष्ट रूप में लिखे गए हैं।

कुछ सन्दर्भ,

जब (जब नोट) एक घटना होती है,

फिर (लगभग। तब) परिणाम की जांच करें।

ऐसा कुछ हो सकता है:

या रूसी में एक और उदाहरण:

दृश्य 1: खाते में धन है +

पैसे वाला खाता

और एक वैध कार्ड

और नकदी के साथ एक एटीएम

जब कोई ग्राहक नकद का अनुरोध करता है

फिर सुनिश्चित करें कि खाता डेबिट हो गया था

और सुनिश्चित करें कि नकदी जारी की गई है

और सुनिश्चित करें कि कार्ड वापस आ गया है

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

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

बीडीडी का क्या फायदा है?

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

विपक्ष:

लेकिन इस दृष्टिकोण की अपनी कमियां हैं - यह लंबी और महंगी है। BDD असुविधाजनक है भले ही इसके लिए विकासशील आवश्यकताओं के चरण में पहले से ही परीक्षण विशेषज्ञों की भागीदारी की आवश्यकता हो, और यह विकास चक्र को लंबा करता है।

इस स्थिति से बाहर का रास्ता एक उपयुक्त बीडीडी ढांचे और ठीक से निर्मित विकास प्रक्रियाओं का विकल्प हो सकता है।

बीडीडी के बारे में और अधिक पढ़ें।

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

DDD - डोमेन संचालित डिज़ाइन

विषय-उन्मुख डिजाइन एक विशिष्ट तकनीक या कार्यप्रणाली नहीं है। डीडीडी नियमों का एक सेट है जो आपको सही डिजाइन निर्णय लेने की अनुमति देता है। यह दृष्टिकोण अपरिचित डोमेन में सॉफ़्टवेयर डिज़ाइन करने की प्रक्रिया को महत्वपूर्ण रूप से तेज कर सकता है।

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

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

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

डोमेन-चालित डिजाइन का मुख्य लक्ष्य व्यवसाय प्रक्रियाओं की जटिलता, उनके स्वचालन और कोड में कार्यान्वयन का मुकाबला करना है। "डोमेन" का अनुवाद "डोमेन" के रूप में किया जाता है, और इस दृष्टिकोण के ढांचे के भीतर विकास और डिजाइन को डोमेन से दूर धकेल दिया जाता है।

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

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

उदाहरण: इकाई "व्यक्ति" को लें और इसे "सार्वजनिक बोलने" के संदर्भ में रखें। इस संदर्भ में, डीडीडी के अनुसार, वह एक वक्ता या वक्ता बन जाता है। और "परिवार" के संदर्भ में - एक पति या भाई।

अब कोड के बारे में। यह महत्वपूर्ण है कि आपका कोड एक किताब की तरह पढ़ा जाए, यह सरल और समझने योग्य है जो परियोजना की आम भाषा बोलता है। मेरा क्या मतलब है?

यदि प्रोजेक्ट भाषा में आप "उत्पाद जोड़ा गया है" अभिव्यक्ति का उपयोग करते हैं, तो निम्न विकल्प DDD नहीं है:

var उत्पाद = नया उत्पाद ('सेब')

product.save ()

क्यों? कोड कहता है कि हमने एक अजीब तरीके से उत्पाद बनाया और इसे बचाया। कैसे एक उत्पाद को एक ही जोड़ने के लिए? इसे जोड़ने की जरूरत है। यहाँ डीडीडी कोड है:

उत्पाद :: जोड़ ('सेब');

वास्तुकला:

Domain-Driven Design के दृष्टिकोण से, यह वास्तव में कोई फर्क नहीं पड़ता कि आप किस आर्किटेक्चर को चुनते हैं। Domain-Driven Design इसके बारे में नहीं है; Domain-Driven Design भाषा और संचार के बारे में है।

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

डीडीडी के बारे में लेख भी हैं जिन्हें मैं ध्यान से पढ़ने की सलाह देता हूं - यहां और यहां ।

यह आखिर में हमें क्या देता है:

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

विपक्ष:

• विशेष रूप से परियोजना की शुरुआत में उच्च योग्य डेवलपर्स की आवश्यकता होती है;
• सभी ग्राहक ऐसी लागतों के लिए तैयार नहीं हैं, डीडीडी को विकास प्रक्रिया में सभी प्रतिभागियों द्वारा अध्ययन किए जाने की आवश्यकता है।

FDD - सुविधाएँ संचालित विकास

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

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

• एक सामान्य मॉडल का विकास;
• आवश्यक सिस्टम गुणों की सूची संकलित करना;
• प्रत्येक संपत्ति पर नियोजन कार्य;
• प्रत्येक संपत्ति का डिजाइन;
• प्रत्येक संपत्ति का निर्माण।

प्रत्येक पुनरावृत्ति के दौरान अंतिम दो चरण होने चाहिए। इसके अलावा, प्रत्येक प्रक्रिया को कार्यों में विभाजित किया गया है और सत्यापन मानदंड हैं।

आइए प्रत्येक वस्तु पर अधिक विस्तार से ध्यान दें।

एक सामान्य मॉडल का विकास।

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

लिस्टिंग की विशेषताएं

सामान्य मॉडल के निर्माण के दौरान एकत्र की गई जानकारी का उपयोग कार्यों की सूची संकलित करने के लिए किया जाता है। कार्यों को तथाकथित "डोमेन" (अंग्रेजी डोमेन) में जोड़ा जाता है, और वे, एक कार्यात्मक विशेषता के अनुसार, उप-क्षेत्रों (अंग्रेजी विषय क्षेत्रों) में विभाजित होते हैं।

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

गुण (कार्य) योजना

अगला चरण अग्रणी प्रोग्रामर या टीमों के बीच कार्यों का वितरण है।

फ़ीचर डिज़ाइन

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

समारोह कार्यान्वयन

हम कोड लिखते हैं, स्टब्स को हटाते हैं, परीक्षण करते हैं।

संपत्ति के परीक्षण और उत्पाद में चले जाने के बाद, हम अगली प्राथमिकता संपत्ति लेते हैं, डिजाइन / कार्यान्वयन चक्र दोहराते हैं।

कुल मिलाकर, परिणाम के रूप में:

• सिस्टम गुण प्रलेखन;
• सावधान डिजाइन;
• छोटे कार्यों का मूल्यांकन करना आसान;
• परीक्षण व्यावसायिक कार्यों पर केंद्रित हैं;
• परिष्कृत उत्पाद निर्माण प्रक्रिया;
• लघु पुनरावृत्ति विकास चक्र आपको कार्यक्षमता को जल्दी से बढ़ाने और त्रुटियों को कम करने की अनुमति देता है।

विपक्ष:

• एफडीडी बड़ी परियोजनाओं के लिए अधिक उपयुक्त है। छोटे विकास दल इस दृष्टिकोण के सभी लाभों का अनुभव नहीं कर पाएंगे;
• महत्वपूर्ण कार्यान्वयन और प्रशिक्षण लागत।

एमडीडी - मॉडल संचालित विकास

हाल ही में, प्रकाशनों पर बहुत ध्यान दिया गया है जो कि एमडीए (मॉडल ड्रिवेन आर्किटेक्चर) और एमडीडी (मॉडल ड्रिवेन डेवलपमेंट) मॉडल पर आधारित वास्तुकला और विकास के विषय पर आधारित है। विवरण में जाने के बिना, हम केवल मुख्य बिंदुओं को उजागर करते हैं।

मॉडल-संचालित विकास सॉफ्टवेयर विकास की एक शैली है जहां मॉडल मुख्य विकास कलाकृतियों बन जाते हैं जहां से कोड और अन्य कलाकृतियां उत्पन्न होती हैं।

, , .

MDD — , . - .

. . , , . MDD — , , .

«», . ( ).

MDD ‑ . , , . MDD-, . Unified Modeling Language – UML 2.0.

Object Management Group (OMG) :

• c , ;
• - ;
• , .

MDD, , — . .

:

• (Minimum Viable Product) ;
• : , , ;
• ;
• .

:

• MMD , Rational Software Architect, Simulink Sirius;
• ;
• .

PDD — Panic Driven Development

agile , PDD. , .

.

, , . . , ? , .

, , .

. . UX . ? , . , .

.

, , , . , . . , .

.

— . . . . . .

.

, , , — , . . , , , .

, .

, . . , , .

:

• ;
• ;
• , - .

:

• .

PDD , , , .

निष्कर्ष

agile . , , .

मुझे आशा है कि आप में से कई ने प्रेरित विकास प्रथाओं के बारे में कुछ नया सीखा है, और अब, संक्षिप्तीकरण DDD, BDD, MDD के साथ आमने-सामने होने से, आपको भ्रम का अनुभव नहीं होगा, या आप उन्हें व्यवहार में आज़माना भी चाह सकते हैं।