कुछ कारण क्या हैं कि एकमात्र डेवलपर को टीडीडी का उपयोग क्यों करना चाहिए?

Question

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

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

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

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

हॉबी परियोजनाओं को औचित्य देने के लिए और भी कठिन हैं ... वे आम तौर पर सप्ताहांत से कुछ भी कहते हैं। एज-केस कीड़े शायद ही कभी मायने रखती हैं, यह सब कुछ के साथ खेलने के बारे में है।

this one जैसे प्रश्नों को पढ़ना, प्रतिक्रिया पर सबसे अधिक वोट दिया गया है कि उस पोस्टर के अनुभव/राय में टीडीडी वास्तव में समय बर्बाद कर देता है यदि आपके पास 5 से कम लोग हैं (यहां तक ​​कि टीडीडी के साथ क्षमता/अनुभव का एक निश्चित स्तर भी मानते हैं)। हालांकि, ऐसा लगता है कि प्रारंभिक विकास समय, रखरखाव नहीं है। यह स्पष्ट नहीं है कि कैसे एक परियोजना के पूरे जीवन चक्र पर टीडीडी ढेर करता है।

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

I सोचें कि टीडीडी बड़ी टीमों, या कम से कम एक अविश्वसनीय प्रोग्रामर वाली किसी भी आकार की टीम में एक अच्छा दृष्टिकोण होगा। यह मेरा सवाल नहीं है।

एक अच्छा ट्रैक रिकॉर्ड वाला एकमात्र डेवलपर टीडीडी को अपनाने वाला क्यों होगा?

मुझे टीडीडी पर किए गए किसी भी प्रकार के मीट्रिक (औपचारिक रूप से या नहीं) के बारे में सुनना अच्छा लगेगा ... एकल डेवलपर्स या बहुत छोटी टीमों पर ध्यान केंद्रित करना।

यह विफल होने के कारण, आपके व्यक्तिगत अनुभवों के उपाख्यानों को भी अच्छा लगेगा। :)

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

Answer 1

के बारे में मैं आँख बंद करके कुछ भी पालन करने के लिए नहीं कर रहा हूँ।

यह सही रवैया है। मैं हर समय टीडीडी का उपयोग करता हूं, लेकिन मैं इसे कुछ के रूप में सख्ती से पालन नहीं करता हूं।

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

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

Answer 2

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

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

Answer 3

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

वैसे भी, टीडीडी एकल या टीम के पर्यावरण पर निर्भर नहीं है। यह पूरी तरह से आवेदन पर निर्भर करता है।

Answer 4

मेरे पास बहुत अधिक अनुभव नहीं है, लेकिन मुझे परीक्षण के लिए तीव्र-विपरीत दृष्टिकोण देखने का अनुभव मिला है।

एक नौकरी में, कोई स्वचालित परीक्षण नहीं था। "टेस्टिंग" में एप्लिकेशन में चारों ओर पोकिंग शामिल थी, यह देखने के लिए कि क्या यह टूट गया है या नहीं। कहने की जरूरत नहीं है, हमारे उत्पादन सर्वर तक पहुंचने के लिए फ्लैट-आउट टूटे हुए कोड के लिए यह आसान था।

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

तो, मेरे लिए, यह टीम के आकार पर इतना अधिक निर्भर नहीं है, लेकिन आवेदन का आकार। क्या आप आवेदन के हर हिस्से का ट्रैक रख सकते हैं? हर आवश्यकता? यह सुनिश्चित करने के लिए कि प्रत्येक एप्लिकेशन काम कर रहा है, आपको चलाने के लिए हर परीक्षण की आवश्यकता है? यह कहने का भी अर्थ यह है कि यदि एप्लिकेशन साबित करने के लिए आपके पास परीक्षण नहीं है, तो यह एप्लिकेशन "काम कर रहा है"?

बस मेरा $ 0.02।

Answer 5

मैं इस प्रश्न का उत्तर जल्दी से उत्तर देने जा रहा हूं, और उम्मीद है कि आप कुछ तर्क देखना शुरू कर देंगे, भले ही आप अभी भी असहमत हों। :)

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

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

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

Answer 6

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

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

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

Answer 7

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

मेरे पास एक परीक्षण-पहला दृष्टिकोण है क्योंकि मैं अपने कोड में उच्च स्तर का आत्मविश्वास रखना चाहता हूं। अनुमोदित, परीक्षणों को अच्छे परीक्षण होने की आवश्यकता है या वे कुछ भी लागू नहीं करते हैं।

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

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

Answer 8

मैं 'एक डेवलपर' या 'शौक' परियोजनाओं के लिए टीडीडी के ऊपरी हिस्से के बारे में आपके बिंदु की वैधता से सहमत हूं, जो खर्चों को न्यायसंगत नहीं ठहराते हैं।

आप फिर भी विचार करने के लिए है कि सबसे सर्वोत्तम प्रथाओं अगर वे लगातार समय की एक लंबी अवधि के लिए लागू होते हैं की प्रासंगिकता और उपयोगिता है।

उदाहरण के लिए टीडीडी आपको लंबे समय तक परीक्षण/बगफिक्सिंग समय बचा रहा है, पहले यूनिट परीक्षण के 5 मिनट के भीतर नहीं।

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

यह शौक परियोजनाओं के लिए भी लागू होता है। आप इससे थके हुए हो सकते हैं और इसे किसी को पास करना चाहते हैं। आप व्यावसायिक रूप से सफल हो सकते हैं (क्रेगलिस्ट सोचें) और आपके अलावा 5 और लोग काम करेंगे।

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

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

यदि आप ऐसा नहीं करना चाहते हैं - काउबॉय कोडिंग से चिपके रहें, तो यह इस तरह से बहुत आसान है।

पीएस वही बात अन्य प्रथाओं पर लागू होती है:

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

बना बारे में कुछ पता नहीं होगा आदि अनंत तक

Answer 9

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

मैं आम तौर पर एकल काम करता हूं और ज्यादातर टीडीडी करता हूं - ऐसे मामलों जहां मैं बस नहीं हूं जहां मैं अपने प्रथाओं तक जीने में असफल रहता हूं या अभी तक एक अच्छा तरीका नहीं मिला है जो मेरे लिए टीडीडी करने के लिए काम करता है, वेब इंटरफेस के साथ उदाहरण।

Answer 10

अब मैं यूनिट परीक्षणों के उचित सेट के बिना कुछ भी दोबारा प्रतिक्रिया नहीं देता हूं।

मैं यूनिट परीक्षणों के साथ पहले और कोड दूसरे के साथ पूर्ण-ऑन टीडीडी नहीं करता हूं। मैं कैटल करता हूं - कोड ए लिटल, टेस्ट ए लिटिल - डेवलपमेंट। आम तौर पर, कोड पहले जाता है, लेकिन हमेशा नहीं।

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

मैं महत्वपूर्ण बिट्स को दोबारा प्रतिक्रिया देता हूं। पास करने के लिए परीक्षण के मौजूदा सूट प्राप्त करें।

तब मुझे एहसास हुआ कि मैं कुछ भूल गया हूं, और मैं नई सामग्री पर कैटल विकास के लिए वापस आ गया हूं।

तब मैं उन चीजों को देखता हूं जिन्हें मैं हटाना भूल गया - लेकिन क्या वे वास्तव में हर जगह अप्रयुक्त हैं? 'हटाएं और देखें कि परीक्षण में क्या विफल रहता है।

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

अकेले उड़ान के लिए टीडीडी मेरा कॉपिलॉट है।

Answer 11

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

.. पिछले 6 महीनों से मेरे जीवन की शुरुआत। : -/

Answer 12

एकल डेवलपर को अपने प्रोजेक्ट पर टीडीडी का उपयोग करना चाहिए (ट्रैक रिकॉर्ड कोई फर्क नहीं पड़ता), क्योंकि आखिरकार यह परियोजना किसी अन्य डेवलपर को पास की जा सकती है। या अधिक डेवलपर्स लाए जा सकते हैं।

नए लोगों को बिना परीक्षण के कोड के साथ काम करने में कठिनाई होगी। वे चीजें तोड़ देंगे।

Answer 13

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

Answer 14

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

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

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

Answer 15

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

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

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

Answer 16

यहाँ कुछ memes और मेरी प्रतिक्रियाओं हैं:

"टीडीडी ने मुझे इस बारे में सोचा कि यह कैसे असफल होगा, जिसने मुझे एक बेहतर प्रोग्रामर बनाया है"

पर्याप्त अनुभव देखते हुए, विफलता मोड से अत्यधिक चिंतित होने के कारण स्वाभाविक रूप से आपकी प्रक्रिया का हिस्सा बनना चाहिए।

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

किस्सा के लिए "मेरे < पुस्तकालय घटक के लिए महान काम किया एक्स >"

मैं सवाल मैं इन मामलों में मूल्य देखा में कहा है, लेकिन धन्यवाद।

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

जब आप एक प्राप्त करते हैं तो बहिष्कृत आवश्यक कार्यप्रणालियों में किए गए प्रोजेक्ट की सराहना करने के लिए आप कितने जा रहे हैं? आरयूपी, कोई भी? टीडीडी का मतलब है कि टीडीडी का मतलब क्या है कि टीडीडी उतना महान नहीं है जितना हर कोई सोचता है।

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

...

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

Answer 17

मैं भी एक अनुबंध प्रोग्रामर हूं। यहां मेरे 12 Reasons Why I Love Unit Tests हैं।

Answer 18

ठीक है मेरी बारी ... मैं TDD करना चाहते हैं यहां तक ​​कि अपने दम पर (गैर कील/प्रायोगिक/प्रोटोटाइप कोड के लिए), क्योंकि

• इससे पहले कि आप छलांग सोचें: बलों मुझे सोचने के लिए कि मैं क्या कोड को क्रैंकिंग शुरू करने से पहले करना चाहते हैं। मैं यहां क्या हासिल करने की कोशिश कर रहा हूं .. 'अगर मुझे लगता है कि मेरे पास पहले से ही यह टुकड़ा था .. मैं इसे कैसे काम करने की उम्मीद करूंगा?' ऑब्जेक्ट्स के डिजाइन में इंटरफ़ेस को प्रोत्साहित करता है।
• बदलने के लिए आसान: मैं आत्मविश्वास के साथ संशोधन कर सकता हूं .. 'मैंने कदम 1-10 में कुछ भी तोड़ नहीं दिया जब मैंने चरण 5 बदल दिया।' रिग्रेशन परीक्षण तत्काल
• बेहतर डिज़ाइन उभरते हैं: मुझे डिज़ाइन गतिविधि में प्रयास करने के बिना बेहतर डिजाइन मिलते हैं। टेस्ट-फर्स्ट + रेफैक्टरिंग लीड कम से कम युग्मित, कम से कम कक्षाओं के साथ न्यूनतम वर्ग .. कोई overengineering .. कोई YAGNI कोड। कक्षाओं में बेहतर सार्वजनिक इंटरफेस, छोटे तरीके हैं और अधिक पठनीय हैं। यह एक ज़ेन चीज है .. आप केवल ध्यान देते हैं कि जब आप इसे प्राप्त करते हैं तो आपको यह मिल गया।
• डीबगर अब मेरा क्रच नहीं है: मुझे पता है कि मेरा प्रोग्राम क्या करता है .. बिना अपने कोड के घंटों तक कदम उठाने के बिना। आजकल अगर मैं डीबगर के साथ 10 मिनट से अधिक खर्च करता हूं .. मानसिक अलार्म बजने लगते हैं।
• मुझे समय पर घर जाने में मदद करता है मैंने टीडीडी के बाद से अपने कोड में बग की संख्या में उल्लेखनीय कमी देखी है .. भले ही दावा कंसोल ट्रेस की तरह है और xUnit प्रकार एटी नहीं है।
• उत्पादकता/प्रवाह: यह मुझे अगले असतत बच्चे-कदम की पहचान करने में मदद करता है जो मुझे करने की दिशा में ले जाएगा ... स्नोबॉल रोलिंग रखता है। टीडीडी मुझे लय (या एक्सपीर्स कॉल फ्लो) में तेजी लाने में मदद करता है। मुझे पहले की तुलना में प्रति यूनिट समय में किए गए गुणवत्ता के काम का एक बड़ा हिस्सा मिलता है। लाल-हरा-रिफैक्टर चक्र ... एक प्रकार की सतत गति मशीन में बदल जाता है।
• मैं साबित कर सकते हैं कि मेरे कोड एक बटन
• अभ्यास के स्पर्श पर काम करता है बनाता है सही मैं अपने आप को मेरी बेल्ट के अंतर्गत खोलना ड्रेगन तेजी से .. अधिक TDD समय के साथ & सीखने पाते हैं। शायद विसंगति .. लेकिन मुझे लगता है कि टीडीडी ने मुझे एक बेहतर प्रोग्रामर बना दिया है जब भी मैं पहले परीक्षण नहीं करता हूं। रिफैक्टरिंग अवसरों को स्पॉट करना दूसरी प्रकृति बन गया है ...

अगर मैं किसी और के बारे में सोचता हूं तो मैं अपडेट करूंगा .. यही वह है जो मैं प्रतिबिंब के अंतिम 2 मिनट में आया था।

Answer 19

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

Answer 20

प्रेरित स्वयं रुचि।

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

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

चरम पर ले लिया, मैं पुराने (पढ़ने योग्य: बिल करने योग्य) परियोजनाओं पर काम करने से पुराने कोड की समीक्षा करने में अधिक समय व्यतीत कर सकता हूं। इसे सॉफ़्टवेयर के दोबारा लिखने के कोण के रूप में सोचें (इससे पहले कि आप इसे खत्म होने से पहले अनचाहे सॉफ़्टवेयर को कितना ऊंचा कर सकें :)।

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

आखिरकार, यह रखरखाव करने में कम समय और अधिक लाभदायक, अधिक रोचक (लगभग कुछ भी) और अधिक महत्वपूर्ण (परिवार की तरह) करने में अधिक समय व्यतीत करने के लिए अनुवाद करता है।