php - क्या दुनिया में सबसे कसकर युग्मित साइट के लिए परीक्षण लिखने की कोशिश करना उचित है?




testing cohesion (9)

कल्पना करें कि आपकी नौकरी का 9 0% केवल एक बहुत ही भारी, बहुत टूटी हुई वेबसाइट पर मुद्दों का भ्रमण करने के लिए है। कल्पना कीजिए कि यह वेबसाइट सबसे कसकर युग्मित, कम से कम एकजुट PHP कोड में लिखा गया है जिसे आपने कभी देखा है, कोड का प्रकार जो मूल डेवलपर्स को आपकी "दृष्टि पर थप्पड़" सूची में जोड़ देगा। कल्पना करें कि यह वेब एप्लिकेशन 4 बहुत ही अलग हिस्सों (1 वाणिज्यिक, 2 "पुनर्निर्मित", और 1 कस्टम) से बना है और वर्चुअल डक्ट टेप और शिम्स का बकवास-टन है। कल्पना कीजिए कि इसमें प्रोग्रामिंग प्रथाओं का प्रकार शामिल है जिसमें वेबसाइट के प्रमुख घटक वास्तव में उन चीजों पर भरोसा करते हैं जो ठीक से काम नहीं कर रहे हैं, और इन टूटी चीजों को ठीक करने से आम तौर पर अन्य चीजें टूट जाती हैं। कल्पना कीजिए कि आप बहुत बुरे अनुभवों से जानते हैं जो वेबसाइट के एक प्रतीत होता है कि निर्दोष हिस्सा बदलते हैं, जैसे "नाम" फ़ील्ड को दो अलग "पहले" और "अंतिम" फ़ील्ड में विभाजित करना, साइट को घुटनों पर लाएगा और इसके घंटों की आवश्यकता होगी रोलबैक, विलय और पैच। कल्पना करें कि ग्राहकों के साथ कोड को खिसकाने और पूरी तरह से शुरू करने के लिए वर्षों से एंटरप्राइज़-ग्रेड निराशा और हाथ wringing से मुलाकात की जा रही है। फिर कल्पना करें कि नई सुविधाओं को लागू करने के लिए ASAP / EMERGENCY टिकट प्राप्त करने की कल्पना करें कि किसी भी अन्य वेबसाइट में 4 घंटे लगेंगे लेकिन आप इस साइट के साथ बेहतर जानते हैं ताकि आप 40 घंटे उद्धृत कर सकें, फिर उसके द्वारा सही तरीके से उड़ें और 80 घंटे का बिल दें, लेकिन यह ठीक है क्योंकि क्लाइंट इसका उपयोग उनकी वेबसाइट के साथ किया जाता है।

यहां कुछ अन्य चीजें हैं जिन्हें आपको कल्पना भी करनी चाहिए:

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

यह सब कल्पना कीजिए, क्या यह परीक्षण कवरेज के एक मध्यम स्तर को हासिल करने की कोशिश करने लायक भी है? या आप इस काल्पनिक परिदृश्य में, जो कुछ भी आपको दिया गया है और उम्मीद कर रहे हैं, प्रार्थना कर सकते हैं, यहां तक ​​कि यहां तक ​​कि बलिदान भी कर सकते हैं, कि ग्राहक इन दिनों में से किसी एक को फिर से लिखने के लिए सहमत होंगे और फिर आप लिखना शुरू कर सकते हैं परीक्षण?

परिशिष्ट

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

अब तक सभी प्रतिक्रियाओं के लिए धन्यवाद!


इसकी कोशिश करें

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

साइट के एक छोटे से हिस्से पर यह कम से कम एक मूल्य है (मुझे पता है कि आप किसी भी हिस्से को पूरी तरह से अलग नहीं कर पाएंगे, लेकिन आप अभी भी भाग को लक्षित कर सकते हैं)।

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

सौभाग्य!


बिलकुल नहीं।

यदि आप कहते हैं कि कई चीजें अन्य चीजों पर भरोसा करती हैं जो विशेष रूप से काम नहीं कर रही हैं तो आप इसका परीक्षण कैसे शुरू कर सकते हैं?

व्यक्तिगत रूप से मैं इसे स्क्रैप कहूंगा और शुरू करूंगा। चार घंटे की विशेषताएं जो 80 लेती हैं? मुझे उम्मीद है कि यह एक असाधारण है। आपके सिरदर्द होना चाहिए।

मैं कोड बेस को फिर से लिखने के लिए एक बहुत ही दृढ़ प्रस्ताव के साथ शुरू करूंगा। हाथ-wringing ग्राहकों को कुछ बार धुंध सच कहा जाना चाहिए। टूटे हुए आधार के साथ कितने अन्य डेवलपर काम करेंगे? कुछ सुंदर लागत / लाभ चार्ट बनाएं।

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


आप इसे स्क्रैप नहीं कर सकते। ग्राहक आपको जाने नहीं देगा, और यह वैसे भी सबसे अच्छा रास्ता नहीं हो सकता है।

तो एक फिक्स के लिए 40 घंटे उद्धृत करने के बजाय जो मिनट लेना चाहिए था ... उद्धरण 60. ग्राहक उसके साथ ए-ओके लगता है। ठीक करने के लिए 40 का उपयोग करें, और 20 रिफैक्टर करने के लिए ... और आप जो प्रतिक्रिया करते हैं उस पर परीक्षण लिखें। यदि 60 रन 100 तक, तो 120 खर्च करें; 80 को ठीक करने के लिए, और 40 रिफैक्टर / परीक्षण करने के लिए।

अपने सामान्य अनुमानों में चीज़ को बेहतर बनाने के लिए समय में बनाएं, या नया काम ढूंढें; वर्तमान स्थिति, ऐसा लगता है, आपको हमारे क्षेत्र से नफरत करने में ड्राइव करेगा।


आप एक अच्छा बीडीडी (डोमेन) मॉडल बनाने के लिए 40 घंटे / पुनरावृत्ति बिलिंग पर विचार करना चाह सकते हैं कि एप्लिकेशन कैसे काम करता है या बेहतर: काम करना चाहिए। यह एक अच्छा ढांचा बनाता है जहां आप आवश्यक सुविधाओं को दस्तावेज कर सकते हैं। जब मॉडल पर्याप्त हो जाता है, तो आप अनुमान लगा सकते हैं कि इसे एक कार्यरत एप्लिकेशन में बदलने के लिए आपको कितना समय चाहिए।


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

और शायद " लीगेसी कोड के साथ प्रभावी ढंग से काम करना " किताब पढ़ने के लायक है?

संपादित करें

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

2 संपादित करें

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

संपादित करें 3

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


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

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

हालांकि, संभावित लाभ देखें। यह आपको बताना चाहिए कि यह वास्तव में इसके लायक है या नहीं।

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

याद रखें, लाभों काटने के लिए आपको 100% कवरेज की आवश्यकता नहीं है। प्रत्येक परीक्षण अर्थ जोड़ता है ...


यह इसे टेस्ट करने योग्य बनाने के लिए लगता है, आपको सिस्टम के हिस्सों को खरोंच से फिर से लिखना होगा - अनिवार्य रूप से प्रक्रिया में कई बग का कारण बनता है।

आप जो वर्णन करते हैं, उससे पुरानी व्यवस्था उस तरह के प्रयास को डालने के लायक नहीं है।

मैं किसी भी परिस्थिति में इसके लिए परीक्षण करने की कोशिश नहीं करता हूं, लेकिन जितनी जल्दी हो सके पुनः लिखने की अनुमति प्राप्त करने का प्रयास करता हूं।

यदि आपके ग्राहक को प्रकाश दिखाई नहीं देता है, तो इस बात पर विचार करें कि परियोजना को दोबारा करने का अधिकार आपके लिए कुछ समय देने लायक है: स्वच्छ कोड के साथ काम करना किसी के कल्याण के लिए बहुत बेहतर है ...


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

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

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

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


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





tightly-coupled-code