मूल रूप से संरचना के साथ किसी परियोजना को कैसे ठीक करें?


25

मैं एक सॉफ्टवेयर परियोजना पर काम कर रहा हूँ जो 5 साल से अधिक समय से अकेली है। यह शुरू करने के लिए एक गड़बड़ी थी (मैं इस पर काम करने वाला तीसरा या चौथा डेवलपर हूं), और हालांकि यह एक गड़बड़ से कम है अब भी यह अविश्वसनीय रूप से अव्यवस्थित है। नियंत्रण में इसे प्राप्त करने में प्रगति की दर हिमनद है और मैं राज्य के प्रति उदासीन महसूस करने लगा हूं कि यह किस प्रकार है। मैं वास्तव में इसे कैसे ठीक करना शुरू करूं?

प्रोजेक्ट बारीकियाँ: यह एक बिक्री कार्यक्रम है जो लगभग पूरी तरह से विज़ुअल बेसिक क्लासिक (VB6) में MySQL बैक एंड और रिपोर्टिंग इंजन C # में लिखा गया है। C # रिपोर्टिंग मॉड्यूल काम करने के लिए एक खुशी है, यह केवल पिछले कुछ वर्षों में लिखा गया था और इससे पहले सभी रिपोर्ट क्रिस्टल रिपोर्ट 9 में की गई थीं (हाँ, हमारे पास अभी भी कुछ रिपोर्टें हैं जो इस पर भरोसा करती हैं)।

हालांकि, वास्तविक कार्यक्रम ही पूर्ण आपदा है। कुल 90k LOC कुल नहीं है, और टिप्पणियों के बारे में 10k लाइनें (ज्यादातर दस्तावेज नहीं हैं, लेकिन पुराने कोड जो टिप्पणी की गई हैं)। 158 फॉर्म फाइलें, और 80 मॉड्यूल फाइलें। मुझे पता नहीं है कि उनमें से कितने वास्तव में उपयोग किए जाते हैं, क्योंकि कार्यक्रम की कुछ विशेषताएं बस पदावनत की जाती हैं और (उह, कभी-कभी) कार्यक्रम से हटाए गए संबंधित कोड के बिना इस तरह के रूप में नोट किया जाता है। मुझे लगता है कि कोड का केवल 50% वास्तविक उत्पादक उपयोग में है।

मैं बहुत सारे कोड को छूने से डरता हूं क्योंकि मुझे यकीन नहीं है कि अगर मैं कुछ तोड़ रहा हूं जो एक अस्पष्ट ग्राहक पर निर्भर करता है, तो यह अधिक मौकों पर हुआ है जितना मैं गिन सकता हूं। यह ऐसा है जैसे पूरे कोड में बारूदी सुरंगें हैं।

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

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

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

तो मैं वास्तव में इस परियोजना को कैसे शुरू करूं? किसी अन्य भाषा के साथ VB6 टूल करने का प्रयास करें? मेरे खाली समय में कार्यक्रम को आज़माएं और फिर से लिखें? या यह पूरी तरह से निराशाजनक है?

अद्यतन करें

इस पोस्ट के बाद मैं नए जोश के साथ प्रोजेक्ट पर वापस गया, लेकिन प्रगति की इतनी धीमी दर को देखकर कुछ ही महीनों में निराशा में लौट आया। मैंने इस चक्र को अगले वर्ष 2 या 3 बार दोहराया।

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


4
बहुत बुरा लगता है। एक शुरुआत वर्तमान कोड की एक कॉपी को बचाने और पुराने कोड को हटाने के लिए होगी जो कि टिप्पणी की गई है (यह सिर्फ शोर है)। जब मैंने एक विरासत प्रणाली पर काम किया, तो मैं आमतौर पर कोड के शीर्ष पर एक तारीख डालूंगा जो मैं टिप्पणी करूंगा। तब आंत से बाहर कोड टिप्पणी की गई थी जो 6 महीने या उससे अधिक थी।
प्रोग्रामर

4
मैं जैमिसन के साथ शुरू करूंगा और शेल्फ के नीचे अपना रास्ता काम करूंगा। । ।
व्यट बार्नेट

1
क्या आपने कभी VB प्रोग्रामर द्वारा लिखित C # प्रोजेक्ट को लेने की कोशिश की है?
שגינתיא אבישנת

जवाबों:


28

अब जब यह स्रोत नियंत्रण में है, तो आप कमेंट आउट कोड से छुटकारा पा सकते हैं।

मैंने यहां एक समान स्थिति में शुरू किया (80KLOC VB6 ऐप जिसमें कोई स्रोत नियंत्रण नहीं, कोई वास्तविक संरचना नहीं है, लगभग सभी घटनाओं में काम करने वाले)।

लगभग 2 वर्षों में मैंने आधे से अधिक सी # में परिवर्तित कर लिया है (आमतौर पर जब महत्वपूर्ण नई सुविधाओं की आवश्यकता होती है)। सभी नए C # कोड में यूनिट टेस्ट कवरेज है। C # को कनवर्ट करने में निश्चित रूप से अधिक समय लगता है। यदि आप महत्वपूर्ण नए मॉड्यूल नहीं जोड़ रहे हैं, तो मैं उस मार्ग से नीचे नहीं जाऊंगा।

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

हालाँकि, मुझे यह फायदा था कि आवेदन केवल आंतरिक था। चूँकि मेरे पास केवल एक साइट पर तैनात करने के लिए था, इसलिए मैं आपकी तुलना में कुछ बड़े जोखिम उठा सकता था। अगर मैंने गलती की है, तो इसे ठीक करना आम तौर पर बड़ी बात नहीं थी। लगता है जैसे आपके पास वह विलासिता नहीं है।

मुझे वास्तव में लगता है कि आपका सर्वश्रेष्ठ दांव निम्नलिखित दृष्टिकोण लेना है:

  1. हर बात को विस्तार से जानें। इससे यह संभव है कि आप अनजाने में कुछ तोड़ देंगे।
  2. रिफ्लेक्टर निर्दयता से अलगाव और संरचना को सुधारने के लिए, लेकिन वहां ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग जैसी नई पद्धति को जूता करने की कोशिश न करें, क्योंकि VB6 सिर्फ इसे चूसता है।
  3. इसे एक सीखने के अनुभव के रूप में मानें। यदि आप कभी भी हीन दृष्टि से नहीं देखते हैं, तो आपको कैसे पता चलेगा कि बेहतर तरीका है?
  4. जब तक आपके पास लिखने के लिए एक प्रमुख मॉड्यूल न हो, नई भाषा / फ्रेमवर्क / प्लेटफ़ॉर्म में पुनर्लेखन को परेशान न करें। फिर भी, ध्यान से विचार करें।

याद रखें, कार्यक्रम का लक्ष्य एक ऐसा उत्पाद होना है जो आपकी कंपनी को पैसा देता है। यह कला का एक दोषरहित काम नहीं है (और मैं एक पूर्णतावादी हूं इसलिए यह मेरे लिए वास्तव में कठिन है कि मैं इसे स्वीकार करूं )। कभी-कभी व्यावहारिकता को गले लगाना बेहतर होता है।

माना जाता है कि विरासत कोड की भारी मात्रा को बनाए रखने के लिए बहुत सारे COBOL प्रोग्रामर हैं। मुझे संदेह है कि वे सभी पागलपन से दूर कुछ नई भाषा में इसे लिख रहे हैं। :)


3
+1 महान जवाब: सभी मैं जोड़ सकता हूं सुनिश्चित करें कि आप खुद पर बहुत अधिक उम्मीद नहीं रख रहे हैं। नए विकास की तुलना में कोड रखरखाव धीमा है, विरासत कोड, यहां तक ​​कि धीमी, और undocumented, असंरचित कोड जैसे कि आपने वर्णन किया है .... पिछले 5 वर्षों में मैंने विभिन्न प्रकार के कोड बेस पर काम किया है, जो 1980 तक वापस डेटिंग और लाखों में उपाय। एसएलओसी ... मुझे आपका दर्द पता है ...
मैट्नज़

+1 लेकिन एक OO सुविधा VB6 करता है ठीक है पर इंटरफेस है। यदि आप समान कोडित copy'n'pasted को कुछ बार देख सकते हैं, तो आप इंटरफ़ेस में रिफ्लेक्टर करने में सक्षम हो सकते हैं, यदि पूर्ण वर्ग नहीं।
मार्क हर्ड

3

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


11
मैं इस स्थिति में हूं। सबसे पहले, वीबी 6 में दयनीय इकाई परीक्षण सूट हैं। दूसरी इकाई परीक्षणों में लगभग हमेशा DI की आवश्यकता होती है और यह VB6 में वास्तव में कठिन होता है क्योंकि ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के लिए इसके भयानक समर्थन के कारण। मैं अभी तक किसी से भी सुनने के लिए जो वीबी 6 परियोजना ले गया था, यूनिट परीक्षणों का एक गुच्छा लिखा और एक रिफैक्टिंग द्वि घातुमान पर चला गया, भले ही यह स्टॉक का जवाब हो जो आप हमेशा इस तरह के एक सवाल के लिए सुनेंगे। क्या आप जानते हैं कि तर्क के लिए यूनिट टेस्ट लिखना कितना दर्दनाक होता है जो फॉर्म इवेंट हैंडलर में सभी जगह पर होता है? परीक्षण लिखने से पहले आपको रिफ्लेक्टर देना होगा !
स्कॉट व्हिटलॉक

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

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

3

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

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

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


जब तक ठीक से नहीं किया जाता है, "एक आधुनिक भाषा में पोर्टिंग" एक "V # प्रोग्राम को C # सिंटैक्स में देगा" - वर्तमान में एक सी पोर्ट पर जावा ऐप पर काम कर रहा है जो वास्तव में "Cava" है जावा नहीं - यह दोनों में से सबसे खराब है और न तो सबसे अच्छा है ........ सही तरीके से पोर्टिंग करना वास्तव में ड्रैग में एक फिर से लिखना है, और जैसा कि योएल ने "चीजों को न करने" की सूची में उच्च स्तर पर रखा।
मैट्नज

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

3

मुझे यह कहने से नफरत है, लेकिन मैं "पूरी तरह से निराशाजनक" के साथ जाना चाहता हूं, केवल पैच / एन्हांस का एक अंतहीन चक्र जारी रखने और कुछ भी नहीं तोड़ने की उम्मीद है। मैंने अब तक बहुत सारी VB6 परियोजनाओं को देखा है, जैसे आप जो वर्णन करते हैं और C # / / पर उन्हें फिर से लिखने / फिर से लिखने का प्रयास करते हैं। नेट बहुत बुरी तरह से विफल हो जाता है, अक्सर प्रयास के प्रभारी लोगों के साथ निकाल दिया जाता है।

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

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


+1 आप आधुनिक विंडोज संस्करणों पर VB6 के समर्थन खोने के बारे में सही हैं। जितनी जल्दी या बाद में (शायद जितनी जल्दी हो), आपका एप्लिकेशन बस उस फ़ंक्शन को बंद कर देगा जहां उसे इसकी आवश्यकता है।
बर्नार्ड

1

कुछ अच्छे जवाब यहां पहले से ही हैं, मैं एक बात जोड़ना चाहूंगा। सब कुछ फिर से लिखने की कोशिश करने के बजाय, शायद आपके पास कम से कम कुछ मॉड्यूल को अधिकतर 1: 1 से VB.NET में पोर्ट करने का मौका होगा (बेशक, आपको ऐसा करते समय बहुत सावधान रहना होगा)? मेरे अनुभव के अनुसार, इस तरह के पोर्टिंग को खरोंच से सभी मौजूदा कार्यक्षमता के पुनर्निर्माण के प्रयास की तुलना में ~ 5-10 गुना कम प्रयास के साथ किया जा सकता है। और आपके द्वारा इसे पोर्ट करने के बाद , आप फिर से रिफैक्टर करना शुरू कर सकते हैं - उन सभी टूल्स के साथ जो .NET दुनिया में उपलब्ध हैं, जैसे अच्छी यूनिट टेस्टिंग टूल्स, ऑटोमैटिक रिफैक्टरिंग टूल्स, असली OOP आदि।

मैं एक ऐसी ही स्थिति में था, जहां हमें 16 बिट C ++ प्रोग्राम (150k LOC) को 32 बिट दुनिया में स्थानांतरित करना था, जहां उपयोग में मूल जीयूआई ढांचा और उपलब्ध नहीं था। हमें यह समझने में कुछ समय लगा कि पुनर्लेखन अवास्तविक था, लेकिन जब हमने C ++, C ++ / CLI और C # का उपयोग करके .NET दुनिया में उस चीज़ को पोर्ट करने का निर्णय लिया, तो हमें ऐसा करने के लिए केवल 9 महीनों की आवश्यकता थी (लगभग 1 देव के साथ) पूर्णकालिक उस परियोजना पर काम कर रहे हैं)। और हमारे पास जीयूआई भाग के लिए कोई यूनिट परीक्षण उपलब्ध नहीं था, क्या उन सभी भागों का परीक्षण मैन्युअल रूप से किया गया था।


0

यद्यपि यह आपके परीक्षण को इकाई-परीक्षण पर बहुत जोर देता है, हालांकि, जो कि एक बहुत ही महत्वपूर्ण बात है, वीबी 6 में करना काफी कठिन है, स्टीवन मैककोनेल ने इस तरह के प्रोजेट से निपटने के बारे में एक उत्कृष्ट पुस्तक लिखी।

इस पर एक नज़र मारो:

स्टीवन सी। MCCONNELL: लिगेसी कोड, द्वितीय संस्करण के साथ प्रभावी रूप से कार्य करना। माइक्रोसॉफ्ट प्रेस, जून 2004।

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.