2008-08-21 11 views
5

मैं एक ऐसी कंपनी में शामिल हो गया हूं जो किसी उत्पाद पर काम करता है। यह उत्पाद ~ 5 साल या उससे भी अधिक समय तक रहा है, और एएसपी.नेट वेबफॉर्म का उपयोग करता है। इसका मूल वास्तुकला समय के साथ फीका है, और चीजें समाधान के दौरान अपेक्षाकृत असंगठित हो गई हैं। यह किसी भी तरह से भयानक नहीं है, लेकिन निश्चित रूप से कुछ काम का उपयोग कर सकते हैं; आप सब जानते हैं कि मेरा क्या मतलब है।मौजूदा सिस्टम पर टेस्टेबिलिटी के लिए रिफैक्टरिंग

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

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

क्या किसी के पास कोई अनुभव है कि कार्रवाई का सर्वोत्तम तरीका क्या है? मेरे पास अपने विचार हैं, लेकिन समुदाय से कुछ इनपुट सुनना चाहते हैं।

उत्तर

5

आपके पीएम की चिंताओं वैध हैं - सुनिश्चित करें कि आप किसी भी बड़े रिफैक्टरिंग करने से पहले अपने सिस्टम को परीक्षण के तहत प्राप्त करें।

मैं दृढ़ता से माइकल फेदर की पुस्तक Working Effectively With Legacy Code ("विरासत संहिता" पंखों का एक प्रति प्राप्त करने की अनुशंसा करता हूं जिसका मतलब है कि किसी भी प्रणाली जो यूनिट परीक्षणों द्वारा पर्याप्त रूप से कवर नहीं है)। यह उन विचारों और निर्भरताओं को तोड़ने के तरीके के बारे में अच्छे विचारों से भरा हुआ है, जो सुरक्षित तरीके से हैं, जो कि रिग्रेशन बग को पेश करने का जोखिम नहीं उठाएंगे।

रिफैक्टरिंग कार्यक्रम के साथ शुभकामनाएं; मेरे अनुभव में यह एक सुखद और कैथर्टिक प्रक्रिया है जिससे आप बहुत कुछ सीख सकते हैं।

2

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

0

लीगेसी कोड के साथ प्रभावी रूप से कार्य करने के लिए दूसरी सिफारिश को फेंकना, एक उत्कृष्ट पुस्तक जिसने वास्तव में इस तथ्य को अपनी आंखें खोलीं कि लगभग किसी भी पुराने/क्रैपी/अवांछित कोड को झुकाया जा सकता है!

1

मैं मार्टिन फाउलर द्वारा Refactoring वेबसाइट पर जाने के लिए एक सुझाव में फेंकना चाहूंगा। उन्होंने सचमुच इस सामान पर पुस्तक लिखी।

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

यूनिट परीक्षण एएसपी.Net मुश्किल हो सकता है, लेकिन वहां कई ढांचे हैं जो इसे करना आसान बनाता है। ASP.Net MVC, और WCSF कुछ नाम देने के लिए।

0

Ian Nelson से उत्तर के साथ पूरी तरह से सहमत हैं। इसके अतिरिक्त मैं उपयोगकर्ता के दृश्य बिंदु से व्यवहार को संरक्षित करने के लिए कुछ "उच्च स्तरीय" परीक्षण (कार्यात्मक या घटक परीक्षण) प्राप्त करना शुरू कर दूंगा। यह बिंदु आपके पीएम के लिए सबसे महत्वपूर्ण चिंता हो सकती है।

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