गहन अभ्यास के माध्यम से टीडीडी की खोज

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



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



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

टीएल? डॉ।

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



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

विवरण

गैरी क्लेन के स्रोतों को पढ़ते हुए, जो बताता है कि लोग कैसे निर्णय लेना सीखते हैं, गहन अभ्यास पर मेरे अध्याय ने मेरा ध्यान आकर्षित किया। (मैं इस पुस्तक के पृष्ठ 104 के कुछ उद्धरणों पर टिप्पणी करूंगा।)

चूंकि प्रभावी निर्णय लेने की कुंजी विशेषज्ञता निर्माण है, इसलिए प्रलोभनों में से एक प्रशिक्षण बनाना है जो लोगों को विशेषज्ञों की तरह सोचने के लिए सिखाता है।

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

ज्यादातर मामलों में, यह बहुत लंबा और महंगा होगा।

हाँ।

हालांकि, अगर हम लोगों को विशेषज्ञों के रूप में सोचने का तरीका नहीं सिखा सकते हैं, तो शायद हम उन्हें विशेषज्ञों के रूप में अध्ययन करना सिखा सकते हैं।

चलें ...

साहित्य का अध्ययन करने के बाद, मैंने कई तरीकों की पहचान की जिन्हें विशेषज्ञों को विभिन्न क्षेत्रों में प्रशिक्षित किया जा सकता है:

• वे गहन अभ्यास में भाग लेते हैं ताकि प्रत्येक व्यावहारिक पाठ का एक उद्देश्य और मूल्यांकन मानदंड हो।
• वे अनुभव की एक व्यापक परत हासिल करते हैं।
• उन्हें प्रतिक्रिया मिलती है: सटीक, नैदानिक ​​और समय पर।
• वे अपनी गलतियों को सीखने के लिए "डिब्रीपिंग" आयोजित करके अपने अनुभव को समृद्ध करते हैं।

यह कुछ परिचित लगता है, लेकिन कुछ TDD प्रथाओं से अधिक जानने के लिए एक नए अवसर का प्रतिनिधित्व करता है।

चार में से तीन इतना बुरा नहीं है

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



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

• मैंने वर्ष 2000 की शुरुआत से नवंबर 2001 में आईबीएम से प्रस्थान करने तक लगभग सभी कार्यशील कोड लिखने के लिए TDD का उपयोग करके अनुभव की एक व्यापक परत विकसित की।
• मुझे सटीक, निदान और समय पर प्रतिक्रिया मिली, हजारों सवाल पूछे और विभिन्न मेलिंग सूचियों में गंभीर चर्चा में भाग लिया। (तब कोई StackOverflow नहीं था।) मैंने अन्य लोगों से कई सवालों के जवाब भी लिए, जिससे मुझे बहुत सारे कोड पढ़ने, लिखने और सुधार करने की आवश्यकता हुई।
• मेलिंग सूचियों पर प्रश्नों का उत्तर देना, सम्मेलनों में, उपयोगकर्ता की बैठकों में, मैंने अक्सर पुराने विषयों पर बार-बार छुआ, जिससे मुझे अपने पुराने उत्तरों को सुधारने की अनुमति मिली, साथ ही साथ नई अंतर्दृष्टि का भी अनुभव हुआ। इस अनुभव के सभी अंत में मेरी पहली पुस्तक में बदल गया: JUnit व्यंजनों: प्रोग्रामर परीक्षण के लिए व्यावहारिक तरीके ।

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

गहन टीडीडी अभ्यास

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



कुछ बग फिक्स पकड़ो। सबसे अधिक संभावना है, आप पहले से ही जानते हैं कि "पहले परीक्षण" (परीक्षण-पहले) के सिद्धांत का उपयोग करके कीड़े को कैसे ठीक किया जाए, लेकिन बस इस मामले में, मैं इस प्रक्रिया का संक्षेप में वर्णन करूंगा:

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

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



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



क्या मेरे पास एक स्पष्ट लक्ष्य और मूल्यांकन मानदंड है? मुझे एक स्पष्ट लक्ष्य दिखाई देता है: बग को ठीक करने के लिए, परीक्षण लिखना सीखें, अधिक केंद्रित परीक्षण लिखना सीखें, और कोड के बारे में ज्ञान भी प्राप्त करें ताकि यह ज्ञान उस समय तक वाष्पित न हो जाए, जब तक मैं सामान्य रिपॉजिटरी में अपने बदलाव नहीं भेजता। और मूल्यांकन मानदंडों के रूप में, मैं निम्नलिखित में से एक चुन सकता हूं:

• बग को ठीक करने के कुछ समय बाद इन परीक्षणों पर लौटना मेरे लिए कितना आसान है और समझ में आया कि मैं क्या कर रहा था?
• किसी और के लिए मेरे परीक्षणों को पढ़ना और समझना आसान है कि मैं क्या कर रहा था?
• बड़े परीक्षणों से छोटे की ओर बढ़ना मेरे लिए कितना आसान है?
• जब मैं बड़े परीक्षणों से छोटे लोगों पर स्विच करता हूं तो क्या कोई जानकारी खो जाती है?
• मुझे कितना विश्वास है कि यह विशेष बग दोबारा नहीं होगा?
• बग से लड़ने पर मुझे कितना शांत और आरामदायक लगता है?

मुझे नहीं पता कि क्या आप इन मानदंडों को पर्याप्त रूप से स्पष्ट कहेंगे, लेकिन कम से कम आप पहले से ही इनसे शुरू कर सकते हैं। शायद एक साथ हम बेहतर मूल्यांकन मानदंड बना सकते हैं।



क्या यह मुझे अनुभव की एक व्यापक परत बनाने में मदद करेगा? यह मदद करेगा अगर मैं अगले कुछ महीनों में इस तरह से 50 कीड़े ठीक करूं। कम से कम, अगर मैं इस तरह से सभी कीड़े को ठीक करने का फैसला करता हूं, तो मैं लगातार एक महत्वपूर्ण मात्रा में अनुभव जमा करूंगा। खासकर अगर मैं सिस्टम के सभी हिस्सों में कीड़े को ठीक कर दूंगा। और भी अधिक, अगर कई प्रणालियों में।



क्या मुझे सटीक, नैदानिक, समय पर प्रतिक्रिया मिलेगी? मुझे ऐसा लगता है। हर बार जब मैं एक नया परीक्षण लिखता हूं, तो यह या तो पास हो जाएगा या गिर जाएगा। इसलिए, कम से कम मैं यह समझ सकता हूं कि मैंने कोड के टूटे हुए हिस्से से संपर्क करना शुरू कर दिया। मुझे 100% यकीन नहीं हो रहा है कि मुझे वह कोड ऑफ कोड मिल गया है जो तब तक दुर्घटना का कारण बनता है जब तक कि मेरे परीक्षण एक या दूसरे तरीके से इसे साबित करने के लिए पर्याप्त नहीं हो जाते हैं, और मैं धीरे-धीरे इस दिशा में आगे बढ़ रहा हूं।



नई अंतर्दृष्टि पाने के लिए क्या यह मेरे पुराने अनुभव पर पुनर्विचार करने में मेरी मदद करेगा? हाँ और नहीं। नहीं, क्योंकि (मुझे उम्मीद है) मुझे एक ही बग को दो बार ठीक नहीं करना है; लेकिन हां, क्योंकि मैं हर नए बग के साथ इस तरह काम करता हूं, इसलिए मुझे कई बार सिस्टम के समान हिस्सों से निपटना पड़ता है। सिस्टम के किसी भी हिस्से में जितने अधिक कीड़े हैं, उतने ही अधिक अवसर मुझे अपने पिछले परीक्षणों में लौटने और पुराने के साथ अपने नए अनुभव की तुलना करने में होंगे। यदि मैं पिछले समय से अलग ढंग से जो कर रहा हूं उसकी तुलना करने में थोड़ा समय व्यतीत करता हूं, इससे मुझे नई अंतर्दृष्टि प्राप्त करने का अवसर मिलेगा।



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

बग के साथ काम करने के बाहर

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

नियम स्वयं कुछ नहीं करते हैं; लोग सब कुछ करते हैं। TDD, किसी भी अन्य अभ्यास की तरह, चिकित्सक को मस्तिष्क को चालू करने की आवश्यकता होती है। उसे सचेत रूप से व्यायाम करना चाहिए।

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

TDD "होशपूर्वक" अभ्यास कैसे करें

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



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

टीडीडी प्रशिक्षण लक्ष्य

• एक लाइब्रेरी के साथ परीक्षण के माध्यम से एक एकीकरण बिंदु बनाएं जिसे आपने पहले काम नहीं किया है।
• अपने कोड के थोड़ा बड़े हिस्से को फ्रेमवर्क के साथ एकीकरण से अलग करें।
• कम परीक्षण लिखें जिन्हें एक रूपरेखा-उन्मुख परीक्षण लाइब्रेरी (उदा। Robolectric, NUnitASP, rspec-rails, या JSFUnit) की आवश्यकता होती है, और अधिक परीक्षण जो नियमित परीक्षण पुस्तकालयों (नियमित JUnit, RSpec, या pytest) का उपयोग करते हैं।
• अगला परीक्षण बनाने में लगने वाले समय को कम करें।

टीडीडी पर प्रशिक्षण के लिए मूल्यांकन मानदंड।

• क्या मैंने सिस्टम के इस हिस्से को सामान्य से अधिक सरल बना दिया है?
• क्या सिस्टम के इस हिस्से के नाम दूसरों के लिए अधिक समझदार हैं, क्या वे यह समझने में मदद करते हैं कि इस कोड को कैसे बदला जाए?
• क्या मैं मौजूदा कोड को संशोधित करने के बजाय केवल नए कोड जोड़कर सिस्टम के इस हिस्से का विस्तार कर सकता हूं?
• क्या मेरे परीक्षणों के वातावरण को कॉन्फ़िगर करने के लिए आवश्यक कोड केवल सिस्टम के उन हिस्सों पर निर्भर करता है जिन्हें मैंने अभी बनाया था?
• यदि मेरे परीक्षण में कई परीक्षण शामिल हैं, तो क्या मुझे लगता है कि वे एक-दूसरे से दृढ़ता से संबंधित हैं?
• क्या मेरे टेस्ट काफी तेजी से पास होते हैं? या कम से कम वे पहले से ज्यादा तेज हो गए हैं?

यदि हम कम से कम दस मिनट के लिए एक साथ बैठते हैं, तो हम संभवतः इन उपयोगी मानदंडों में से एक दर्जन के साथ आते हैं। कुछ चुनें और अगले प्रोग्रामिंग सत्र के लिए उन्हें ध्यान में रखें, जिसके दौरान आप टीडीडी का अभ्यास करेंगे।



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



और अब मैं गैरी क्लेन के मॉडल में एक महत्वपूर्ण बिंदु पर जाना चाहूंगा, उस बिंदु पर जिसने मुझे आज यह लेख लिखा है।

व्यापक अनुभव

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

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

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



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



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



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

---

1 ।लोगों के व्यवहार को बदलने में मदद करने के बारे में अधिक जानने के लिए स्विच का अध्याय 3 पढ़ें ।

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