कोड रीफैक्टरिंग समय को कैसे सही ठहराया जाए?

Question

70k LOC से अधिक की एक बहुत बड़ी परियोजना है।

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

एक उचित सॉफ्टवेयर विकास सिद्धांत पर बहस करने और बचाव करने में आपके प्रमुख बिंदु क्या होंगे?

Comments

70k LOC बहुत बड़ी परियोजना नहीं है। मैं इसे छोटा

— कहूंगा

@ B @овиЈ सच है, मुझे सिंगल सोर्स फाइल्स विरासत में मिली हैं, जिसमें 10k एलओसी के कई गुणक थे

— जेम्स

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

— B38овиЈ

Answer 1

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

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

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

Comments

उफ़, एक हाथी की कोशिश कभी नहीं की

— जैकी चैन

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

— चापलूसी

हमने लड़के का स्काउट नियम किया। तब तक काम करता है जब तक कोई छोटा सा काटे नहीं छूटता। ऐसे हिस्से हैं जो इतने उलझ गए हैं कि उस पर समय बिताने के अलावा और कोई रास्ता नहीं है।

— atoth

Answer 2

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

यदि यह छोटे वेतन वृद्धि में नहीं किया जाता है, तो यह वास्तव में रिफैक्टिंग नहीं है, एह?

Answer 3

यहां सभी अच्छे उत्तर हैं - लेकिन क्या मैं इसमें एक व्यावसायिक आयाम जोड़ सकता हूं। मैं तुमसे पूछता हूँ क्यों / तो क्या? (अपने नुकीले बालों के मालिक (PHB) के बारे में सोचें :)

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

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

अगर आपको लगता है कि मैं इस पुस्तक की कोशिश कर सब कुछ कैसे माप सकता हूं

Answer 4

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

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

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

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

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

Comments

एक ही उम्मीद कर सकता है कि आपके प्रोजेक्ट में विफल होने के लिए परीक्षण हो ...

— रिग

@ अगर वहाँ नहीं हैं, तो मैं कुछ लिखकर शुरू करूँगा। हर बग आपको लगता है, एक परीक्षण लिखें जो इसे ठीक कर देगा। कहीं न कहीं से आपको प्रारंभ करना होगा। यदि आप उद्देश्यपूर्ण रूप से यह कहने में सक्षम नहीं हैं कि "मैंने कुछ नहीं तोड़ा है"।

— जॉन लीयोन

Answer 5

कल्पना करें कि आप एक लंबी और विशाल दीवार के सामने हैं। आपको दूसरी तरफ जाने की आवश्यकता है।

या तो आप एक दरवाजा बनाने के लिए दीवार को रिफलेक्टर करते हैं, या आप उसके चारों ओर जाते हैं।

दोनों समाधानों के लिए समय का अनुमान लगाएं और आप रिफैक्टरिंग के लिए अपना औचित्य प्राप्त करें।

दीवार के दूसरी तरफ जाने के लिए आवश्यक लोगों की संख्या से दूसरे समाधान में समय को गुणा करना न भूलें।

Answer 6

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

Answer 7

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

साथ ही, रिफैक्टरिंग निरंतर प्रक्रिया होनी चाहिए और रिफैक्टरिंग पर समय बिताने को विकास कार्य में ही शामिल किया जाना चाहिए। विशेष "रीफैक्टरिंग कार्य" होना अच्छा विचार नहीं है।