পুরানো সিস্টেমের আধুনিকীকরণে, কপিলট প্রথমে প্রমাণগুলি সংগঠিত করে

প্রথমবার যখন আমি 1.5 যুগ থেকে একটি আধুনিক মেশিনে একটি জাভা প্রকল্প টেনে আনলাম, প্রথম জিনিসটি পপ আপ হল কোড সমস্যা নয়, কিন্তু প্রমাণ সমস্যা। বিল্ডটি পুনরুত্পাদন করা যেতে পারে কিনা, পরীক্ষার আউটপুট একই কিনা, ব্যর্থতার পয়েন্টটি JVM, চিত্র বা উত্স কোড থেকে আসে কিনা, এই বিষয়গুলি “রিফ্যাক্টরিং শুরু করার” আগে কীভাবে এগিয়ে যেতে হবে তা নির্ধারণ করে। পুরানো সিস্টেমের আধুনিকীকরণের সময় সবচেয়ে বড় ভয় যে পরিবর্তনগুলি ধীর হয় তা নয়, তবে পরিবর্তনের পরে কী ঘটেছে তা বলা অসম্ভব।

প্রথমে দৃশ্যটি ঠিক করুন, তারপরে পরবর্তী ক্রিয়াগুলি অর্থবহ হবে। সেই ধাপে সবচেয়ে মূল্যবান জিনিসটি IDE-তে সম্পূর্ণ হওয়া নয়, তবে একটি বাক্স যা বারবার চালানো যেতে পারে: পুরানো JDK, পুরানো বিল্ড টুল, পুরানো প্রবেশদ্বার এবং পুরানো পরীক্ষা কমান্ডগুলি সবই ডকারে লক করা আছে। নিম্নলিখিত মত কমান্ড সুন্দর নয়, কিন্তু তারা কাজ করে:

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

এই কমান্ডের শুধুমাত্র একটি ফাংশন আছে: “আজকের ব্যর্থতা” পুনরায় প্লেযোগ্য প্রমাণে ঠিক করা। এটি ছাড়া, প্রতিটি পরবর্তী সাফল্য কেবল এমন পরিস্থিতির ফলাফল হতে পারে যা ক্ষমাশীল ছিল। এখানে কপিলটের ভূমিকাও খুব স্পষ্ট। এটি রায়কে প্রতিস্থাপন করার জন্য নয়, তবে চিহ্নগুলিকে বাছাই করতে সাহায্য করার জন্য: দীর্ঘ লগগুলিতে বারবার ত্রুটি, বিল্ড স্ক্রিপ্টগুলিতে একে অপরের প্রতিধ্বনিকারী পথ এবং পুরানো পরীক্ষায় বেশ কয়েকটি পুনরাবৃত্ত এন্ট্রিগুলি প্রথমে একটি রুক্ষ স্ক্রীনিংয়ের জন্য ব্যবহার করা যেতে পারে। যা sifted আউট একটি উপসংহার নয়, কিন্তু একটি মানচিত্র দিয়ে শুরু.

যখন আসলে ছুরির নিচে যাওয়ার সময় আসে, তখন পরিবর্তনের ক্ষেত্রটি অবশ্যই খুব সংকীর্ণ হতে হবে। পুরানো প্রকল্পগুলিকে উল্টে দেওয়ার সবচেয়ে সহজ উপায় হল প্যাকেজের নাম পরিবর্তন করা, তৈরি করা, এন্ট্রি করা এবং একবারে পরীক্ষা করা। শেষ পর্যন্ত, আপনি বলতে পারবেন না কোন পদক্ষেপটি সিস্টেমটি ভেঙেছে। একটি আরও স্থিতিশীল পদ্ধতি হল প্রথমে ক্ষুদ্রতম ব্যবধানটি দখল করা: উদাহরণস্বরূপ, অ্যাডাপ্টারের একটি স্তর দিয়ে পুরানো প্রবেশদ্বারটি ঢেকে রাখুন, প্রথমে নতুন টুল চেইনটিকে পুরানো বিশ্বের বাইরে দাঁড়াতে দিন এবং কাঠামোটি পরিষ্কারভাবে দেখতে দিন এবং তারপর ধীরে ধীরে ভিতরে চলে যান। এই ধরনের যান্ত্রিক কাজ পরিচালনার জন্য কোপাইলট খুবই উপযুক্ত: আমদানি পূরণ করা, চলমান কনফিগারেশন, এক্সট্র্যাক্ট করা এবং টেম্পারিং পরীক্ষা করা। কঙ্কাল মডেলকে এই জিনিসগুলি করতে দিন, এবং কার্যকারিতা সত্যিই উচ্চ; তবে এই সীমটি কাটা উচিত কিনা এবং কাটার পরে কী আচরণ সংরক্ষণ করা উচিত তা নির্ধারণ করা এখনও মানুষের উপর নির্ভর করে।

পরীক্ষার ক্ষেত্রে উপস্থিতি দ্বারা প্রতারিত হওয়াও সহজ। পুরানো পরীক্ষায় উত্তীর্ণ হওয়ার অর্থ এই নয় যে আধুনিকীকরণ নিরাপদ, এর অর্থ কেবলমাত্র কিছু ঐতিহাসিক আচরণ এখনও ভাঙা হয়নি। অনেক পুরানো প্রকল্পের পরীক্ষাগুলি ব্যবসার শব্দার্থিক স্পেসিফিকেশনের চেয়ে আচরণগত স্ন্যাপশটের মতো। সবুজ শুধু সবুজ এবং সরাসরি “ব্যবস্থা বোঝা” হিসাবে ব্যাখ্যা করা যাবে না। রূপান্তরের সময় সবচেয়ে গুরুত্বপূর্ণ ক্রিয়াগুলির মধ্যে একটি হল প্রতিটি ছোট ছিদ্রে নতুন, সংকীর্ণ পরীক্ষার সীমানা যোগ করা, যাতে পরীক্ষাটি ধীরে ধীরে “ঐতিহাসিক উত্তরাধিকার” থেকে “বর্তমান সীমাবদ্ধতায়” পরিবর্তিত হয়। Copilot পুরানো দাবী, সম্পূর্ণ টেমপ্লেট, এবং ডুপ্লিকেট পরীক্ষা শেল রোল আউট ভেঙে সাহায্য করতে পারে। যাইহোক, পরীক্ষায় কি শব্দার্থতত্ত্ব বজায় রাখা উচিত এবং মডেল সিস্টেমের জন্য সিদ্ধান্ত নিতে পারে না।

প্রত্নতাত্ত্বিক আধুনিকায়নে, শ্রমের সবচেয়ে নির্ভরযোগ্য বিভাজনটি আসলে খুব সহজ: পরিবেশ এবং লগগুলি সত্যকে পেরেক দেওয়ার জন্য দায়ী, কোপাইলট ইট সরানো এবং অনুবাদ করার জন্য দায়ী, এবং কোন ইতিহাসটি ধরে রাখা উচিত এবং কোন ইতিহাসটি কেটে ফেলা উচিত তা সিদ্ধান্ত নেওয়ার জন্য জনগণ দায়বদ্ধ। একবার সিস্টেমের অতীত ব্যাখ্যা করার জন্য একটি মডেল সাজানো হলে, এটি প্রায়শই প্রমাণের চেয়ে অনুমানকে আরও বিশ্বাসযোগ্য করে তোলে; এটিকে প্রমাণ ব্যবস্থাপনা এবং যান্ত্রিক সংস্থার অবস্থানে ফিরিয়ে দিলে, এটি সত্যিকারের দরকারী সহকারীর মতো হয়ে ওঠে।