छद्मोकोड प्रोग्रामिंग प्रक्रिया बनाम टेस्ट संचालित विकास

Question

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

मेरा प्रश्न है - उन लोगों में से जिन्होंने दोनों दृष्टिकोणों की कोशिश की है, जिन्हें आप पसंद करते हैं?

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

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

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

Answer 4

सिर्फ इसलिए कि परीक्षा उत्तीर्ण होती है, इसका मतलब यह नहीं है कि आप कर चुके हैं।

टीडीडी Red - Green - Refactor द्वारा सबसे अच्छी विशेषता है।

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

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

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

वास्तविक लक्ष्य अच्छा सॉफ्टवेयर है। टीडीडी "भलाई" को बाहर नहीं कर सकता है।

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

Answer 5

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

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

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

(मुझे उस के लिए लौ नहीं करते कृपया, मैं केवल आधा गंभीर हूँ: पी)

Answer 6

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

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

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

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