यह सत्यापित करने के लिए कि एक रिफैक्टरिंग मूल कोड

Question

के बराबर है, मैं किसी यूनिट-टेस्ट के बिना विरासत जावा कोड के साथ काम कर रहा हूं। परियोजना के साथ काम करने के लिए कई वर्गों को दोबारा सुधारने की जरूरत है।

ग्रहण के साथ कई रिफैक्टरिंग किए जा सकते हैं, और क्या मैं कुछ हाथ से कर रहा हूं। कुछ रिफैक्टरिंग के बाद मैं सीवीएस-हेड में भिन्नता की समीक्षा करता हूं, लेकिन मैं वास्तव में यह महसूस नहीं कर सकता कि सबकुछ 100% सही है।

प्रश्न: मैं रीफैक्टरिंग को कैसे सत्यापित कर सकता हूं, गणितीय पिछले संस्करण के समान है? मेरी इच्छा है कि एक उपकरण था, लेकिन मैं समाधान के रूप में "मूल मानव एल्गोरिदम" भी स्वीकार करता हूं।

मुझे पता है, "अपने जुनीट टेस्ट चलाएं" सबसे अच्छा जवाब है, लेकिन दुख की बात है, मेरी परियोजना में कोई भी नहीं है।

धन्यवाद!

Answer 1

"TDD By Example" में एक विशिष्ट खंड है जो इसके बारे में बात करता है। समस्या यह है कि आपको रिफैक्टर के लिए यूनिट परीक्षण की आवश्यकता होती है, लेकिन एक जटिल कोड आमतौर पर गैर-परीक्षण योग्य होता है। इस प्रकार, आप इसे टेस्ट करने योग्य बनाने के लिए रिफैक्टर करना चाहते हैं। साइकिल।

छोटे रिफैक्टरिंग चरणों कार्य करें:

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

जैसे ही कोई विधि/कक्षा परीक्षण योग्य हो जाती है, इसके लिए यूनिट परीक्षण लिखें।

इस प्रक्रिया को दोहराने से धीरे-धीरे आपको उस स्थिति में ले जाया जाएगा जहां आपके पास परीक्षण हैं और इस प्रकार आप अधिक आक्रामक रूप से प्रतिक्रिया दे सकते हैं। आम तौर पर, यह प्रक्रिया अपेक्षा से कम होती है।

Answer 2

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

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

शायद इसके समय आपने यूनिट परीक्षणों को लिखा था जो आपको बहुत कम लग रहा है?

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

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

Answer 3

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

Answer 4

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

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

यदि यह एक जीयूआई है, तो मुझे उम्मीद है कि इसमें एमवीसी अलगाव होगा ताकि आप मॉडल को अलग से जांच सकें, अन्यथा आप अटक जाएंगे।

Answer 5

प्रश्न

: मैं एक रिफैक्टरिंग मान्य कर सकते हैं कैसे, कि गणितीय है पिछले संस्करण के समान? I एक उपकरण था, लेकिन मैं भी समाधान के रूप में "मूल मानव एल्गोरिदम" स्वीकार करता हूं।

सच पूछिये तो, refactorings प्रसिद्ध परिवर्तन का एक सेट जो संरक्षण के लिए कोड का अर्थ विज्ञान साबित किया गया है कर रहे हैं। Refactoring Object-Oriented Frameworks देखें। अन्य सभी को पुन: इंजीनियरिंग कहा जाना चाहिए, लेकिन मैं मानता हूं कि दोनों एक दूसरे के लिए उपयोग किए जाते हैं।

अर्थशास्त्र संरक्षण के बारे में तर्क कठिन है, और यह एक खुला शोध विषय है। उदाहरण के लिए देखें Formalising Behaviour Preserving Program Transformations।

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

Answer 6

प्रश्न: मैं एक रिफैक्टरिंग को कैसे सत्यापित कर सकता हूं, जो पिछले संस्करण के समान गणितीय है? मेरी इच्छा है कि एक उपकरण था, लेकिन मैं समाधान के रूप में "मूल मानव एल्गोरिदम" भी स्वीकार करता हूं।

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

AOP उपयोग अपने विधि के शुरू में और अंत में अपने वस्तु राज्य और मानकों 'डंप' के लिए:

Answer 7

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

फिर उस कोड के साथ कई परिदृश्य रिकॉर्ड करें जिन्हें आपको बदलने और अपने रिफैक्टर कोड का उपयोग करके उन्हें फिर से चलाने की आवश्यकता है।

यह गणितीय नहीं है, यह स्थापित करने के लिए थोड़ा भारी है, लेकिन गैर-रिग्रेशन परीक्षणों का एक अच्छा सेट प्राप्त करने के बाद।

डम्पर XStream जैसे टूल के साथ सेट अप करना आसान है।

Answer 8

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

अधिक जानकारी here उपलब्ध है।

Answer 9

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

Answer 10

मुझे आश्चर्य है कि अब तक किसी ने माइकल फेदर द्वारा Working Effectively with Legacy Code पुस्तक का उल्लेख नहीं किया है। यह विभिन्न भाषाओं में बहुत सारी व्यावहारिक सलाह के साथ, इस सटीक स्थिति से संबंधित है। मैं विरासत परियोजनाओं से निपटने वाले किसी को भी इसकी सलाह देता हूं।