एक विरासत अनुप्रयोग में एक सुसंगत वास्तुकला शुरू करना

Question

मेरे पास एक बड़ी Asp.Net आधारित वेबसाइट की जिम्मेदारी है। यह वर्तमान में एक वेबसाइट है (वेब ​​अनुप्रयोग नहीं), कुछ विंडोज़ सेवाएं और कई कक्षा पुस्तकालय हैं।

डेटा लेयर LLBLGEN और Linq To LLBGen के मिश्रण का उपयोग करता है , साथ ही साथ विरासत इनलाइन एसक्यूएल के कई उदाहरण हैं जिन्हें फिर से काम नहीं किया गया है।

कुछ प्रबंधक प्रकार के कार्यान्वयन हैं, लेकिन कई मामलों में एप्लिकेशन स्मार्ट UI एंटी-पैटर्न प्रदर्शित करता है (यानी कोड के पीछे बहुत अधिक व्यावसायिक तर्क)

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

मेरा सवाल है कि कहां से शुरू करें? हमारे पास 10 साल का कोड है (इसमें से कुछ अभी भी बस एएसपी क्लासिक सामान माइग्रेट किए गए हैं), कई अलग-अलग दृष्टिकोण और शैली।

संपूर्ण कोड आधार को फिर से भरना यथार्थवादी नहीं है और, शायद वांछनीय नहीं है

मुझे पता है कि यह एक उपन्यास की स्थिति नहीं है, क्या इस समस्या से निपटने के लिए कोई उपयोगी विचार या अवधारणाएं हैं?

Comments

"वांछनीय नहीं" लेख, खरोंच से फिर से लिखना है न कि वह सब कुछ refactor। और आप हमेशा के लिए रिफ्लेक्टर करना चाहते हैं।

— रेयनोस

के संभावित डुप्लिकेट क्या अपरिचित, संरचनात्मक रूप से अस्वस्थ कोड में कार्यक्षमता जोड़ने के लिए सबसे प्रभावी तरीका है?

— gnat

Answer 1

मैं भी इसी तरह की परिस्थितियों में काम कर रहा हूं और मैं आपको निम्नलिखित सलाह दे सकता हूं।

1. आपको तकनीकी ऋण को कम करने की आवश्यकता है । अभी। क्यों? क्योंकि तकनीकी ऋण वित्तीय ऋण की तरह है। आप इस पर ब्याज देंगे।
2. चूंकि संपूर्ण कोड आधार को फिर से भरना संभव नहीं है, इसलिए अपने आप से पूछें: क्या इसे रोक रहा है? यह बस बहुत काम है? क्यों?
3. समय में तकनीकी ऋण को कम करने के लिए एक योजना बनाएं। उदाहरण के लिए, नियमों को " प्रत्येक बिट कोड जो टीम द्वारा छुआ गया है, को निर्धारित किया जाना चाहिए / नए मानक पर लागू किया जाना चाहिए "। आमतौर पर: यूनिट परीक्षणों को लिखा जाना चाहिए, कोड को सही परतों में स्थानांतरित किया जाना चाहिए, आदि। यह आपको हास्यास्पद महंगी और कम मूल्य की "रिफैक्टिंग" परियोजनाओं का सहारा लिए बिना बहुत सारे कोड को ठीक करने की अनुमति देता है।
4. बकवास लपेटो। Decoupling refactoring और अच्छी वास्तुकला के लिए महत्वपूर्ण है। यदि आप किसी तरह कोड आधार को विभाजित कर सकते हैं, तो आप शायद छोटे बिट्स को रिफैक्ट कर सकते हैं।
5. तकनीक ऋण को और अधिक न बढ़ाएं। तकनीक ऋण को और अधिक न बढ़ाएं। तकनीक ऋण को और अधिक न बढ़ाएं। ऐसा न करें...

Comments

+1 तकनीक ऋण को और अधिक नहीं बढ़ाता है।

— रेयनोस

धन्यवाद - तकनीकी ऋण अवधारणा में खुदाई की गई है। इसके बारे में सोचने का बहुत उपयोगी तरीका। सभी महान सुझाव (विशेष रूप से 3)

— मैट इवांस

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

— गर्त्जन

Answer 2

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

Sklivvz क्या कहते हैं इसके अलावा कुछ सलाह:

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

2. पता लगाएँ कि आपका लक्ष्यीकरण लक्ष्य क्या है। क्या आप साइट में सामग्री प्राप्त करना आसान बनाना चाहते हैं? क्या आपके पास बहुत सारे कीड़े हैं और उपयोगकर्ता-कथित गुणवत्ता में सुधार करना चाहते हैं? क्या आप इसके बजाय सुविधा विकास समय को कम करना चाहते हैं? या आप मुख्य रूप से एक बेहतर UX चाहते हैं? आपकी वास्तुकला को आपके द्वारा निर्धारित लक्ष्यों को पूरा करने के लिए कोड को रिफलेक्टर करना आसान बनाना चाहिए। यह कभी न भूलें कि आपके रिफैक्टरिंग का प्राथमिक लाभार्थी आपका उपयोगकर्ता / ग्राहक / व्यवसाय होना चाहिए। क्लीनर कोड अपने आप में एक लक्ष्य नहीं है, यह एक विधि है, और अंत में एक उपयोगकर्ता शामिल है।

3. संभव के रूप में कई संदर्भ आर्किटेक्चर खोजने की कोशिश करें और उन्हें कॉपी करने से डरो मत। पहिया को सुदृढ़ मत करो। यदि किसी और के पास एक वास्तुकला है जो आपकी जैसी साइटों के लिए अच्छी तरह से काम करती है, तो उनसे सीखें।

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

Answer 3

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

Comments

अच्छी सलाह। मुझे लगता है कि कुंजी स्पष्ट रूप से वांछित वास्तुकला का पता लगा रही है। एक दृष्टिकोण पर चर्चा करने और सहमत होने के लिए कुछ बैठकों का समय निर्धारित करना।

— मैट इवांस

Answer 4

पुनरुत्थान विरासत सॉफ्टवेयर पर एक बहुत अच्छी मुफ्त पुस्तक / पीडीएफ है: http://scg.unibe.ch/download/oorownload/

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

Answer 5

यदि इसमें सुसंगत वास्तुकला नहीं है, तो यह इसलिए है क्योंकि प्रबंधन समस्या के बारे में समझ नहीं पाता है। बस कोड दूर। नए कोड लिखने के साथ ही आपको नई अच्छी वास्तुकला का परिचय देना चाहिए।

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

मैं मूल रूप से केवल उन मुद्दों के बारे में कह रहा हूं जो आपके प्रबंधकों को वास्तव में परवाह हैं, न कि उन मुद्दों के बारे में जो वे आपके ज्ञान के बारे में परवाह करेंगे।

यदि आप प्रबंधन को फिर से वास्तुकला बेच सकते हैं, तो परीक्षण से शुरू करें। यदि वे परीक्षण में निवेश नहीं करना चाहते हैं, तो आपके प्रयासों से केवल आपको परेशानी होगी।