पुराने सिस्टम को आधुनिक बनाने में कोपायलट सबसे पहले सबूतों को छांटता है

#पुराने सिस्टम को आधुनिक बनाने में कोपायलट सबसे पहले सबूतों को व्यवस्थित करता है

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

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

docker run --rm -v "$PWD":/src -w /src legacy-jdk8 \
  sh -lc './gradlew test 2>&1 | tee logs/baseline.log'

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

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

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

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