टीडीडी को एक आदत बनाना: समस्याएं और कार्यान्वयन

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

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

टीम के सदस्यों (प्रशिक्षित सभी) पर मेरे शोध से निम्नलिखित समस्याएं सामने आईं:

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

मुख्य समस्याएं

इन लक्षणों के आधार पर, मुख्य समस्याएं क्या हैं?

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

अधिकांश कार्यान्वयन रणनीतियों को मैंने कक्षा की गतिविधियों (या ई-लर्निंग) और एक-एक सलाह पर ध्यान केंद्रित किया है। ठीक है, वे निश्चित रूप से अपने लक्ष्य को प्राप्त करते हैं, लेकिन मुझे लगता है कि बहुत अधिक की आवश्यकता है।

कक्षा निर्देश दो प्रमुख समस्याओं से ग्रस्त है: उदाहरण बहुत सरल हैं और वास्तविक समस्याओं से संबंधित नहीं हैं, और व्यवहार में इसे आज़माने का लगभग कोई मौका नहीं है।

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

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

किताबें एक बढ़िया विकल्प हैं, लेकिन कुछ डेवलपर्स इंजीनियरिंग प्रथाओं के बारे में किताबें पढ़ना पसंद करते हैं, और यहां तक ​​कि जो इस तरह से TDD सीखते हैं, उन्हें बड़ी समस्याएं हैं। ऑनलाइन पाठ्यक्रमों की तरह, सीखने की समस्या अपने कंधों पर टिकी हुई है।

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

एक दृष्टिकोण

क्या काम कर सकता था? पिछले दृष्टिकोण दो प्रमुख समस्याओं से पीड़ित हैं: गहराई और संचार की कमी। एक पूरी रणनीति में दृष्टिकोणों का एक संयोजन होता है।

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

इस योजना के केंद्र में है: चालू संचार बनाना और टीडीडी के आसपास सहयोग का विस्तार करना। इन रणनीतियों में से तीन इस क्षेत्र में केंद्रित हैं: जोड़ी प्रोग्रामिंग, कोडिंग डोजो और रीडिंग सेमिनार।

कोडिंग डोजो

कोडिंग दोजो (रैंडोरी फॉर्मेट का उपयोग करना) एक ऐसी घटना है जिसमें लोगों का एक छोटा समूह (15 से अधिक नहीं) टीडीडी ( डैनिलो सातो से अनुकूलित) का उपयोग करके समस्याओं का हल करता है:

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

अनुभव से, मेरा सुझाव है कि आप शुरू करने के लिए बहुत छोटे कार्य चुनते हैं।

सेमिनार पढ़ना

सेमिनार पढ़ने के लिए कई किताबें उपलब्ध हैं:

• जावा परियोजनाओं के लिए: लास कोसकेला टेस्ट ड्रिवेन: जावा डेवलपर्स के लिए टीडीडी और स्वीकृति टीडीडी ;
• .NET प्रोजेक्ट्स के लिए: केंट बेक का टेस्ट ड्रिवेन डेवलपमेंट: उदाहरण के लिए ;
• इकाई परीक्षण पैटर्न के बारे में अधिक जानकारी Gerard Meszaros xUnit टेस्ट पैटर्न: टेस्ट कोड को फिर से भरना
• और अगर आपका कोड TDD के साथ विकसित नहीं किया गया था: माइकल फेथर्स लिगेसी कोड के साथ प्रभावी रूप से कार्य कर रहा है ।

आमतौर पर, टीमें प्रति सत्र 1-2 अध्याय की प्रक्रिया करती हैं। काम के बाहर लोगों को पढ़ने के लिए गति काफी धीमी है। इसके अलावा, वह इस अध्याय से कई बिंदुओं की गहन चर्चा के लिए पर्याप्त समय प्रदान करता है।

सहयोगात्मक शिक्षा के लाभ

सेमिनारों में पिज्जा (या कोई अन्य भोजन) होना चाहिए - चूंकि आप लोगों को काम के समान कुछ करने के लिए अपना व्यक्तिगत समय बिताने के लिए कहते हैं, इसलिए उन्हें प्रोत्साहन की आवश्यकता होती है। वैकल्पिक रूप से दो कार्यशालाएं हो सकती हैं, इसलिए लोग ऐसा महसूस नहीं करेंगे कि वे एक चीज में फंस गए हैं। और किसी को यह उम्मीद नहीं करनी चाहिए कि समूह बैठक से बैठक तक स्थिर रहेगा।

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

टीडीडी को एक आदत बनाना

सामान्य तौर पर, ये कुंजी हैं। मुझे लगता है कि वे एक सफल कार्यान्वयन रणनीति बनाने में मदद करते हैं:

• धैर्य, अभ्यास, गहराई
• प्रबंधन का समर्थन
• बहुपक्षीय दृष्टिकोण
• डेवलपर्स डेवलपर्स की मदद करते हैं