आप टीडीडी के साथ जटिल सिस्टम कैसे डिजाइन करते हैं?

Question

Does TDD mean not thinking about class design? के समान, मुझे इस बारे में सोचने में परेशानी हो रही है कि परंपरागत 'डिज़ाइन' चरण टीडीडी में फिट बैठता है।

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

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

या मैं कुछ भी नहीं के बारे में चिंता कर रहा हूँ, और कोड बस परीक्षण है नहीं (व्यवहार में) को फिर से लिखने या refactor करने के लिए मुश्किल है, तो आप एक कोने में चित्रित कर रहे हैं पालन करने के लिए लिखा? वैकल्पिक रूप से, क्या मैं बिंदु खो रहा हूं और मुझे होने की उम्मीद है जब मैं कार्यक्षमता के एक नए खंड का परीक्षण करने के लिए कोड के भाग को फिर से लिखूं?

Answer 1

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

टीडीडी का हिस्सा रिफैक्टरिंग कर रहा है।

Answer 2

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

किसी को सावधानी बरतनी चाहिए और कोड को सुगंधित करना चाहिए और रिफैक्टरिंग अवसरों और कोड गंधों का पता लगाने के लिए कोड को स्नीफ करना चाहिए।

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

Answer 3

मैं TDD के साथ डिजाइन करने के तीन तरीके पाया है:

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

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

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

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

इससे मुझे सही होने पर मुझे अपना कोड अधिक तेज़ी से प्राप्त करने देता है। ऐसा कहकर, यह कोड को सही बनाने का मेरा प्रयास था जिसने मुझे सिखाया कि रेखा कहां थी!

Answer 4

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

संदर्भ 'विकास', TDD का उपयोग कर आप यह सुनिश्चित होगा परीक्षण योग्य कोड है जो सभी लाभ TDD के बारे में उद्धृत देना लिख ​​रहे हैं

लेकिन 'डिजाइनिंग' बड़े जटिल प्रणालियों में, TDD विशेष रूप से

1. (इंजीनियरिंग के लिए) प्रदर्शन निम्नलिखित चिंता है कि प्रणाली की वास्तुकला में निहित हैं को संबोधित नहीं करता
2. सुरक्षा
3. अनुमापकता
4. उपलब्धता
5. (और अन्य सभी 'ilities')

(अर्थात उपर्युक्त सभी चिंताओं को जादूत्मक रूप से 'उभरना' नहीं है, "पहले एक असफल परीक्षण केस लिखें, इसके बाद कार्य कार्यान्वयन, रिफैक्टर - पादर, कुल्ला, दोहराना ..." नुस्खा)।

• इन के लिए, आप से समस्या दृष्टिकोण की आवश्यकता होगी सफेद बोर्डिंग उच्च स्तरीय और बाधाओं की आवश्यकताओं और समस्या अंतरिक्ष द्वारा लगाए गए के संबंध में एक प्रणाली की तो निम्न स्तर के विवरण।

• उपर्युक्त विचारों में से कुछ एक-दूसरे के साथ प्रतिस्पर्धा करते हैं और सावधानीपूर्वक व्यापार-बंद की आवश्यकता होती है जो बहुत सारे यूनिट परीक्षणों के माध्यम से 'उभरती' नहीं होती हैं।

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

मैं सॉफ्टवेयर का एक काफी जटिल टुकड़ा (जैसे संकलक, डेटाबेस, ऑपरेटिंग सिस्टम) है कि एक टेस्ट प्रेरित डिजाइन शैली में किया गया था भर में अभी आना बाकी है।निम्नलिखित ब्लॉग आलेख इस बिंदु के बारे में बहुत अच्छी तरह से बात करता है (Compilers, TDD, Mastery)

इसके अलावा, निम्नलिखित videos on Architecture देखें जो विचार प्रक्रिया में बहुत सामान्य ज्ञान जोड़ता है।