क्या आपको किसी और चीज़ पर काम करते समय preexisting दोषों को ठीक करना चाहिए?

Question

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

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

धन्यवाद, कोरी

Comments

Informit.com/articles/article.aspx?p=1235624&seqNum=6 देखें ।

— ओलिवर वीलर

Answer 1

मैं एक बहुत छोटी टीम पर काम करता हूं, इसलिए यह इस बात पर निर्भर करता है कि बदलाव क्या है:

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

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

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

लेकिन ऐसा महसूस न करें कि सराहना की कमी बग को ठीक करने के लिए या किसी भी कारण से कोड आधार में सुधार न करने का एक कारण है। यदि और कुछ नहीं, तो आप भविष्य के लिए दयालु हो रहे हैं, जो निश्चित रूप से कुछ और तय करने के लिए वापस वहाँ जाएगा।

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

Comments

लड़के स्काउट नियम का उल्लेख करने के लिए +1 "जितना आपने पाया, कैंपग्राउंड क्लीनर को छोड़ दें।"

— मार्टिन विकमैन

Answer 2

हमेशा की तरह, यह निर्भर करता है।

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

मूल रूप से आप एक जोखिम मूल्यांकन कर रहे हैं: क्या बदलने का जोखिम है बनाम नहीं बदल रहा है। यदि आपको ऐसा नहीं लगता है कि आपको पर्याप्त अनुभव मिला है (सामान्य रूप से प्रोग्रामिंग या विशेष रूप से सिस्टम के साथ) तो टीम में किसी और से पूछें।

Answer 3

व्यावहारिक प्रोग्रामर इन 'ब्रोकन विंडोज' को कहते हैं।

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

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

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

Answer 4

यदि यह एक स्पष्ट बग है, जैसे कि कुछ ऐसा जो सुरक्षा, भ्रष्ट डेटा का उल्लंघन करेगा, या उपयोगकर्ता को प्रदर्शित होने वाले अपवाद को बढ़ाएगा, तो इसे ठीक करें। अन्यथा, किसी ऐसे व्यक्ति से पूछें जो कोडबेस को आपसे बेहतर जानता हो।

Comments

उचित लगता है। उस चीज़ के बारे में क्या जो मामूली रूप से मामूली है, जैसे विकृत HTML जो कि Quirks मोड में रेंडर करने वाला ब्राउज़र बर्दाश्त करता है? बग, इस मामले में, थोड़ा नुकसान पहुंचा रहा है, लेकिन मुझे पता है कि यह जीवन को सड़क के नीचे कठिन बना देगा अगर कुछ नई सामग्री / प्लगइन को पेज को मानकों के अनुरूप मोड में प्रस्तुत करने की आवश्यकता होती है।

— कोरी

@ कोरी: हाँ, यह उस तरह की चीज है जिस पर आप एक अधिक अनुभवी डेवलपर से परामर्श करना चाहते हैं। आपके पास एक राय है, और मैं मानता हूं कि यह शायद सही निर्णय है, इसलिए अपने मामले को प्रस्तुत करें, लेकिन ध्यान रखें कि ऐसे अन्य कारक हो सकते हैं जिनके बारे में आपको पता नहीं है कि जो आदमी 5 साल से इस पर काम कर रहा है वह समझता है।

— मेसन व्हीलर

Answer 5

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

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

Answer 6

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

Comments

कभी-कभी एक छोटा बग फिक्स करना वास्तव में इसे अनदेखा करने से अधिक समय नहीं लेता है, और बाद में इसे ठीक करने की तुलना में अधिक कुशल है।

— डेविड थोरले

यही कारण है कि मैंने कहा जब तक यह तुच्छ नहीं है। लेकिन कुछ भी है जो मुझे लगता है कि लॉग किया जाना चाहिए 15 मिनट से अधिक लेने जा रहा है।

— क्रेग

Answer 7

मैं उन टीमों पर गया हूँ जहाँ गैर-महत्वपूर्ण दोष या मानक-उल्लंघन "कमजोर कोड" दोष के रूप में प्रस्तुत किए जाते हैं। मैं कहूंगा कि जो व्यक्ति एक महत्वपूर्ण दोष पाता है, उसकी जिम्मेदारी है कि वह किसी तरह का झंडा फहराए

Answer 8

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

एक बात ध्यान दें, थियो, हम 4 देवों की एक छोटी सी दुकान और एक इंटर्न हैं और बग फिक्स जो संभवत: बग मैं बनाया गया है।

Answer 9

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

आपको यह याद रखना होगा कि यदि आपने इसे ढूंढ लिया है, तो संभवत: उपयोगकर्ताओं ने ऐसा नहीं किया है, या फिर उन्होंने इसकी सूचना दी होती। एक उपयोगकर्ता द्वारा कभी भी सामना नहीं किए जा सकने वाले मुद्दे को ठीक करने में समय बिताने के बजाय, आप उस समय को उन समस्याओं को ठीक करने से बेहतर कर सकते हैं जो आपके उपयोगकर्ताओं की समस्याओं का कारण बन रही हैं।

Comments

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

— क्रेग मैकक्यून

Answer 10

पहले टिप्पणियों को अच्छी तरह से दस्तावेज करें, और तय करें कि बाद में इसे ठीक करना है या नहीं।

अपने सहयोगियों के साथ कुछ औपचारिक चर्चा (जैसे, नियमित बैठक में) या अनौपचारिक चर्चा (जैसे, दोपहर के भोजन के दौरान) करें और उन परिवर्तनों के बारे में बताएं जो आपके द्वारा तय किए गए कोड के व्यवहार पर अधिक विश्वास हासिल करते हैं।

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

Answer 11

मैं यहां ट्रेंड करूंगा। जब तक आप विकास के बहुत शुरुआती प्रोटोटाइप चरण में नहीं होते हैं, आपको इसे तुरंत ठीक नहीं करना चाहिए, आपको बग रिपोर्ट दर्ज करनी चाहिए। इसके कई फायदे हैं:

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