पुराने कोड को आधुनिक बनाने के लिए सबसे पहले पुरातत्व की आवश्यकता है

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

यही कारण है कि “पुरातत्व” “परिवर्तन” से पहले आता है। पहले बिल्ड फ़ाइल को देखें, फिर निर्भरताएँ, फिर चल रहे वातावरण को, फिर परीक्षणों को। आदेश को उलटा नहीं किया जा सकता. बिल्ड.एक्सएमएल अभी भी मौजूद है, लेकिन पोम.एक्सएमएल मौजूद नहीं है। ऐसे संकेत यह बताने के लिए पर्याप्त हैं कि परियोजना चींटी युग में जी रही है; क्या कोड संकलित किया जा सकता है, क्या परीक्षण चलाए जा सकते हैं, और क्या उत्पाद को फिर से बनाया जा सकता है, ये पहला सबूत हैं। यहां मॉडल का सबसे उपयोगी हिस्सा पुराने कोड के लिए तुरंत नया कोड लिखना नहीं है, बल्कि टुकड़ों के ढेर से इन सबूतों की पहचान करना है।

पर्यावरण को भी पहले पिन किया जाना चाहिए। पुराना कोड अक्सर पुराने JVMs, पुराने कंटेनरों और पुरानी वास्तुशिल्प मान्यताओं के साथ आता है। इसे सीधे आज की मशीनों पर डालें, विशेष रूप से क्रॉस-आर्किटेक्चर वातावरण में, और समस्या होने पर नए शोर में मिश्रण करना आसान है: क्या कोड स्वाभाविक रूप से टूटा हुआ है, या क्या यह अनुकरण, मिररिंग और टूल श्रृंखलाएं हैं जो परेशानी पैदा कर रही हैं? यदि आप इस स्तर पर “समान कोड को एक ही वातावरण में स्थिर रूप से पुन: प्रस्तुत किया जा सकता है” भी हासिल नहीं कर सकते हैं, तो बाद की सभी आधुनिकीकरण गतिविधियां केवल अनुमान होंगी।

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

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

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