क्या TDD और एजाइल प्रैक्टिस एक इष्टतम समाधान का वादा कर सकते हैं? (या एक "अच्छा" समाधान भी?)
बिल्कुल नहीं। लेकिन, यह उनका उद्देश्य नहीं है।
ये विधियाँ बस एक राज्य से दूसरे राज्य में "सुरक्षित मार्ग" प्रदान करती हैं, यह स्वीकार करते हुए कि परिवर्तन समय लेने वाले, कठिन और जोखिम भरे हैं। और दोनों प्रथाओं का बिंदु यह सुनिश्चित करना है कि आवेदन और कोड दोनों व्यवहार्य हैं और आवश्यकताओं को जल्दी और अधिक नियमित रूप से पूरा करने के लिए सिद्ध होते हैं।
... [TDD] सॉफ्टवेयर डेवलपमेंट के विरोध में है, जो ऐसे सॉफ्टवेयर को जोड़ने की अनुमति देता है जो आवश्यकताओं को पूरा करने के लिए सिद्ध नहीं होता है ... केंट बेक, जिसे विकसित होने या 'रिडिजर्व किए गए' तकनीक का श्रेय दिया जाता है, ने कहा कि TDD सिंपल को प्रोत्साहित करता है डिजाइन और आत्मविश्वास को प्रेरित करता है। ( विकिपीडिया )
टीडीडी कोड की प्रत्येक "चंक" को सुनिश्चित करने पर ध्यान केंद्रित करता है जो आवश्यकताओं को संतुष्ट करता है। विशेष रूप से, यह सुनिश्चित करने में मदद करता है कि कोड पहले से मौजूद आवश्यकताओं को पूरा करता है, क्योंकि आवश्यकताओं को खराब कोडिंग द्वारा संचालित करने की अनुमति के विपरीत है। लेकिन, यह कोई वादा नहीं करता है कि कार्यान्वयन किसी भी तरह से "इष्टतम" है।
चुस्त प्रक्रियाओं के लिए:
कार्य सॉफ्टवेयर प्रगति का प्राथमिक उपाय है ... प्रत्येक पुनरावृत्ति के अंत में, हितधारकों और ग्राहक प्रतिनिधि प्रगति की समीक्षा करते हैं और निवेश पर वापसी को अनुकूलित करने की दृष्टि से प्राथमिकताओं का मूल्यांकन करते हैं ( विकिपीडिया )
चपलता एक इष्टतम समाधान की तलाश में नहीं है ; आरओआई को अनुकूलित करने के इरादे से - बस एक काम कर समाधान । यह बाद में के बजाय जल्द ही काम कर समाधान का वादा करता है ; एक "इष्टतम" एक नहीं।
लेकिन, यह ठीक है, क्योंकि सवाल गलत है।
सॉफ़्टवेयर डेवलपमेंट में ऑप्टिमाइज़ फ़र्ज़ी, मूविंग टारगेट होते हैं। आवश्यकताएं आमतौर पर प्रवाह में होती हैं और उन रहस्यों से रूबरू होती हैं जो केवल आपके बॉस के बॉस से भरे कॉन्फ्रेंस रूम में, आपकी शर्मिंदगी के लिए उभर कर आते हैं। और एक समाधान की वास्तुकला और कोडिंग की "आंतरिक अच्छाई" को आपके साथियों की विभाजित और व्यक्तिपरक राय द्वारा वर्गीकृत किया गया है और आपके प्रबंधकीय अधिपति - जिनमें से कोई भी वास्तव में अच्छे सॉफ़्टवेयर के बारे में कुछ भी नहीं जान सकता है।
बहुत कम में, TDD और चंचल प्रथाओं कठिनाइयों स्वीकार करते हैं और दो चीजें हैं जो के लिए अनुकूलन करने का प्रयास कर रहे हैं उद्देश्य और औसत दर्जे का: । वर्किंग वी नहीं-कार्य और जल्द ही वी बाद में।।
और, भले ही हम उद्देश्य मैट्रिक्स के रूप में "काम कर रहे" और "जल्दी" हो, उनके लिए आपके अनुकूलन की क्षमता मुख्य रूप से एक टीम के कौशल और अनुभव पर आकस्मिक है।
जिन चीज़ों पर आप प्रयास कर सकते हैं, वे इष्टतम समाधान पैदा करती हैं, जैसे चीज़ें शामिल हैं:
आदि..
क्या उन चीजों में से प्रत्येक वास्तव में इष्टतम समाधान पैदा करता है, यह पूछने के लिए एक और महान सवाल होगा!