रैंडम रूप से रीफैक्टरिंग कोड को अनुमति दी गई है


23

पृष्ठभूमि

  • मेरी टीम स्क्रैम का उपयोग करती है
  • मेरे पास वर्तमान में कोई कार्य असाइन नहीं किया गया है
  • बैकलॉग में अधिक लंबित कार्य नहीं हैं
  • आज मेरे मुवक्किल के लिए मजदूर दिवस है

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

क्या यह स्क्रैम में ठीक है अगर मैं बेतरतीब ढंग से रिफैक्टिंग कोड शुरू करता हूं जो मेरे पास है और यह नहीं लिखा है कि हमेशा मुझे परेशान करें लेकिन अन्य दिनों के असाइनमेंट के कारण इसे ठीक करने के लिए अन्य दिनों का समय नहीं है?

क्या अन्य दिनों के बारे में है कि मैं स्प्रिंट के बीच खाली समय है।

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



मुझे लगता है कि यह पूरी तरह से राय आधारित नहीं है क्योंकि मैं विशेष रूप से स्क्रैम प्रक्रिया के बारे में पूछ रहा हूं।
कार्लोस मुनोज

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

@ B onовиЈ नहीं, मैंने 1 सितंबर को प्रश्न
कार्लोस मुनोज़

1
@ BondовиЈ मजदूर दिवस अमेरिका में सितम्बर का पहला सोमवार है। पहली मई अंतर्राष्ट्रीय श्रमिक दिवस है। अमेरिका में नहीं होने के कारण मुझे मजदूर दिवस पर काम करने को मिलता है
कार्लोस मुनोज

जवाबों:


29

मुझे वास्तव में अन्य उत्तरों पर हमला करने का मतलब नहीं है, लेकिन कोई और यहां स्वचालित परीक्षण लिख रहा है? यहाँ उचित सॉफ्टवेयर इंजीनियरिंग प्रथाओं के बिना Scrum कर रहे किसी के लिए मार्टिन Fowler से एक मजेदार पढ़ने है। रॉबर्ट सी। मार्टिन भी इस बारे में यहाँ बहुत कुछ कहते हैं

तो, मेरे जवाब के लिए ... संक्षेप में, यह इस प्रकार है:

हां, "बेतरतीब ढंग से" रिफैक्टिंग कोड को स्क्रैम में अनुमति दी जाती है , जब तक कि टीम तय करती है कि यह किया जाना चाहिए। (आखिरकार, यह आत्म-आयोजन है)

और अब लंबे उत्तर के लिए:

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

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

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

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


1
बहुत सुरक्षित होने पर विचार करने के लिए पर्याप्त परीक्षण कवरेज क्या है? बग्स को ठीक करने के उद्देश्य के बिना बेतरतीब ढंग से काम करने वाले कोड को बदलना हमेशा एक जोखिम होता है।
पेट्टर नॉर्डलैंडर

5
परीक्षणों की कोई भी मात्रा पूरी तरह से सुरक्षित नहीं है। SQLite सॉफ्टवेयर के सबसे अधिक परीक्षण किए गए टुकड़ों में से एक है, कुल शाखा कवरेज के साथ, फिर भी वे हर समय आपातकालीन बगफिक्स रिलीज करते हैं।
Jan Hudec

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

1
मैं इस बात से असहमत नहीं हूं कि रिफैक्‍टोरिंग एनसेसेरी है। हालाँकि, भले ही आपके पास श्वेत / ब्लैक बॉक्स परीक्षण तकनीकों का उपयोग करके 100% कवरेज हो, व्यवहार में बदलाव न करने और अप्रत्याशित बग को पेश करने की संभावना शून्य के पास कहीं भी नहीं है। एक बार एक कक्षा कोडित हो जाने के बाद, मुझे लगभग कभी भी उस कक्षा में परिवर्तन नहीं दिखाई देता है। वह जगह नहीं है जहाँ कीड़े होते हैं। अधिकांश बग तब होते हैं जब एक वर्ग बदलता है क्योंकि यह सिस्टम के संबंध में "थोड़ा" अलग व्यवहार करता है, भले ही यह अभी भी "तकनीकी रूप से" एक ही काम करता है। उदाहरण के लिए, बस थ्रेड को सुरक्षित बनाया गया है, ऊओप्स अब कार्य विफल रहता है क्योंकि इसकी कॉल अवरुद्ध है।
डंक

2
100% कोड कवरेज बग्स की शुरूआत को पूरी तरह से नहीं रोकता है। यद्यपि कोड की प्रत्येक पंक्ति का परीक्षण किया जाता है, लेकिन हर संभावित कार्यक्रम की स्थिति का कभी भी परीक्षण नहीं किया जाएगा।
bdsl

11

स्क्रम वास्तव में रिफैक्टरिंग के बारे में कुछ नहीं कहता है।

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


4

मैं कहूंगा कि यह नहीं है। यह काम के प्रकार (रिफैक्टिंग, आदि) की परवाह किए बिना है।

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

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


1

मैं नहीं के रूप में अच्छी तरह से कहने जा रहा हूँ। यदि यह सही तरीके से प्रबंधित नहीं किया जाता है तो री-फैक्टरिंग अक्सर अनजाने बग्स की ओर जाता है।

एक जीएम के रूप में, समय-समय पर मैं हर किसी को किसी अन्य परियोजना पर रखूंगा और एक सप्ताह कोड समीक्षा / पुनः-फैक्टरिंग / नाम बदलने और एक परियोजना पर सम्मेलनों को लागू करने में खर्च करूंगा। ये री-फैक्टरिंग स्प्रिंट्स लगभग हमेशा प्रकृति में कॉस्मेटिक होंगे। किसी भी कार्यात्मक पुन: फैक्टरिंग की योजना समय से पहले बनाई जाएगी और मूल डेवलपर को शामिल किया जाएगा।

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

यदि यह एक ऐसी परियोजना है, जिसके आप एकमात्र अनुचर हैं और यह आपका अपना खाली समय है, तो यह सुनिश्चित करने के लिए कि आप अपने वर्तमान स्प्रिंट में अनावश्यक देरी का कारण नहीं हैं, यह सुनिश्चित करने के लिए अलग-अलग कदम उठा सकते हैं।

जब संदेह हो, तो अपने प्रबंधक से पूछें।

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


1
"कॉस्मेटिक रीफैक्टरिंग" से आपका क्या अभिप्राय है?
B:30ови

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

1

स्क्रमम रिफैक्टरिंग के बारे में कुछ नहीं कहता है (रॉबर्ट सी। मार्टिन का एक व्याख्यान देखें, "जो भूमि भूल गया था")।

स्कैम कार्यों में ग्राहक द्वारा निर्दिष्ट आपके सॉफ़्टवेयर की सुविधाओं को लक्षित कर रहे हैं, न कि तकनीकी ऋणों को रीफ़ैक्टरिंग द्वारा चुकाने के लिए। ये पूरी तरह से अलग अमूर्त स्तर हैं। ग्राहक ज्यादातर नेकनेस का मूल्यांकन करने में सक्षम नहीं होता है।

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

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

यदि आप अभी भी कार्यों को फिर से करने के बारे में सोचते हैं, तो आपके पास दो समस्याएं हैं: 1. एक ग्राहक, जो समझ नहीं पाता है, क्यों उसे एक ऐसे कार्य को स्वीकार करना पड़ता है जो एक नई सुविधा का उत्पादन नहीं करेगा 2. आप अपने आँकड़ों को पूरी तरह से विकृत कर देते हैं और इसलिए आपके पूर्वानुमान की क्षमता जैसा कि आप अचानक एक अलग चर को बदलते हैं जो पिछले स्प्रिंट में नहीं माना जाता था

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

रिफैक्टरिंग ज्यादातर समय एक भूमिगत कार्य है। "महान" रिफ्लेक्टरिंग का अर्थ है कि "छोटे" रिफैक्टोरिंग को अतीत में संसाधित नहीं किया गया है।

एक अंतिम नोट: यदि आप रिफ्लेक्टरिंग करते हैं तो सुनिश्चित करें कि आपके पास परीक्षण के तहत घटक है जो आप रिफलेक्ट कर रहे हैं। ओह, आपके पास परीक्षण नहीं हैं? परीक्षण लिखने के लिए एक कार्य करें। आपका ग्राहक यह जानकर खुश होगा कि वर्तमान में वह जिस सॉफ्टवेयर का उपयोग कर रहा है, उसमें पर्याप्त परीक्षण कवरेज नहीं है ...

तकनीकी सामान को ग्राहक से दूर रखें और एक पेशेवर डेवलपर के रूप में अपना काम करें।


0

यहाँ एक दृष्टिकोण है: दोनों करो!

रिफैक्टिंग अक्सर त्रुटि-प्रवण या अधिक समय लेने वाली होती है जो मूल रूप से @misterbiscuit के रूप में अनुमानित होती है।

तो इसे एक मसौदा या एक स्पाइक करने के प्रयास पर विचार करें। यदि आप इस चरण में अनुमोदन या विज्ञापन प्राप्त करने के लिए नहीं हैं।

फिर, इसे दो चैनलों में से एक के माध्यम से शामिल करने के लिए देखें:

  • एक मौजूदा टिकट जो समान कोड / कार्यक्षमता को छूता है जहां आप इसे उचित रूप से लपेट सकते हैं। यथोचित रूप से साथी टीम के सदस्यों के साथ सहमति व्यक्त की जाती है।
  • अगले टिकट की समीक्षा के लिए पूरे टिकट (या साप्ताहिक बैठक आदि) यदि झरना हो तो। उस समय आप इसके लिए केस कर सकते हैं।

एक बार जब आप वास्तविक खरीद-प्राप्त कर लेते हैं, तो आप अपनी स्पाइक को लागू करने या फिर से देखने के लिए देख सकते हैं और वास्तविक कोड को मेनलाइन (मास्टर, आदि) शाखा में विलय कर सकते हैं।

इसके कई फायदे होंगे:

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

एक अंतिम टिप्पणी: 'यादृच्छिक' शब्द सुनने वाले उत्पाद प्रबंधक से बचें। वे 'लक्षित, रणनीतिक, प्रदर्शन को बढ़ाने वाले' कोड उन्नयन के साथ अधिक अनुकूल प्रतिक्रिया दे सकते हैं। या एप्लिकेशन सर्विस पैक। या जो भी भाषा आपको कवरेज देती है।


0

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

  • एक डिजाइन या वास्तुकला की समस्या को ठीक करना
  • कार्यान्वयन में सुधार

क्या यह स्क्रैम में ठीक है अगर मैं बेतरतीब ढंग से रिफैक्टिंग कोड शुरू करता हूं जो मेरे पास है और यह नहीं लिखा है कि हमेशा मुझे परेशान करें लेकिन अन्य दिनों के असाइनमेंट के कारण इसे ठीक करने के लिए अन्य दिनों का समय नहीं है?

से इस उत्तर :

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

मेरे पिछले काम में, हमारे पास कुछ प्रकार के घोटाले थे, जिसमें बड़े स्प्रिंट (2-3 महीने) थे। चूंकि हमारे पास स्प्रिंट्स (1 महीने) के बीच कुछ देरी थी, इसलिए हमने इस समय का उपयोग सॉफ्टवेयर का विश्लेषण करने के लिए किया, और कोड को रिफलेक्टर किया।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.