हजारों त्रुटियां!

Question

मुझे हाल ही में एक नई परियोजना सौंपी गई थी। खैर, एक पुरानी परियोजना वास्तव में, क्लासिक एएसपी में लिखी गई है। अब एप्लिकेशन का एक नया संस्करण नवीनतम ASP.NET में लिखा जा रहा है, लेकिन यह थोड़ी देर में RTM होने की उम्मीद नहीं है (अनुमानित रिलीज की तारीख जनवरी 2017 है) इसलिए मुझे पुराने एप्लिकेशन पर कुछ रखरखाव करना होगा जब तक यह नहीं हो सकता बाहर किया हुआ।
साथ ही, मुझे यह महसूस हुआ है कि सभी ग्राहक तुरंत नए कार्यक्रम पर नहीं लौटेंगे, इसलिए यह संस्करण संभवतः थोड़ी देर के लिए होगा।

और समस्या यह है, यह त्रुटियों से भरा है। इसके कुछ हिस्सों वापस पिछली सदी, जब वहाँ कोई वेब मानकों थे तिथि, और मैं वास्तव में क्वर्क्स मोड के बारे में कोई आपत्ति नहीं है, और widthऔर heightउन सभी त्रुटियों सीएसएस के बजाय गुण,, लेआउट के लिए इस्तेमाल किया फ़्रेमसेट आदि टेबल, लेकिन ओह,! width="20px"सभी जगह, onchange="javascript:..."और उन जगहों पर जहां वे सीएसएस का उपयोग करते हैं, style="width:20"और style="width=20px"आम हैं। जहां विरोधाभासी widthऔर styleगुण हैं, वहां बहुत सारी पंक्तियों का उल्लेख नहीं है । आदि।
नतीजतन, वेब एप्लिकेशन केवल IE के तहत चलता है, और केवल संगतता मोड में। यह स्पष्ट है कि डेवलपर्स ने कभी भी कोड वैधता पर ध्यान नहीं दिया, केवल अगर बाहर आया तो जैसा दिखता था, उनके मन में वैसा ही दिखना चाहिए।

और मुझे नहीं पता कि कैसे संभालना है। मुझे अन्य त्रुटियों के लिए कोड में देखते हुए अपनी आँखें बंद करना असंभव लगता है।
मैं निश्चित रूप से एक वैश्विक खोज कर सकता हूं और अधिकांश मुद्दों को रास्ते से हटाने के लिए बदल सकता हूं, लेकिन इसका मतलब होगा कि मेरी पहली प्रतिबद्धताओं में हजारों परिवर्तित .asp फाइलें शामिल होंगी। क्या मै वह कर सकता हूं?

Comments

"त्रुटियों" से क्या आप कोडिंग शैली का मतलब पसंद करते हैं?

— इवान

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

— gnasher729

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

— डॉक्टर ब्राउन

यह एक "त्रुटि" नहीं है जो "क्लासिक एएसपी" में लिखा कोड क्लासिक एएसपी के मानकों (जैसे वे थे) का पालन करता है, जो वेब कोडिंग में नवीनतम फैशन से अलग होता है - और नवीनतम फैशन संभवतः "आउट" होगा किसी भी मामले में अगले साल तक "तारीख"। "यह स्पष्ट है कि डेवलपर्स ने कभी भी कोड वैधता को नहीं देखा" - अगर ओपी को लगता है कि वह कोड लिख सकता है / जो भविष्य में 15 या अधिक वर्षों के लिए अभी भी "वैध दिखाई देगा", तो समय बताएगा कि क्या विश्वास सिर्फ प्राकृतिक आशावाद है ( या युवाओं का अज्ञान)।

— एलेफ़ेज़ेरो

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

— Stephan Branczyk

Answer 1

ऐसा लगता है कि आप शब्द "त्रुटियों" में कई चीजों को भ्रमित कर रहे हैं

• विरासत HTML विशेषताएँ
• कोडिंग शैली
• कोडिंग त्रुटियां जो बग पैदा नहीं करती हैं
• बिना लाइसेंस के कीड़े
• गलतियाँ जो अब सुविधाएँ हैं
• बग की सूचना दी
• रिपोर्ट किए गए बग आपको ठीक करने के लिए असाइन किए गए हैं

एक विरासत ऐप पर जो इस प्रकार की त्रुटि में से केवल एक को प्रतिस्थापित करने जा रहा है, आपको चिंता करनी चाहिए। आखरी वाला।

मैं कहूंगा कि जहां तक ​​आपको बग फिक्स करने की सुविधा पर अन्य सामान को रिफ्लेक्टर नहीं करना चाहिए, इसका मुख्य कारण है:

• गलतियाँ जो अब सुविधाएँ हैं

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

दूसरी तरफ, यदि आप अपने निंदक JFDI के सिर को लगाते हैं, तो आप सुपर सुपर क्विक और नए संस्करण की टीम को पुराने संस्करणों की विशेषताओं के साथ बनाए रखने में सक्षम नहीं होंगे।

यह आपको विडंबनापूर्ण उल्लास की मुस्कुराहट प्रदान करेगा, जैसा कि आप ग्राहकों को क्रोम प्लगइन यानी 6 एमुलेटर की सलाह देते हैं, ताकि वे मार्की 'फीचर' का उपयोग करते रहें, जिससे वे प्यार करते हैं

Comments

" गलतियाँ जो अब सुविधाएँ हैं " - ओह, खुशी ...

— एफपी

वास्तव में आप जो स्पर्श करते हैं, उसमें बहुत सतर्क रहें, यह तुरंत ही समझ में आ गया: xkcd.com/1172

— डेनिस जहरुद्दीन

कृपया स्पष्ट करें... JFDI ...

— GER

@ जीईआर "जस्ट [एक्सप्लेटिव] डू इट" जिसका मतलब सामान्य मानकों और परीक्षण और अन्य चीजों से बचना है और बिना किसी देखभाल के इसे ठीक करना है कि क्या यह एक रखरखाव योग्य और पठनीय तरीके से किया गया है।

— नजल्ल

जैसे एग्ली लेकिन इससे भी अधिक

— ईवान

Answer 2

आप जो पूछते हैं वह तकनीकी सवाल नहीं है, और यहां कोई भी इसका जवाब नहीं दे सकता है।

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

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

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

Comments

यह एक व्यावसायिक निर्णय है लेकिन इसका उत्तर देना इतना स्पष्ट है कि उसे प्रबंधक से पूछने की आवश्यकता नहीं है। आवश्यकता नहीं होने पर वह गंदगी को साफ नहीं करना चाहिए। (+1)

— usr

Answer 3

जब आवेदन को 18 से 24 सप्ताह में बदल दिया जाएगा (ऊपर प्रस्तुत 6 से 8 सप्ताह में अपेक्षित विलंब को जोड़ते हुए) तो आपको वास्तव में खुद से यह पूछने की जरूरत है कि आप अभी भी काफी मात्रा में काम का निवेश करके व्यवसाय में क्या मूल्य जोड़ते हैं पुराने संस्करण।

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

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

Comments

s/weeks/years/

— कोडइन्चोस

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

— पीटरिस

@ पेटरिस खैर, अस्थायी कर। लेकिन हाँ।

— Jay

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

— जूल्स

सौभाग्य से, मुझे सबसे खराब मुद्दों (एसक्यूएल इंजेक्शन हमलों, लाखों पंक्तियों के साथ एसक्यूएल टेबल) को ठीक करने के लिए मंजूरी मिल गई लेकिन कोई संकेत नहीं , वे पृष्ठ जहां मूल डेवलपर प्राधिकरण के लिए जांच करना भूल गया था ...)।

— जूल्स

Answer 4

बड़े बदलाव करने के कारण नहीं:

एक: कुछ महीनों में कोड खत्म हो रहा है। क्या यह वास्तव में आपके लिए 5 महीने खर्च करने के लिए कंपनी के समय के लिए एक प्रणाली को ठीक करने का समय होगा जो फिर 1 महीने बाद फेंक दिया जाएगा? कैविएट: सिस्टम शायद ही कभी चले जाते हैं जब वे दूर जाने के लिए शेड्यूल किए जाते हैं। प्रतिस्थापन प्रणाली लगभग हमेशा देर से होती है, ऐसे उपयोगकर्ता हैं जो किसी भी कारण से अपग्रेड नहीं कर सकते हैं, लेकिन यह एक जटिल मुद्दा है।

दो: यदि आप बहुत सारे बदलाव करते हैं, विशेष रूप से बड़े पैमाने पर खोज और जगह, तो आप बग का परिचय देंगे। नहीं तुम कीड़े परिचय हो सकता है: आप करेंगे। मान लीजिए आपने एक S & R किया और "चौड़ाई = 200" को "चौड़ाई: 200px" में बदल दिया। क्या आपके ASP पृष्ठ पर C # या VB कोड है? क्योंकि यदि आपके पास "चौड़ाई" नाम का एक चर था जिसे आप 200 पर सेट कर रहे थे, तो आपने इसे तोड़ दिया। (या उस मामले के लिए, क्या आपने एस एंड आर को एएसपी पृष्ठों तक सीमित करने के लिए सोचा था?) या यदि आपने "चौड़ाई: 200" को "चौड़ाई: 200px" में बदल दिया, तो क्या होगा यदि कोड में एक जगह थी जो "चौड़ाई: 200 मिमी थी" "? अब यह कहता है कि "चौड़ाई: 200pxmm"। ठीक है, मान लीजिए कि आपने उन लोगों के बारे में सोचा। क्या होगा यदि कोई ऐसी जगह है जिसमें अमान्य चौड़ाई विनिर्देश था, जिसे निश्चित रूप से अनदेखा किया गया है, और यह अब काफी अच्छी तरह से बाहर है। आप ठीक करें" चौड़ाई और यह अब 200px के साथ देता है ... और प्रदर्शन खराब हो गया है, क्योंकि 200px वास्तव में देने के लिए गलत चौड़ाई है और यह केवल इसलिए काम किया क्योंकि उस मूल्य को अनदेखा किया गया था? मास एस एंड आर बहुत खतरनाक हैं, क्योंकि आप लगभग निश्चित रूप से हर उस जगह का अध्ययन नहीं कर रहे हैं जिसे आप बदलते हैं। आप संभावना भी नहीं जानते कि क्या परीक्षण करना है।

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

यहां तक ​​कि अगर व्यवहार वास्तव में गलत है, तो शायद उपयोगकर्ता इसकी उम्मीद करते आए हैं और वे नियमित रूप से इसके चारों ओर काम करते हैं, और इसे ठीक करके, आप उनके वर्कआर्ड को तोड़ देंगे। उदाहरण: मैं एक ऐसी प्रणाली पर काम करता हूं, जहां हमारे पास एक ऐसी जगह है, जहां आप तारीखों के माध्यम से और जनता के लिए एक बिक्री उपलब्ध कराते हैं। दोनों तिथियां वास्तव में उस दिन शुरू होने वाली मध्यरात्रि थीं, इसलिए यदि आपने "30 जुलाई के माध्यम से" कहा कि इसका मतलब है कि यह 29 जुलाई के दिन के अंत के साथ समाप्त होता है, अर्थात 30 जुलाई को 12:01 बजे से एक मिनट पहले, 30 जुलाई को नहीं। एक बिंदु पर मैंने यह तय किया था, लेकिन मैं केवल ऐसा कर सकता था क्योंकि उस स्क्रीन का उपयोग करने के लिए प्राधिकरण के साथ आधा दर्जन से कम लोग थे, और मैं बस उन सभी को बता सकता था जो मैंने इसे तय किया था। यदि सैकड़ों उपयोगकर्ता थे, और वे अब तक यह पता लगा चुके थे कि आपको वास्तव में तारीख के बाद का दिन देना है, तो मेरी "फिक्सिंग"

Answer 5

मैं निश्चित रूप से एक वैश्विक खोज कर सकता हूं और अधिकांश मुद्दों को रास्ते से हटाने के लिए बदल सकता हूं, लेकिन इसका मतलब यह होगा कि मेरी पहली प्रतिबद्धताओं में हजारों परिवर्तित .asp फाइलें शामिल होंगी। क्या मै वह कर सकता हूं?

मैं नहीं देखता कि क्यों नहीं। एक प्रतिबद्ध होना चाहिए धारणात्मक एक बात है, लेकिन मैं कोई कारण नहीं क्यों एक वैश्विक खोज और से की जगह को देखने style="width=20"के लिए style="width: 20px""एक बात" के रूप में, धारणात्मक बोल गिनती नहीं होगी। और अगर यह आपको बेहतर नींद में मदद करेगा, तो आप को विचलित होने से बचाएंगे क्योंकि आप अन्य चीजों को ठीक करते हैं, और कुछ भी नहीं करते हैं , क्यों नहीं?

Comments

क्यों नहीं? क्योंकि व्यापक विरासत कोडबेस पर व्यापक खोज और प्रतिस्थापन के बाद व्यापक परीक्षण की आवश्यकता होती है ताकि कुछ भी न टूटे।

— जैक्सबी

Answer 6

आपकी समस्या प्राथमिकताएं निर्धारित कर रही है : शोस्टॉपर्स (उत्पादन में) कौन से मुद्दे हैं? कौन से टाइमबॉम्ब टिक रहे हैं? और जो थोड़ी देर में छोड़ दिया जा सकता है (क्योंकि यह काम करता है और वर्षों से ऐसा किया है, यहां तक ​​कि सॉर्ट-ऑफ भी)?

मैं आपकी स्थिति में क्या करूंगा जिससे समस्या वर्ग की सूची बनेगी जिसे मैं देखना चाहता हूं। उदाहरण के लिए, की जगह style="width=(\d+)"के साथ style="width: \1px"(जो शायद एक वैश्विक खोज के साथ सुधारा जा सकता है / regexp का उपयोग कर की जगह - खेद है मेरा 100% नहीं है) एक वर्ग होगा, और सिर्फ एक घटना है कि अगर, तो ठीक है। प्रत्येक श्रेणी के लिए एक प्राथमिकता को सूचीबद्ध करें (यह करने के लिए कितना जरूरी है) और काम का एक अनुमान (इस श्रेणी को करने में कितना समय लगेगा)।

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

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