2010-03-25 10 views
8

मैं ऐसी कंपनी में काम करता हूं जहां ओओपी है ... ठीक है, फोब नहीं किया गया है, लेकिन कम से कम "बहुत जटिल" के रूप में जाना जाता है। मेरे सहकर्मी 100+ लाइन फ़ंक्शंस लिखते हैं और वे आम तौर पर "funcs.inc.php" या "something.inc.php" में होते हैं, अगर वे किसी भी फ़ंक्शन का उपयोग करते हैं, तो अक्सर वे कॉपी-पेस्ट नहीं करते हैं और तेज।बहुत "टेस्टी" वातावरण में टीडीडी का उपयोग कैसे करें

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

यह विरासत कोड नहीं है क्योंकि वे सक्रिय रूप से इसे विकसित कर रहे हैं और मैं उनके कोड को संशोधित नहीं करना चाहता क्योंकि मैं संघर्ष को उत्तेजित नहीं करना चाहता हूं।

कंपनी को बदलने के अलावा, आप किस दृष्टिकोण का सुझाव देंगे?

+4

आईएमओ, यदि आप कोड को संशोधित नहीं करना चाहते हैं, तो यह विरासत कोड है। –

+0

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

+0

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

उत्तर

11

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

  1. फिर से नामकरण से एक API तोड़ दिया या पूरी तरह से कुछ
  2. के साथ भाग कर सूक्ष्म प्रकार में परिवर्तन के साथ एक API तोड़ दिया गौर नहीं मिलता था कि
  3. परीक्षण के बिना एक जहरीले संशोधन पुश किया यह
  4. उछला मेमोरी लीक
  5. ब्लॉक जहां वे
से पहले अवरुद्ध कभी नहीं (मेरे टेस्ट स्वीट वेलग्रिंड बारे में पता है)

इनमें से कोई भी असफल होने का परिणाम आमतौर पर मुझे कहता है "अरे, क्या आप जांच सकते हैं (मॉड्यूल), मुझे लगता है कि यह अंतिम संशोधन में टूट गया है"

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

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

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

+0

अच्छा सुझाव, लेकिन इसके साथ मेरी समस्या यह है: मैं पैरामीटर या कभी-कभी (हाल ही में हाल ही में) वैश्विक चर या वैश्विक परिभाषाओं के आधार पर 6 अलग-अलग कार्यों को करने वाले कार्यों का परीक्षण कैसे कर सकता हूं और इसमें 80% MySQL क्वेरी शामिल हैं? – dbemerlin

+0

@ डीबेमेरिन: आपकी स्थिति मुझे लगता है की तुलना में थोड़ा और अधिक लगता है :) आप जो कर सकते हैं वह _your_ उपयोग मामलों के साथ परीक्षण है, जो इसे थोड़ा सा संकीर्ण करता है। आप ग्लोबल्स को खुद को आवश्यकतानुसार सेट कर सकते हैं, लेकिन मुझे उनके साथ आपका अंक मिल गया है, फिर भी आप सोचते हैं कि एक वर्ग का विज्ञापन विज्ञापित/निर्देशित के रूप में क्यों उपयोग किया जाता है और वैश्विक पर इसकी निर्भरता का विज्ञापन नहीं करता है। परीक्षण लागू करने के लिए वास्तव में कोई 'शानदार' तरीका नहीं है जब कोई और भी ऐसा नहीं कर रहा है। क्वेरी डेटा के लिए, फ़ंक्शंस अपेक्षित इनपुट को स्पष्ट नहीं करता है? कूटनीति के लिए –

+2

+1, विशेष रूप से "मुझे लगता है ** यह अंतिम संशोधन में ** टूट गया।" दोष कभी मनोबल में मदद करता है। –

4

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

यदि वे कभी नहीं पूछते हैं, तो कम से कम, आपने अपना जीवन थोड़ा और आसान बना दिया है।

3

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

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

2

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

उन पुस्तकालयों के लिए नकली फ़ंक्शन बनाएं जिन्हें आप स्वयं से अलग करना चाहते हैं।

2

क्या आप पहले अपने कोड पर यूनिट परीक्षण लिख सकते हैं? अन्य लोगों द्वारा परेशान मत हो; सुनिश्चित करें कि आपका कोड पूरी तरह से tdded और इकाई परीक्षण किया गया है।

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

संबंधित मुद्दे