क्या यह परीक्षण संचालित विकास (और सामान्य रूप से फुर्तीली) की सीमा व्यावहारिक रूप से प्रासंगिक है?


30

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

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

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

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


क्या आप टीडीडी उप-तकनीक का उल्लेख कर रहे हैं जिसे त्रिकोणासन कहा जाता है ? "स्वीकार्य समाधान" से, क्या आपका मतलब एक सही है या एक अनुरक्षण / सुरुचिपूर्ण / पठनीय है?
गुरिल्ला

6
मुझे लगता है कि यह एक वास्तविक समस्या है। चूंकि यह सिर्फ मेरी राय है, मैं कोई जवाब नहीं लिखूंगा। लेकिन हाँ, चूंकि टीडीडी को एक डिज़ाइन प्रथा के रूप में जाना जाता है , यह एक दोष है कि इससे स्थानीय मैक्सिमा या कोई समाधान नहीं हो सकता है। मैं कहता हूँ कि सामान्य TDD एल्गोरिथम डिजाइन के लिए अच्छी तरह से अनुकूल नहीं है। TDD की सीमाओं पर संबंधित चर्चा देखें: TDD के साथ सुडोकू को हल करना , जिसमें रॉन जेफ्रीस सर्किल में दौड़ते हुए और "TDD" करते हुए खुद को एक गधा बनाता है, जबकि पीटर नॉरविग वास्तव में विषय वस्तु के बारे में जानकर वास्तविक समाधान प्रदान करता है,
एंड्रेस एफ।

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

2
समस्या मौजूद है, लेकिन टीडीडी या एजाइल तक सीमित नहीं है। बदलती जरूरतों का मतलब है कि पहले से लिखे सॉफ्टवेयर के डिजाइन को हर समय बदलना होगा।
रेमकोगर्लिच

@ guillaume31: स्रोत कोड स्तर पर पुनरावृत्तियों का उपयोग करते हुए कोई भी त्रिकोणीय रूप से नहीं, बल्कि किसी भी तकनीक। स्वीकार्य समाधान से मेरा तात्पर्य है कि सभी परीक्षाओं को उत्तीर्ण करना और यथोचित रूप से बनाए रखा जा सकता है ..
फ्रैंक पफ़र

जवाबों:


8

इस तरह के तरीकों की एक प्रसिद्ध सीमा यह है कि वे वैश्विक इष्टतम, या यहां तक ​​कि स्वीकार्य स्थानीय इष्टतम को खोजने की गारंटी नहीं देते हैं।

अपनी तुलना को अधिक पर्याप्त बनाने के लिए: कुछ प्रकार की समस्याओं के लिए, पुनरावृत्ति अनुकूलन एल्गोरिदम बहुत अच्छे स्थानीय ऑप्टिमा का उत्पादन करने की संभावना रखते हैं, कुछ अन्य स्थितियों के लिए, वे विफल हो सकते हैं।

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

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

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

रॉबर्ट हार्वे का हवाला देते हुए: "आप इकाई परीक्षणों से एक वास्तुकला विकसित नहीं कर सकते।" या पीडीआर: "टीडीडी मुझे केवल सर्वश्रेष्ठ अंतिम डिजाइन में आने में मदद नहीं करता है, इससे मुझे कम प्रयासों में मदद मिलती है।"

तो वास्तव में आपने जो लिखा है

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

सच हो सकता है - जब आप एक गलत वास्तुकला चुनते हैं, तो आपको वहां से आवश्यक समाधान तक नहीं पहुंचने की संभावना है।

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


20

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

यदि आप TDD से संबंधित समस्याओं में रुचि रखते हैं तो मैं तीन अलग-अलग लोगों का उल्लेख कर सकता हूं जिनके बारे में मैं अक्सर सोचता हूं:

  1. पूर्णता समस्या: कितने परीक्षण पूरी तरह से एक प्रणाली का वर्णन करने के लिए आवश्यक हैं? "उदाहरण के मामलों द्वारा कोडिंग" एक प्रणाली का वर्णन करने का एक पूरा तरीका है?

  2. सख्त समस्या: जो कुछ भी करने के लिए इंटरफ़ेस का परीक्षण करती है, एक अपरिवर्तनीय इंटरफेस की जरूरत है। टेस्ट , अपरिवर्तनीय सच्चाइयों का प्रतिनिधित्व करते हैं , याद रखें। दुर्भाग्य से ये सत्य हमारे द्वारा लिखे गए अधिकांश कोड के लिए बिल्कुल भी ज्ञात नहीं हैं, केवल बाहरी सामना करने वाली वस्तुओं के लिए।

  3. परीक्षण क्षति समस्या: आदेश दावे परीक्षण योग्य बनाने के लिए, हम लिखने से इनकी कोड के लिए (कम performant, उदाहरण के लिए) की आवश्यकता हो सकती। हम परीक्षण कैसे लिखते हैं ताकि कोड उतना अच्छा हो जितना यह हो सकता है?


एक टिप्पणी को संबोधित करने के लिए संपादित: यहां एक "डबल" फ़ंक्शन के लिए एक स्थानीय अधिकतम को वापस लाने का एक उदाहरण है, जो कि रिफैक्टिंग के माध्यम से है

परीक्षण 1: जब इनपुट 0 है, तो शून्य लौटें

कार्यान्वयन:

function double(x) {
  return 0; // simplest possible code that passes tests
}

Refactoring: जरूरत नहीं है

टेस्ट 2: जब इनपुट 1 है, तो 2 वापस करें

कार्यान्वयन:

function double(x) {
  return x==0?0:2; // local maximum
}

Refactoring: जरूरत नहीं है

टेस्ट 3: जब इनपुट 2 है, तो 4 वापस करें

कार्यान्वयन:

function double(x) {
  return x==0?0:x==2?4:2; // needs refactoring
}

पुनर्रचना:

function double(x) {
  return x*2; // new maximum
}

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

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

2
@Sklivvz समझ में आया, लेकिन मुझे नहीं लगता कि यह आपके द्वारा पोस्ट किए गए खिलौनों के बाहर उस तरह से काम करता है। इसके अलावा, इससे आपको मदद मिली कि आपके फ़ंक्शन को "डबल" नाम दिया गया था; एक तरह से आप पहले से ही जवाब जानते थे। टीडीडी निश्चित रूप से मदद करता है जब आप अधिक या कम उत्तर जानते हैं, लेकिन इसे "सफाई से" लिखना चाहते हैं। यह एल्गोरिदम की खोज करने या वास्तव में जटिल कोड लिखने में मदद नहीं करेगा। यही कारण है कि रॉन जेफ़री इस तरह सुडोकू को हल करने में विफल रहे; आप एक एल्गोरिथ्म को लागू नहीं कर सकते हैं जो आप TDD'ing द्वारा अपरिचित से अपरिचित हैं।
एंड्रेस एफ।

1
@VaughnCato ठीक है, अब मैं या तो आप पर भरोसा करने या संदेहपूर्ण होने की स्थिति में हूं (जो असभ्य होगा, तो चलो ऐसा नहीं करते हैं)। चलो बस, मेरे अनुभव में, यह आपके कहे अनुसार काम नहीं करता है। मैंने कभी टीडीडी से विकसित एक जटिल जटिल एल्गोरिथ्म नहीं देखा है। शायद मेरा अनुभव बहुत सीमित है :)
एंड्रेस एफ।

2
@Sklivvz "जब तक आप उपयुक्त परीक्षण लिख सकते हैं" ठीक यही बात है: यह मेरे लिए प्रश्न को भीख देने जैसा लगता है। जो मैं कह रहा हूं वह यह है कि आप अक्सर नहीं कर सकते । एक एल्गोरिथ्म या एक सॉल्वर के बारे में सोचना पहले परीक्षण लिखकर आसान नहीं बनाया जाता है । आपको पहले पूरी तस्वीर देखनी होगी । परिदृश्यों की कोशिश करना आवश्यक है, लेकिन ध्यान दें कि TDD परिदृश्य लिखने के बारे में नहीं है: TDD डिजाइन के परीक्षण के बारे में है ! पहले परीक्षण लिखकर आप सुडोकू सॉल्वर (या किसी अलग खेल के लिए एक नया सॉल्वर) का डिज़ाइन नहीं चला सकते। उपाख्यानों के प्रमाण के रूप में (जो पर्याप्त नहीं है): जेफ्रीस नहीं कर सका।
एंड्रेस एफ।

13

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

अंतर एक फुर्तीले माहौल में है, जिसे आपने कभी भी इस बिंदु पर सही होने की उम्मीद नहीं की है, इसलिए आप पुराने विचार को टॉस करने के लिए तैयार हैं और नए विचार पर जाएं।

टीडीडी के लिए और अधिक विशिष्ट वहाँ एक तकनीक है जो आप से हो रही है क्योंकि आप टीडीडी के तहत सुविधाएँ जोड़ते हैं। यह परिवर्तन की प्राथमिकता है । जहां TDD आपके पास रिफ्लेक्टर के लिए एक औपचारिक तरीका है, यह सुविधाओं को जोड़ने का एक औपचारिक तरीका है।


13

में अपने जवाब , @Sklivvz आसानी से तर्क दिया है कि समस्या मौजूद नहीं है।

मैं यह तर्क देना चाहता हूं कि यह कोई मायने नहीं रखता है: सामान्य रूप से और विशेष रूप से और विशेष रूप से TDD में पुनरावृत्तियों के मूल आधार (और raison d'être), यह है कि न केवल वैश्विक इष्टतम, बल्कि स्थानीय रूप में अच्छी तरह से किया गया है '। टी ज्ञात तो, दूसरे शब्दों में: भले ही यह एक समस्या थी, फिर भी इसे पुनरावृत्ति करने का कोई रास्ता नहीं है। यह मानते हुए कि आप मूल आधार को स्वीकार करते हैं।


8

क्या TDD और एजाइल प्रैक्टिस एक इष्टतम समाधान का वादा कर सकते हैं? (या एक "अच्छा" समाधान भी?)

बिल्कुल नहीं। लेकिन, यह उनका उद्देश्य नहीं है।

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

... [TDD] सॉफ्टवेयर डेवलपमेंट के विरोध में है, जो ऐसे सॉफ्टवेयर को जोड़ने की अनुमति देता है जो आवश्यकताओं को पूरा करने के लिए सिद्ध नहीं होता है ... केंट बेक, जिसे विकसित होने या 'रिडिजर्व किए गए' तकनीक का श्रेय दिया जाता है, ने कहा कि TDD सिंपल को प्रोत्साहित करता है डिजाइन और आत्मविश्वास को प्रेरित करता है। ( विकिपीडिया )

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

चुस्त प्रक्रियाओं के लिए:

कार्य सॉफ्टवेयर प्रगति का प्राथमिक उपाय है ... प्रत्येक पुनरावृत्ति के अंत में, हितधारकों और ग्राहक प्रतिनिधि प्रगति की समीक्षा करते हैं और निवेश पर वापसी को अनुकूलित करने की दृष्टि से प्राथमिकताओं का मूल्यांकन करते हैं ( विकिपीडिया )

चपलता एक इष्टतम समाधान की तलाश में नहीं है ; आरओआई को अनुकूलित करने के इरादे से - बस एक काम कर समाधान । यह बाद में के बजाय जल्द ही काम कर समाधान का वादा करता है ; एक "इष्टतम" एक नहीं।

लेकिन, यह ठीक है, क्योंकि सवाल गलत है।

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

बहुत कम में, TDD और चंचल प्रथाओं कठिनाइयों स्वीकार करते हैं और दो चीजें हैं जो के लिए अनुकूलन करने का प्रयास कर रहे हैं उद्देश्य और औसत दर्जे का: । वर्किंग वी नहीं-कार्य और जल्द ही वी बाद में।।

और, भले ही हम उद्देश्य मैट्रिक्स के रूप में "काम कर रहे" और "जल्दी" हो, उनके लिए आपके अनुकूलन की क्षमता मुख्य रूप से एक टीम के कौशल और अनुभव पर आकस्मिक है।


जिन चीज़ों पर आप प्रयास कर सकते हैं, वे इष्टतम समाधान पैदा करती हैं, जैसे चीज़ें शामिल हैं:

आदि..

क्या उन चीजों में से प्रत्येक वास्तव में इष्टतम समाधान पैदा करता है, यह पूछने के लिए एक और महान सवाल होगा!


1
यह सच है, लेकिन मैंने यह नहीं लिखा कि टीडीडी या किसी अन्य सॉफ्टवेयर डेवलपमेंट विधि का लक्ष्य वैश्विक इष्टतम के रूप में एक इष्टतम समाधान है। मेरी एकमात्र चिंता यह है कि स्रोत कोड स्तर पर छोटे पुनरावृत्तियों पर आधारित कार्यप्रणाली को कई मामलों में कोई स्वीकार्य (पर्याप्त) समाधान नहीं मिल सकता है
फ्रैंक फफ़र

@Frank मेरा उत्तर स्थानीय और वैश्विक दोनों प्रकार के अनुकूलन को कवर करने के लिए है। और इसका उत्तर यह है कि "नहीं, यह नहीं है कि इन रणनीतियों के लिए क्या डिज़ाइन किया गया है - वे ROI को बेहतर बनाने और जोखिम को कम करने के लिए डिज़ाइन किए गए हैं।" ... या कुछ इस तरह का। और आंशिक रूप से जोर्ग के जवाब पर क्या हो रहा है, इसके कारण: "ऑप्टिमम" लक्ष्य को आगे बढ़ा रहे हैं। ... मैं इसे एक कदम आगे भी ले जाऊंगा; न केवल वे लक्ष्य ले रहे हैं, लेकिन, वे पूरी तरह से उद्देश्य या औसत दर्जे का नहीं हैं।
svidgen

@FrankPuffer शायद यह एक परिशिष्ट के लायक है। लेकिन, मूल बिंदु यह है कि आप पूछ रहे हैं कि क्या इन दोनों चीजों से कुछ हासिल होता है जिसे वे डिजाइन नहीं करते हैं या हासिल करने का इरादा रखते हैं। इसके अतिरिक्त, आप पूछ रहे हैं कि क्या वे कुछ ऐसा हासिल कर सकते हैं जिसे मापा या सत्यापित नहीं किया जा सकता है।
21

@FrankPuffer बाह। मैंने इसे बेहतर कहने के लिए अपने उत्तर को अपडेट करने की कोशिश की। मुझे यकीन नहीं है कि मैंने इसे बेहतर या बदतर बना दिया है! ... लेकिन, मुझे एसईएसई से बाहर निकलने और काम पर वापस जाने की आवश्यकता है।
22

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

4

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

वास्तविक दुनिया में आपके परीक्षण मूल रूप से व्यावसायिक नियमों का प्रयोग और सत्यापन करते हैं:

उदाहरण के लिए - यदि कोई ग्राहक पत्नी और दो बच्चों के साथ 30 साल का गैर-धूम्रपान करने वाला है तो प्रीमियम श्रेणी "x" आदि है।

जब तक यह बहुत लंबे समय के लिए सही नहीं हो जाता है - तब तक आप प्रीमियम गणना इंजन को बदलने नहीं जा रहे हैं - और लगभग निश्चित रूप से नहीं है जबकि एप्लिकेशन लाइव है;)।

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


1
सबसे पहले, जब मैंने आपका उत्तर पढ़ा, तो मैंने सोचा कि "हाँ, यह मुख्य बिंदु है"। लेकिन फिर से सवाल पर पुनर्विचार करने के बाद, मैंने सोचा कि जरूरी नहीं कि यह इतना सार या अवास्तविक हो। यदि कोई आँख बंद करके पूरी तरह से गलत आर्किटेक्चर चुनता है, तो TDD हल नहीं करेगा, 1000 पुनरावृत्तियों के बाद नहीं।
डॉक ब्राउन

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

जब मैं "गलत आर्किटेक्चर" कहता हूं, तो मेरे दिमाग में ऐसे मामले आते हैं जिनमें किसी को मौजूदा टेस्ट सूट को फेंकना पड़ता है। क्या आपने मेरा जवाब पढ़ा?
डॉक्टर ब्राउन

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

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

3

मुझे नहीं लगता कि यह रास्ते में हो जाता है। अधिकांश टीमों के पास कोई भी ऐसा व्यक्ति नहीं है जो एक इष्टतम समाधान के साथ आने में सक्षम हो, भले ही आपने इसे अपने व्हाइटबोर्ड पर लिखा हो। TDD / Agile उनके रास्ते में नहीं आएगा।

कई परियोजनाओं को इष्टतम समाधान की आवश्यकता नहीं होती है और जो इस क्षेत्र में आवश्यक समय, ऊर्जा और ध्यान केंद्रित करती हैं। बाकी सब चीजों की तरह, हम इसका निर्माण करते हैं, पहले इसे काम करते हैं। फिर इसे जल्दी करें। आप इसे किसी प्रकार के प्रोटोटाइप के साथ कर सकते हैं यदि प्रदर्शन महत्वपूर्ण है और फिर कई पुनरावृत्तियों के माध्यम से प्राप्त ज्ञान के साथ पूरी चीज़ का पुनर्निर्माण करें।

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

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

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


0

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

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


लेकिन क्या यह बहुत मजबूत प्रतिक्रिया थी? यह निश्चित रूप से बहुत सारे मामलों में मदद करता है जहां सख्त अग्रिम योजना अनिर्दिष्ट और महंगी साबित हुई। हालाँकि, कुछ सॉफ़्टवेयर समस्याओं को गणितीय समस्या और अपफ्रंट डिज़ाइन के साथ सामना करना होगा। आप उन्हें टीडीडी नहीं कर सकते। आप UI और फ़ोटोशॉप के समग्र डिज़ाइन को टीडीडी कर सकते हैं, लेकिन आप इसके एल्गोरिदम को टीडीडी नहीं कर सकते। वे सामान्य उदाहरण नहीं हैं जैसे "टीडी" उदाहरणों में "योग" या "डबल" या "पॉव" प्राप्त करना [1])। आप शायद कुछ परीक्षण परिदृश्यों को लिखने से बाहर एक नई छवि को नहीं छेड़ सकते हैं; आपको पूरी तरह से बैठना चाहिए और सूत्रों को लिखना और समझना चाहिए।
एंड्रेस एफ।

2
[१] वास्तव में, मुझे पूरा यकीन है fibonacci, जिसे मैंने TDD उदाहरण / ट्यूटोरियल के रूप में देखा है, कमोबेश एक झूठ है। मैं शर्त लगाता हूं कि कोई भी "खोजा हुआ" या किसी भी इसी तरह की श्रृंखला को TDD'ing द्वारा तैयार नहीं करेगा। हर कोई पहले से ही जानना चाहता है, जो धोखा दे रहा है। यदि आप इसे TDD'ing द्वारा खोजने की कोशिश करते हैं, तो आप संभवतः उस मृत-अंत तक पहुंच जाएंगे, जिसके बारे में ओपी पूछ रहा था: आप कभी भी अधिक परीक्षण और रीफ़ैक्टरिंग लिखकर श्रृंखला को सामान्य नहीं कर पाएंगे - आपको गणितीय आवेदन करना होगा तर्क!
एंड्रेस एफ।

दो टिप्पणियां: (1) आप सही हैं कि यह धोखा हो सकता है। लेकिन मैंने यह नहीं लिखा कि टीडीडी गणितीय अनुकूलन के समान है । मैंने इसे केवल एक सादृश्य या एक मॉडल के रूप में उपयोग किया है। मेरा मानना ​​है कि जब तक आप मॉडल और वास्तविक चीज़ के बीच के अंतरों से अवगत नहीं होंगे तब तक गणित को लगभग हर चीज पर लागू किया जा सकता है (और होना चाहिए)। (२) विज्ञान (वैज्ञानिक कार्य) आमतौर पर सॉफ्टवेयर विकास की तुलना में कम अनुमानित है। और मैं यहां तक ​​कहूंगा कि सॉफ्टवेयर इंजीनियरिंग एक शिल्प की तरह वैज्ञानिक कार्य की तरह है। शिल्प आमतौर पर बहुत अधिक नियमित काम की आवश्यकता होती है।
फ्रैंक पफर

@AndresF .: TDD का मतलब यह नहीं है कि आपको सोचने या डिजाइन करने की आवश्यकता नहीं है। इसका मतलब सिर्फ यह है कि आप इम्प्लीमेंट लिखने से पहले टेस्ट लिख लें। आप एल्गोरिदम के साथ ऐसा कर सकते हैं।
जैक्सबी

@FrankPuffer: ठीक है, तो सॉफ्टवेयर विकास में "स्थानीय इष्टतम" का क्या औसत दर्जे का मूल्य है?
जैक्सबी
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.