परीक्षण-संचालित विकास प्रक्रिया में एक सॉफ्टवेयर आर्किटेक्ट की भूमिका क्या है?

Question

जैसा कि मैं इसे समझता हूं, टेस्ट-ड्रिवेन डेवलपमेंट प्रोग्राम स्पेसिफिकेशन को परिभाषित करने के लिए टेस्ट लिखने के बारे में है (यदि मैं गलत हूं तो आप मुझे सही कर सकते हैं)।

यदि सॉफ्टवेयर के लिए विशिष्टताओं (सार्वजनिक एपीआई सहित) को लिखने के लिए कोई जिम्मेदार है (चलो उसे सॉफ्टवेयर आर्किटेक्ट कहते हैं), तो क्या इसका मतलब है कि सॉफ्टवेयर आर्किटेक्ट को सभी परीक्षणों को लिखना होगा?

या क्या सॉफ्टवेयर आर्किटेक्ट विनिर्देशों को लिखते हैं, और फिर उन्हें डेवलपर्स के खिलाफ परीक्षण लिखने के लिए सौंप देते हैं?

या क्या आप सभी डेवलपर्स को अपने स्वयं के परीक्षण लिखने की अनुमति देकर विशिष्ट रूप से विकसित होने की अनुमति देते हैं, और एक सॉफ्टवेयर आर्किटेक्ट होने के बारे में भूल जाते हैं?

Comments

"संगठित रूप से बढ़ने" से आपका क्या अर्थ है, इस पर english.se पर कुछ बहस हुई है - english.stackexchange.com/questions/17853/… - क्या आप इसकी पुष्टि करना चाहेंगे :)

— जोश

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

— रॉबर्ट हार्वे

Answer 1

टेस्ट-प्रेरित विकास कार्यक्रम विनिर्देशों को परिभाषित करने के लिए परीक्षण लिखने के बारे में है

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

समीक्षा करने के लिए, संक्षेप में TDD प्रक्रिया है:

• सुविधाओं के संदर्भ में एक परियोजना को परिभाषित करें
• उपयोगकर्ता कहानियों का उपयोग करके प्रत्येक सुविधा के हितधारक, व्यवहार और लक्ष्य का वर्णन करें
• परीक्षण विवरणों का उपयोग करके उपयोगकर्ता की कहानी से जुड़े अपेक्षित गिवेंस, ट्रिगरिंग इवेंट्स / शर्तों और व्यवहार / परिणामों को निर्दिष्ट करें [और यह 'विनिर्देश' को पूरा करता है]
• प्रत्येक पुनरावृत्ति के लिए सुविधाओं का एक सेट चुनें; पुनरावृत्तियों संक्षिप्त होना चाहिए [मैं योजना और अनुमान चरणों को छोड़ रहा हूं]
  • एक सुविधा के लिए एक परीक्षण कोड (यह विफल हो जाएगा, लेकिन आपको परीक्षण को कोड करने के लिए एपीआई निर्णय लेना था)
  • पर्याप्त सुविधा लागू करें ताकि परीक्षण पास हो जाए
  • यदि आवश्यक हो तो कोड को रिफलेक्टर करें
  • फीचर पूरा होने तक अगले टेस्ट के साथ दोहराएं
  • पुनरावृत्ति पूर्ण होने तक अगली विशेषता के साथ दोहराएं
• प्रोजेक्ट पूरा होने तक अगले पुनरावृत्ति के साथ दोहराएं

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

ध्यान दें कि बिंदु ग्राहक और डेवलपर के लिए सुविधाओं के साथ आने के लिए है और आपसी समझ के लिए कहानियां और परीक्षण विवरण एक साथ लिखें।

इसलिए, इस तरह से, मूल प्रश्न यह था:

TDD में एक सॉफ्टवेयर आर्किटेक्ट की भूमिका क्या है?

और संक्षिप्त उत्तर है:

जैसा कभी था, वैसा ही आज भी है। - डेविड बायर्न

---

संपादित करें: लंबा उत्तर है: आर्किटेक्ट पूरी प्रक्रिया के दौरान सामान्य दूरदर्शी / अन्वेषक / चिड़चिड़ाहट / समर्थन / बैकस्टॉप भूमिका निभाता है, आवश्यकतानुसार।

संपादित 2: क्षमा करें, मैं उप-सवालों के बिंदु से चूक गया! विनिर्देशों को लिखने के लिए हर कोई जिम्मेदार है; अगर उचित / ग्राहक हो तो आर्किटेक्ट सहित सभी डेवलपर । डेवलपर्स भी परीक्षणों को कोड करते हैं।

Comments

यह समझ में आता है, लेकिन मैंने केवल सुना है कि लोगों ने टीडीडी के संदर्भ में अपनी पांच गोलियों के अंदर पांच चरण (लाल-हरी-परावर्तक प्रक्रिया का वर्णन करते हुए) के पांच चरण हैं। क्या बची हुई गोलियां वास्तव में टीडीडी का हिस्सा हैं या वे फुर्तीली या डीडीडी जैसी कुछ बड़ी व्यापक कार्यप्रणाली का हिस्सा हैं?

— रॉबर्ट हार्वे

@ रोबर्ट हम्म ... अच्छा सवाल! तकनीकी रूप से अन्य बुलेट एक्सपी होंगे; मैंने एक ही समय में XP और TDD सीखे और उन्हें अलग करने के लिए कभी नहीं सोचा। अब तक ;-)

— स्टीवन ए। लोव

@ रोबर्ट ने कुछ रिफ्रेशर रीडिंग की; संपादन देखें (FYI करें XP रेफरी का उपयोग करते हुए extremeprogramming.org और TDD Ref agiledata.org/essays/tdd.html#WhatIsTDD )

— स्टीवन ए। लोवे

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

— रॉबर्ट हार्वे

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

— स्टीवन ए। लोव

Answer 2

सॉफ्टवेयर आर्किटेक्ट सभी परीक्षण नहीं लिख रहा है। यह मेरे दिमाग में एक व्यक्ति के कंधों पर बहुत अधिक होगा।

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

निश्चित रूप से ऐसे मामले हो सकते हैं जहां कोई टीम सॉफ्टवेयर आर्किटेक्ट न होने का फैसला कर सकती है, लेकिन इसमें शामिल एपीआई और कंपनी के पैमाने के आधार पर यह एक अच्छा विचार हो सकता है या नहीं भी हो सकता है।