टीडीडी: एक विकास पद्धति जिसने मेरा जीवन बदल दिया

सुबह 7:15 बजे। हमारे तकनीकी समर्थन काम के साथ बाढ़ है। गुड मॉर्निंग अमेरिका ने अभी-अभी हमारे बारे में बात की है और पहली बार हमारी साइट पर आने वालों में से बहुतों ने त्रुटियों का सामना किया है।

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

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



सामग्री के लेखक, जिसका अनुवाद आज हम प्रकाशित करते हैं, का मानना ​​है कि यह सब टीडीडी के लिए धन्यवाद से बचा जा सकता था।

मैं TDD का उपयोग क्यों कर रहा हूं?

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

जब कोई मुझसे पूछता है कि उसे टीडीडी से संपर्क क्यों करना चाहिए, तो मैंने उसे यह कहानी सुनाई, और मैं एक दर्जन से अधिक इसी तरह के मामलों को याद कर सकता हूं। सबसे महत्वपूर्ण कारणों में से एक जो मैंने TDD पर स्विच किया है, वह यह है कि यह कार्यप्रणाली कोड के साथ परीक्षणों के कवरेज में सुधार करती है , जिससे उत्पादन में 40-80% कम त्रुटियां होती हैं। यह वही है जो मुझे टीडीडी के बारे में सबसे अधिक पसंद है। यह डेवलपर्स के कंधों से समस्याओं का पहाड़ छीन लेता है।

इसके अलावा, यह ध्यान देने योग्य है कि TDD डेवलपर्स को कोड में परिवर्तन करने के डर से बचाता है।

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

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

TDD क्या है?

TDD का मतलब टेस्ट ड्रिवेन डेवलपमेंट है। इस पद्धति को लागू करने की प्रक्रिया बहुत सरल है:


परीक्षण त्रुटियों का पता लगाते हैं, परीक्षण पूरी तरह से सफल होते हैं, रिफैक्टरिंग का प्रदर्शन किया जाता है

टीडीडी का उपयोग करने के मूल सिद्धांत यहां दिए गए हैं:

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

TDD कार्यक्रमों को विकसित करने के लिए आवश्यक समय को बचाने में कैसे मदद कर सकता है?

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

टीडीडी को एक निश्चित सीखने की अवस्था की विशेषता है, और जबकि एक शुरुआत इस वक्र पर चढ़ती है, विकास के लिए आवश्यक समय 15-35% तक बढ़ सकता है। अक्सर ऐसा ही होता है। लेकिन टीडीडी के उपयोग की शुरुआत के लगभग 2 साल बाद, कुछ अविश्वसनीय होने लगता है। अर्थात्, उदाहरण के लिए, मैंने टीडीडी का उपयोग नहीं किए जाने से पहले की तुलना में तेजी से प्रोग्रामिंग करते हुए, यूनिट परीक्षणों के प्रारंभिक लेखन के साथ शुरू किया।

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

मैंने काम नहीं किया खिलाड़ी टुकड़े के अंत तक पहुंच गया और इसे खेलना जारी रखा, लेकिन मुझे नहीं पता था कि ऐसा क्यों था।

मुझे लगा कि समस्या अनुचित रूप से इवेंट श्रोताओं को जोड़ने वाली थी। मेरा कोड कुछ इस तरह दिखता है:

video.addEventListener('timeupdate', () => {  if (video.currentTime >= clip.stopTime) {    video.pause();  } }); 

समस्या को खोजने की प्रक्रिया इस तरह दिखाई देती है: परिवर्तन करना, संकलन करना, रिबूट करना, क्लिक करना, प्रतीक्षा करना ... इस क्रम को बार-बार दोहराया गया।

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

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

मैं अंत में if . ब्लॉक के बाहर console.log() हूं। "यह मदद नहीं करेगा," मैंने सोचा। अंत में, if इतना सरल था कि मुझे कोई अंदाजा नहीं था कि इसे गलत तरीके से कैसे लिखा जाए। लेकिन इस मामले में लॉगिंग ने काम किया। मैंने कॉफ़ी पी। "वह क्या है?" मैंने सोचा।

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

मैं कार्यक्रम में एक ब्रेकपॉइंट सेट करता हूं ताकि यह समझ सके कि क्या हो रहा है। मैंने clip.stopTime का अर्थ clip.stopTime । मेरे आश्चर्य के लिए, यह undefined था। क्यों? मैंने फिर से कोड को देखा। जब उपयोगकर्ता टुकड़े के अंतिम समय का चयन करता है, तो प्रोग्राम सही स्थान पर टुकड़े के अंत के लिए मार्कर रखता है, लेकिन clip.stopTime का मान सेट नहीं करता है। "मैं एक अविश्वसनीय बेवकूफ हूँ," मैंने सोचा, "मुझे अपने जीवन के अंत तक कंप्यूटर में अनुमति नहीं दी जानी चाहिए।"

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


जब मैं कार्यक्रम करता हूं तो यह कैसा दिखता है

अगर मैंने आज उस कार्यक्रम को लिखा, तो मैं इस तरह काम करना शुरू करूंगा:

 describe('clipReducer/setClipStopTime', async assert => { const stopTime = 5; const clipState = {   startTime: 2,   stopTime: Infinity }; assert({   given: 'clip stop time',   should: 'set clip stop time in state',   actual: clipReducer(clipState, setClipStopTime(stopTime)),   expected: { ...clipState, stopTime } }); }); 

एक भावना है कि इस पंक्ति की तुलना में बहुत अधिक कोड है:

 clip.stopTime = video.currentTime 

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

यहाँ , वैसे, इकाई परीक्षणों को लिखने के लिए उपयोगी सामग्री है, जैसा कि हमने अभी देखा था।

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

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

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

TDD कार्यप्रणाली ने मुझे कैसे बेहतर कोड लिखना सिखाया?

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

इसका कारण यह है कि यूनिट परीक्षण प्रोग्रामर को एक दूसरे से और I / O सबसिस्टम से अलगाव में घटकों का परीक्षण करने के लिए मजबूर करते हैं। यदि मॉड्यूल कुछ इनपुट डेटा के साथ प्रदान किया जाता है, तो उसे निश्चित, पहले से ज्ञात आउटपुट डेटा को छोड़ देना चाहिए। यदि वह नहीं करता है, तो परीक्षण विफल हो जाता है। यदि ऐसा होता है, तो परीक्षण सफल होता है। यहां मुद्दा यह है कि मॉड्यूल को बाकी एप्लिकेशन से स्वतंत्र रूप से काम करना चाहिए। यदि आप राज्य के तर्क का परीक्षण कर रहे हैं, तो आपको स्क्रीन पर कुछ भी प्रदर्शित किए बिना या डेटाबेस में कुछ भी सहेजे बिना ऐसा करने में सक्षम होना चाहिए। यदि आप उपयोगकर्ता इंटरफ़ेस के गठन का परीक्षण कर रहे हैं, तो आपको ब्राउज़र या एक्सेस नेटवर्क संसाधनों में पृष्ठ को लोड किए बिना इसका परीक्षण करने में सक्षम होना चाहिए।

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

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

मुझे TDD में महारत हासिल करने से बहुत पहले जिम्मेदारियों के पृथक्करण के सिद्धांत के बारे में पता था, लेकिन मुझे नहीं पता था कि विभिन्न संस्थाओं के बीच जिम्मेदारी को कैसे साझा किया जाए।

यूनिट परीक्षण ने मुझे कुछ का परीक्षण करने के लिए मोक के उपयोग का अध्ययन करने की अनुमति दी, और फिर मुझे पता चला कि मोकिंग एक संकेत है कि कोड के साथ कुछ गलत हो सकता है । इसने मुझे चौंका दिया और सॉफ्टवेयर रचना के लिए मेरे दृष्टिकोण को पूरी तरह से बदल दिया।

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

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

TDD टीम समय कैसे बचाता है?

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

यह प्रक्रिया आपको एक "बाड़" बनाने की अनुमति देती है जिसके माध्यम से केवल बहुत कम त्रुटियां "कूद" सकती हैं। इस त्रुटि सुरक्षा का पूरे विकास दल पर अद्भुत प्रभाव पड़ता है। यह मर्ज टीम के डर से छुटकारा दिलाता है।

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

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

इस डर के बिना, कार्यक्रमों पर काम करने की प्रक्रिया पहले की तुलना में बहुत शांत है। अंतिम अनुरोधों को अंतिम समय तक रोकने में देरी नहीं की जाती है। CI / CD सिस्टम परीक्षण चलाएगा, और यदि परीक्षण विफल होते हैं, तो यह परियोजना कोड में परिवर्तन करने की प्रक्रिया को रोक देगा। उसी समय, त्रुटि संदेश और जानकारी के बारे में बिल्कुल कि वे कहां हुए हैं, नोटिस नहीं करना बहुत मुश्किल होगा।

यह पूरी बात है।

प्रिय पाठकों! क्या आप अपनी परियोजनाओं पर काम करते समय टीडीडी का उपयोग करते हैं?