क्या फिक्सिंग कीड़े अन्य लोगों द्वारा एक अच्छा दृष्टिकोण है?

17

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

फुर्तीली विकास (स्क्रैम) में पसंदीदा दृष्टिकोण क्या है?

agile debugging

— Robert.K
स्रोत

3

वह जिसे तेरा कोड बनाया है तेरा कोड तय करना चाहिए

— एजाइल स्काउट

35

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

— shambleh
स्रोत

1

+1 "जितनी जल्दी हो सके" के लिए। वास्तव में, आप उन्हें जल्द से जल्द ठीक कर सकते हैं और अपने उपयोगकर्ताओं को परीक्षण जारी रखने और नए बग की रिपोर्ट करने दे सकते हैं।

1

और उस व्यक्ति के बारे में क्या प्रतिक्रिया है जिसने बग की शुरुआत की?

@ रॉबर्ट यह केवल प्रतिक्रिया का विषय नहीं है। बग को सबमिटर द्वारा औपचारिक रूप से बंद करना होगा ।

10

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

— एंड्रयूस्क

1

@yegor, robert ने बग लिखने वाले के बारे में पूछा, न कि जमा करने वाले से। महत्वपूर्ण बग के लिए यह सूचित किया जाना चाहिए, तुच्छ लोगों के लिए नहीं।

8

डिफ़ॉल्ट रूप से व्यक्ति। कारण काफी सरल है: प्रतिक्रिया। कीड़े व्यक्तिगत और पेशेवर प्रतिक्रिया के लिए एक शानदार अवसर प्रदान करते हैं। अगर कोई और मेरे कीड़े तय करता है, तो मैं फिर से वही गलती करूंगा, क्योंकि मैं इससे नहीं सीखूंगा।

यदि वह व्यक्ति उपलब्ध नहीं है, तो कोई और उसे ठीक कर सकता है, लेकिन व्यक्ति को जीवन चक्र का पालन करना चाहिए।

— ज़ोल्ट
स्रोत

3

इसीलिए संचार महत्वपूर्ण है। यदि एक व्यक्ति जो बग को ठीक करता है जो मूल कोडर नहीं है, तो बताता है कि समस्या क्या है और प्रवर्तक को क्या समस्या थी, तो दो लोग इसे सीखते हैं, बजाय एक से।

— एंड्रयूज

7

एक पीएम के रूप में मैं बग को विशिष्ट डेवलपर्स से जोड़ने से बचूंगा। यदि इसे करने की आवश्यकता है तो कार्यात्मक / विकास प्रबंधक को ऐसा करने दें। टीम के साथ खुद को चिंतित करें। एक बग है जिसे टीम को ठीक करने की आवश्यकता है।

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

— अगस्त

2

मुझे नहीं पता कि इस परिदृश्य को कैसे हैंडल किया जाता है, लेकिन मेरी टीम में, हमारे पास क्रॉस टेस्टिंग / कोड रिव्यू जैसा कुछ है। इस तरह, यदि कोई बग पाया जाता है, तो डेवलपर और समीक्षक दोनों इसे ठीक करने के लिए सर्वोत्तम दृष्टिकोण पर चर्चा करते हैं।

मेरा मानना है कि जब तक समाधान फिट बैठता है, तब तक कोई फर्क नहीं पड़ता कि डेवलपर या समीक्षक इसे लागू करता है। हालांकि, डेवलपर और परीक्षक के बीच किसी भी तरह के संघर्ष से बचने के लिए महत्वपूर्ण है।

Rgds

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

— टियागो कार्डसो
स्रोत

@ टियागो: मैं आपके समाधान की सराहना करता हूं, लेकिन मुझे नहीं लगता कि चर्चा हमेशा आवश्यक है।

— लॉन्ग

1

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

1

मैं पूरी तरह से स्टीवन के साथ सहमत हूं कि कोड सभी टीम से संबंधित है; और कुछ और कारण हैं जो आपको उनके रचनाकारों को बग नहीं देना चाहिए:

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

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

— लंबे समय तक
स्रोत

1

बग को ठीक करने वाले देखभाल के लिए केवल तीन कारण हैं: लागत, गति और पेशेवर विकास।

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

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

— jmoreno
स्रोत

1

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

— श्यामला
स्रोत

0

इस बारे में सोचें: बग के बारे में अधिक जानकारी किसके पास है? विकास दल।

तो वे तय करते हैं कि बग के साथ क्या करना है। वे कोड के स्वामी हैं , इसलिए वे इसके लिए जिम्मेदार हैं।

आप बग फिक्स के लिए प्रोजेक्ट स्कोप पर कुछ समय आवंटित करके और उन्हें अकेले ही काम करने देने में मदद कर सकते हैं ।

कई निर्णय लेने से बचें जहां आपको (पीएम की भूमिका के रूप में) टीम की तुलना में कम जानकारी है।

इसके बारे में प्रश्न देखें: सॉफ्टवेयर डेवलपमेंट टीम को माइक्रो-मैनेज करने से कैसे बचें?

— छोकरा
स्रोत

0

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

फिर आप कोडर्स को दिखा सकते हैं, यह दिखाने के लिए कि वे बग कैसे पैदा कर रहे हैं।

और बग को रोकने का सबसे अच्छा तरीका है, हर किसी को उन्हें ठीक करने के साथ शामिल करना। मेरा मतलब है कि बग का कारण बनने वाले दौर के अनुभव देने और उन्हें ठीक करने के लिए अलग-अलग लोगों को बग फिक्स करना।

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

— crosenblum
स्रोत

0

जब एक बग पाया जाता है, तो इसे ठीक करने के लिए पूरे विकास दल की जिम्मेदारी होती है।

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

व्यक्तियों को यह महसूस करने की आवश्यकता है कि वे एक टीम का हिस्सा हैं और समझते हैं कि कोड, इसकी जिम्मेदारियों के साथ, उन सभी का है। एक परियोजना की सफलता सभी टीम के सदस्यों पर टिकी हुई है।

— ampersandre
स्रोत