2010-09-17 4 views
5

मैंने हाल ही में माइकल सी फेदर्स की पुस्तक Working effectively with legacy code पढ़ी और उस बिंदु पर आया जहां उन्होंने स्वचालित रिफैक्टरिंग टूल की सुरक्षा का परीक्षण करने के लिए एक तरीका बताया।क्या .NET (या कम से कम सी #) के लिए कोई सुरक्षित रिफैक्टरिंग उपकरण है?

मेरा प्रश्न है: क्या .net प्लेटफ़ॉर्म के लिए कोई सुरक्षित रिफैक्टरिंग टूल हैं?; इसका मतलब है औजार जो केवल वास्तविक रिफैक्टरिंग और उदा। निम्नलिखित उदाहरण में temp चर पर inline variable रीफैक्टरिंग की अनुमति न दें, या कम से कम एक चेतावनी दिखाएं कि मैं तर्क बदल रहा हूं।

class Program 
{ 
    private static int _x; 

    static void Main() 
    { 
     int temp = Test(); 
     for (int i = 0; i < 10; ++i) 
     { 
      Console.WriteLine(temp); 
     } 
     Console.ReadKey(); 
    } 


    private static int Test() 
    { 
     return ++_x; 
    } 
} 

मैं रिफैक्टरिंग उपकरण Resharper और Coderush + Refactor pro नवीनतम संस्करणों के साथ और दोनों पर इस उदाहरण परीक्षण किया है और परीक्षण विफल करने के लिए पुनर्रचना की अनुमति दी:

class Program 
{ 
    private static int _x; 

    static void Main() 
    { 
     for (int i = 0; i < 10; ++i) 
     { 
      Console.WriteLine(Test()); 
     } 
     Console.ReadKey(); 
    } 

    private static int Test() 
    { 
     return ++_x; 
    } 
} 
+0

आप एक उपकरण है जो * * भी एक अलग भाषा के लिए, जिस तरह से आप चाहते हैं प्रदर्शन करेंगे का एक उदाहरण है? –

+1

असल में मैं यह चाहता हूं कि टूल इस विशेष रिफैक्टरिंग की पेशकश नहीं करेगा या किसी प्रकार की चेतावनी दिखाएगा कि इससे कोड का तर्क बदल जाएगा। चूंकि एक रिफैक्टरिंग को तर्क नहीं बदलना चाहिए, विकिपीडिया पर परिभाषा देखें: http://en.wikipedia.org/wiki/Refactoring। – RoXX

उत्तर

5

स्वचालित रिफैक्टरिंग के साथ वास्तव में सुरक्षित होना बहुत कठिन है।

जब हमने पहली बार विज़ुअल सी # में रेफैक्टरिंग शुरू की, तो हमने खुद से यह प्रश्न पूछा: क्या हमारे रिफैक्टरिंग को हर समय चीजों को पूरी तरह से सही करने की आवश्यकता होती है, या क्या हमें उन्हें कुछ मामलों में गलतियों की अनुमति देनी चाहिए?

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

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

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

इसके अलावा, सी # टीम के रूप में, हम उच्च-निष्ठा रिफैक्टरिंग करने के लिए एक अच्छी स्थिति में थे। हमारे पास हॉल के नीचे सी # भाषा डिजाइनर और कंपाइलर टीम के साथ एक अनोखा फायदा था। हम जानते थे कि हमें अपनी ताकत के लिए खेलना चाहिए।

तो, हमने बहुत से रिफैक्टरिंग की बजाय कम उच्च गुणवत्ता वाले रिफैक्टरिंग करने का निर्णय लिया जो विश्वसनीय नहीं थे। आज 6.

Visual Studio Refactorings

वापस देख रहे हैं देखते हैं, काश हम केवल किया था नाम बदलें, निकालें विधि, और स्थानीय चर परिचय दें। उन अंतिम दो लगभग समान हैं, कार्यान्वयन के अनुसार। 3 पैरामीटर रिफैक्टरिंग (वहां 7 वां होता था, पैरामीटर के लिए स्थानीय वैरिएबल को बढ़ावा दिया जाता था, लेकिन इसे वीएस -2010 में काटा गया था) सही होने के लिए काम का एक टन था, और शायद इसके लायक नहीं थे।

मेरी सिफारिश है टीडीडी, आपको परीक्षणों का एक बड़ा संग्रह दे ताकि आप सुरक्षित रूप से पुन: सक्रिय कर सकें, चाहे आप किसी उपकरण का उपयोग करें या हाथ से करें।

10

पुनर्रचना स्वाभाविक जोखिम भरा है। अपने कोड को सुरक्षित बनाने के लिए पूरी तरह से एक उपकरण पर निर्भर करना मूर्खतापूर्ण आईएमओ है।

हम रिजर्वर का उपयोग करते हैं लेकिन व्यापक यूनिट परीक्षणों के सुरक्षा नेट के बिना नहीं। मुझे इस जगह में किसी भी बेहतर सी # उपकरण से अवगत नहीं है।

+1

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

+2

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

2

"सुरक्षित" बल्कि व्यक्तिपरक है ....

उन दो उपकरण आपके मन में इस परीक्षण के आधार पर "सुरक्षित" नहीं माना जाना बना दिया जबकि उन उपकरणों के दोनों अत्यंत उपयोगी होते हैं। कोई उपकरण सही नहीं है। यदि ऐसी स्थिति है जहां वे ऐसा कुछ करते हैं जिसे आप पसंद नहीं करते हैं या तो इसे करने से बचें या आसपास काम करें।

5

मैं असहमत हूं कि आपका "परीक्षण" विफलता दिखाता है।

आपने तर्क बदल दिया, उपकरण नहीं। आपने कोड को बदल दिया है कि एक विधि को बार-बार एक बार कहा जाएगा।

उपकरण केवल वही किया जो आपने उन्हें करने के लिए कहा था।

+0

यूप। यही कारण है कि प्रत्येक रिफैक्टरिंग के बाद आपको अपने कोड का परीक्षण करना चाहिए ताकि जब आप तर्क बदलते हैं तो * पता *। – strager

+0

यदि ऑप ने वास्तव में गलती पेश की है, तो मैं ओपीएस कथन स्वीकार करूंगा, जैसे एक कथन का उपयोग करते हुए एक उलटा उपयोग करते हुए, जिसके परिणामस्वरूप एक अलग तार्किक परिणाम हुआ। –

+2

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

0

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

http://www.dsc.ufcg.edu.br/~spg/saferefactor/

संबंधित मुद्दे