क्या कोई ऐसा बिंदु है जहां रिफैक्टरिंग की लागत फिर से लिखने की लागत से अधिक है?

Question

हमारे पास रोजगार की वर्तमान जगह पर अगली पीढ़ी के ढांचे के रूप में कुछ वाकई चौंकाने वाला कोड है।

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

जिस व्यक्ति ने इसे लिखा वह प्रबंधन के साथ एक बहुत ही प्रभावशाली स्थिति है ताकि वे शिविर के उस तरफ हों।

हमने प्रबंधन के लिए (वास्तविक) चिंताओं को हाइलाइट किया है लेकिन जाहिर है कि वे ऐसी परियोजना में अधिक समय देने के इच्छुक नहीं हैं जो सीधे नीचे की रेखा में योगदान नहीं दे रहा है।

इस ढांचे पर तैनात कई अनुप्रयोग हैं इसलिए किसी भी रिफैक्टरिंग को उन अनुप्रयोगों को शामिल करने की आवश्यकता होगी।

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

हालांकि इसमें लाइव तैनाती में 3 साल और कई बग फिक्स, कोने के मामलों और सीमा शर्तों के लिए कैटर किया गया है।

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

Answer 1

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

रिफैक्टरिंग लगभग निश्चित रूप से सही उत्तर है। मेरे पास PHP का पुन: उपयोग करने का कोई अनुभव नहीं है (मैं सी ++ और सी # करता हूं), इसलिए मैं कोई विशिष्ट सलाह नहीं दे सकता। आपको बच्चे के कदमों के साथ आगे बढ़ना है।

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

लेकिन: कोड को फिर से लिखने के लिए सब कुछ न छोड़ें। धीरे-धीरे रिएक्टर। यह आपको थोड़ा धीमा कर देगा, लेकिन आप अभी भी मूल्य प्रदान करेंगे जैसे आप साथ जाते हैं।

this article देखें जो आपको आपके प्रबंधन में तकनीकी ऋण की व्याख्या करने में मदद करेगा। यह भी समझाएगा कि उन्हें क्यों परवाह नहीं है।

Answer 2

बनाने के लिए कोई वास्तविक कठोर निर्णय है कि ...

समस्या मैं यहाँ देख रहा है, उस ढांचे का इस्तेमाल किया और एक लंबे समय और चलाने के लिए गुणवत्ता तो वहाँ ज्ञान का एक बहुत यह में चला गया के लिए तय हो गई है परियोजनाएं स्पष्ट रूप से स्वीकार्य है।इसलिए यदि आप इसे जानते हुए सभी आवश्यकताओं के साथ स्क्रैच से पुनः लिखते हैं - तो आप यह सुनिश्चित कर सकते हैं कि आप पहले से ही काम करने वाले किसी व्यक्ति को भूल जाएंगे (एक ग्राहक को - या आपके मालिक को समझाने के लिए कठिन;))

इसे पुन: सक्रिय करना - यह लगता है - के बाद से वहाँ केवल एक पुरुष, जो वास्तव में कोड के भीतर कनेक्शन जानता है यह भी एक मुश्किल काम है - जो इसे बदलने के लिए नहीं चाहता है ...

तीन विकल्प हैं:

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

किसी भी तरह से आप इसे डाल दिया है - यह हर किसी के लिए एक बुरी स्थिति है ... समय के साथ के बाद से ढांचे के लिए ज़िम्मेदार व्यक्ति द्वारा गुज़रने से इसे खुद से निपटना होगा और फिर शायद यह बहुत देर हो चुकी है।

Answer 3

पुनर्लेखन का लाभ यह है कि आप विश्लेषण चरण में सभी नई चीजें ध्यान में रख सकते हैं, वर्तमान मॉडल के लिए एक मॉडल को अधिक अनुकूल बना सकते हैं। दूसरी ओर, अगर यह केवल बुरी तरह कोडित है, बुरी तरह से डिजाइन नहीं किया गया है, तो पूरी तरह से लिखने में कोई बात नहीं है। बस कोड को sanitize/refactor।

Answer 4

एक छोटे से स्तर पर, हाँ: एक फ़ंक्शन का एक नया संस्करण प्रदान करें, सत्यापित करें कि यह नए और पुराने के साथ काम करता है, पुराने को हटा दें। यह funciton खुद को refactoring से अक्सर पर्याप्त तेज़ है। लेकिन उस स्तर पर, यह refactoring :)

रणनीतिक एक पुनर्लेख की लागत वस्तुतः हमेशा refactoring से अधिक है।

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

---

हाँ परिदृश्यों जहां पुनर्लेखन सस्ता है का निर्माण किया जा सकता है:

• मूल कोड बेस तो spaghettied जाता है कि किसी भी स्थानीय संशोधन टूट जाता है दूसरे से असंबद्ध लगने सुविधाओं।
• आपके पास वास्तव में एक महान नई टीम है, जो पुराने लोगों की तुलना में काफी बेहतर है, लेकिन मौजूदा कोड बेस के साथ उनका कोई अनुभव नहीं है, और मौजूदा कोड बेस एक गड़बड़ है, या ऐसी भाषा में जिसे वे नहीं जानते हैं, या कुछ उसके जैसा।

---

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

Answer 5

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

Answer 6

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