2.19 রিফ্যাক্টরিং ও প্রযুক্তিগত ঋণ

পরিচিতি ও প্রেরণা

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

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

এন্টারপ্রাইজ ও সরকারি পরিবেশে ঝুঁকি বাড়ে। এই সিস্টেম দীর্ঘজীবী, প্রায়ই কয়েক দশকের পুরোনো, এবং প্রায়ই নিরীক্ষা ও পরিবর্তন-নিয়ন্ত্রণ ব্যবস্থার অধীন, যা যেকোনো কোড পরিবর্তনকে নিয়ন্ত্রিত ঘটনা গণ্য করে। আপনি একটি দীর্ঘ সপ্তাহান্তে নাগরিক সুবিধা সিস্টেম পুনর্লিখন করতে পারেন না; আপনি তা আধুনিক করেন ছোট, ফেরানো-যায়, প্রমাণ-সমর্থিত ধাপে, যা ঠিক শৃঙ্খলাবদ্ধ রিফ্যাক্টরিং আপনাকে দেয়। বহু দল ও দীর্ঘজীবী সিস্টেম জুড়ে সেই কাজ সমন্বয় করা (অধ্যায় 10.4) বড় পরিসরের প্রকৌশলের অন্যতম সংজ্ঞায়ক চ্যালেঞ্জ, এবং তা ভুল হলে প্রতিষ্ঠান জমে যায়, যে সফটওয়্যার আর বোঝে না তা বদলাতে পারে না।

মূল নীতিসমূহ

• রিফ্যাক্টরিং আচরণ সংরক্ষণ করে; কোড যা করে তা বদলালে সেটি আলাদা পরিবর্তন, আলাদাভাবে করা।
• একটি বিশ্বাসযোগ্য টেস্ট স্যুট নিরাপদ রিফ্যাক্টরিংয়ের পূর্বশর্ত, ঐচ্ছিক বাড়তি নয়।
• ছোট, নামকরা, ফেরানো-যায় ধাপে কাজ করুন, এবং প্রতিটির পরে কোড সচল রাখুন।
• প্রযুক্তিগত ঋণ দৃশ্যমান ও অনুসরণযোগ্য করুন, তারপর শোধ বীরত্বে নয়, স্থির সক্ষমতা হিসেবে অর্থায়ন করুন।
• আপনি যে কোড ইতিমধ্যে বদলাচ্ছেন তা রিফ্যাক্টর করুন, যেখানে পরিষ্কার নিজের মূল্য তোলে।
• সব ঋণ শোধের যোগ্য নয়; স্থিতিশীল, কদাচিৎ-ছোঁয়া বা শীঘ্র-অবসরে-যাওয়া কোড একা ছেড়ে দেওয়া যায়।
• বিচারকে জানাতে অভ্যন্তরীণ গুণমান মাপুন, কখনো খেলার লক্ষ্য হিসেবে নয়।

সুপারিশ

রিফ্যাক্টরিং ও আচরণ পরিবর্তন কঠোরভাবে আলাদা রাখুন

শুরুর আগে ঠিক করুন আপনি কোনটি করছেন, এবং একটি কমিটে দুটিকে কখনো মেশাবেন না। রিফ্যাক্টর করার সময় আগে পাস করা টেস্ট পরে অপরিবর্তিত অবস্থায় পাস করতে হবে, কারণ পর্যবেক্ষণযোগ্য আচরণ নড়েনি। আচরণ বদলানোর সময় তা নিজস্ব কমিট ও নিজস্ব টেস্টসহ করুন। কারণ ব্যবহারিক: মিশ্র পরিবর্তন কিছু ভাঙলে আপনি বলতে পারেন না আপনার পুনর্গঠন ত্রুটি এনেছে নাকি আপনার আচরণ পরিবর্তন, আর কোড পর্যালোচনায় (অধ্যায় 2.5) পর্যালোচক কোনো অর্ধেক নিয়েই পরিষ্কারভাবে যুক্তি করতে পারেন না। যে অভ্যাস কাজ করে তা Martin Fowler-এর দুই-টুপির নিয়ম: আপনি সবসময় রিফ্যাক্টরিং টুপি নয়তো ফিচার টুপি পরে আছেন, আপনি জানেন কোনটি, এবং ইচ্ছাকৃতভাবে বদলান। আলাদা কমিট সংস্করণ নিয়ন্ত্রণ ইতিহাসও পাঠযোগ্য করে, তাই ব্যর্থতায় বাইসেক্ট করা ইঞ্জিনিয়ার আত্মবিশ্বাসে বিশুদ্ধ-রিফ্যাক্টর কমিট এড়িয়ে যেতে পারেন।

পুনর্গঠনের আগে একটি বিশ্বাসযোগ্য সুরক্ষা জাল স্থাপন করুন

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

কোড স্মেল চিনতে শিখুন এবং ছোট নামকরা রিফ্যাক্টরিং প্রয়োগ করুন

একটি কোড স্মেল হলো একটি ওপরের লক্ষণ যে নিচে কিছুতে মনোযোগ দরকার হতে পারে: বড় হয়ে ওঠা একটি ফাংশন, অনেক বেশি জানা একটি ক্লাস, পুনরাবৃত্ত যুক্তি, লম্বা প্যারামিটার তালিকা, যা করে সে সম্পর্কে মিথ্যা বলা নাম। স্মেল একটি ইঙ্গিত, রায় নয়, তাই আপনি অন্ধভাবে মানার বদলে তদন্ত করেন। সাড়া হলো Fowler-এর ক্যাটালগ থেকে একটি ছোট, নামকরা রিফ্যাক্টরিং: Extract Function, Rename Variable, Move Method, Replace Conditional with Polymorphism, এবং আরও কয়েক ডজন। নামকরা পদক্ষেপ ব্যবহারের মূল্য হলো প্রতিটি ছোট, বোঝা, যান্ত্রিকভাবে নিরাপদ, এবং প্রায়ই সরাসরি আপনার IDE সমর্থিত। আপনি যাচাই করতে পারেন না এমন একটি বড় লাফের বদলে অনেক ক্ষুদ্র নির্ভরযোগ্য ধাপ থেকে বড় উন্নতি গড়েন, পুরোটা সময় কোড সবুজ রেখে।

সুযোগসন্ধানী রিফ্যাক্টরিং পছন্দ করুন, এবং প্রকৃত কাঠামোগত প্রয়োজনে অভিযান সংরক্ষণ করুন

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

বড় কাঠামোগত পরিবর্তনের জন্য স্ট্র্যাংলার ফিগ প্যাটার্ন ব্যবহার করুন

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

প্রযুক্তিগত ঋণকে একটি পোর্টফোলিও গণ্য করুন এবং দৃশ্যমান করুন

Ward Cunningham-এর উদ্ভাবিত ঋণের রূপক দুটি জিনিস আলাদা করে: মূলধন (অগোছালো কোড বা শর্টকাট নিজেই) এবং সুদ (তার কারণে প্রতিটি ভবিষ্যৎ পরিবর্তন যে বাড়তি পরিশ্রম দেয়)। সব ঋণ সমান নয়। Fowler-এর চতুর্ভুজ তাকে দুই অক্ষে সাজায়: ইচ্ছাকৃত বনাম অনিচ্ছাকৃত, এবং বিচক্ষণ বনাম বেপরোয়া। বিচক্ষণ-ইচ্ছাকৃত ঋণ (“আমরা এখন পাঠাই আর পরের স্প্রিন্টে পরিষ্কার করি, এবং খরচ জানি”) বৈধ ব্যবসায়িক সিদ্ধান্ত। বেপরোয়া-অনিচ্ছাকৃত ঋণ (“ডিজাইন প্যাটার্ন কী?“) শুধু ক্ষতি। ব্যবস্থাপনার কাজ, যা সিদ্ধান্ত গ্রহণ ও শাসন (অধ্যায় 1.5) এবং ঋণকে পোর্টফোলিও হিসেবে তার আলোচনার সঙ্গে যুক্ত, ঋণ দৃশ্যমান করা যাতে তা নিয়ে যুক্তি করা যায়: কাজ যেখানে বাস করে সেখানে উল্লেখযোগ্য আইটেম অনুসরণ করুন, কোড ট্যাগ করুন, এবং আপনি যে সুদ দিচ্ছেন তা লিপিবদ্ধ করুন যাতে শোধ সক্ষমতার জন্য প্রমাণে প্রতিযোগিতা করে, সবচেয়ে জোরে যে অভিযোগ করে তার ওপর নয়। যে ঋণ দেখতে পান না তা সামলাতে পারেন না।

শোধ অর্থায়ন করুন স্থির সক্ষমতা হিসেবে, বীরত্ব নয়

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

অভ্যন্তরীণ গুণমান মাপুন, কিন্তু মাপকে লক্ষ্য হতে দেবেন না

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

কখন রিফ্যাক্টর করবেন না তা জানুন

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

ট্রেড-অফ: সুবিধা ও অসুবিধা

পদ্ধতি	সুবিধা	অসুবিধা
সুযোগসন্ধানী রিফ্যাক্টরিং (স্কাউট-নিয়ম)	সস্তা, নিরন্তর, আলাদা বাজেট লাগে না, সময়ের সঙ্গে চক্রবৃদ্ধি	অসম কভারেজ; গরম ফাইল উন্নত হয় আর ঠান্ডাগুলো পচে
পরিকল্পিত রিফ্যাক্টরিং অভিযান	যে কাঠামোগত সমস্যায় পরিষ্কার পৌঁছায় না তা সারে	ব্যয়বহুল; ফিচারের সঙ্গে প্রতিযোগিতা করে; ভালো টেস্ট ছাড়া ঝুঁকিপূর্ণ
স্ট্র্যাংলার ফিগ / ব্রাঞ্চ বাই অ্যাবস্ট্র্যাকশন	ক্রমবর্ধমান, ফেরানো-যায়, সিস্টেম সচল রাখে, ঝুঁকি সীমিত করে	কাগজে পুনর্লিখনের চেয়ে ধীর; শেষ করতে শৃঙ্খলা লাগে
বিগ-ব্যাং পুনর্লিখন	পরিষ্কার স্লেট; লিগ্যাসি সীমাবদ্ধতা নেই	উচ্চ ব্যর্থতার হার; মূল্য পেতে দীর্ঘ সময়; আচরণের ফাঁক
ইচ্ছাকৃত বিচক্ষণ ঋণ	এখনই মূল্য পাঠায়; সুস্পষ্ট, পরিকল্পিত শোধ	শোধ কখনো সময়সূচি না হলে বেপরোয়া হয়ে যায়
মেট্রিক-গেটেড গুণমান	বস্তুনিষ্ঠ, দৃশ্যমান, ক্ষয় আগে ধরে	খেলাকে আমন্ত্রণ জানায়; সূক্ষ্মতা শাস্তি দেয়; প্রকৃত গুণমান নষ্ট করতে পারে

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

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

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

2. আমাদের প্রযুক্তিগত ঋণ কোথায়, তার ওপর আমরা কত সুদ দিচ্ছি, এবং কী শোধ হবে তা কে ঠিক করে? বেশিরভাগ দল এর উত্তর দিতে পারে না, যা আসল সমস্যা, কারণ যে ঋণ দেখা যায় না তা খরচ আসলে যেখানে সেখানে নয়, যে সবচেয়ে জোরে অভিযোগ করে তার দ্বারা পরিচালিত হয়। দৃশ্যমান করা মানে উল্লেখযোগ্য আইটেম অনুসরণ করা, কোড ট্যাগ করা, এবং কোন এলাকা পরিবর্তন ধীর ও ব্যর্থতা-প্রবণ করে তার প্রমাণ জমানো। প্রতিদ্বন্দ্বী টান হলো শোধে ব্যয় করা প্রতিটি ঘণ্টা ফিচারে ব্যয় না করা একটি ঘণ্টা, তাই সিদ্ধান্তটি নেতৃত্বের সঙ্গে নেওয়া পোর্টফোলিও সিদ্ধান্ত হতে হবে, যা আপনি প্রকৌশল কাজ কীভাবে শাসন করেন (অধ্যায় 1.5) তার সঙ্গে যুক্ত। আপনার পরিবর্তন-ব্যর্থতার তথ্য এবং সবাই যে ফাইল ছুঁতে ভয় পায় তার তালিকা আনুন। উত্তর একটি সুরক্ষিত, স্থির শোধ-সক্ষমতায় পরিণত হওয়া উচিত, জিনিস শান্ত হলে পরিষ্কার করার অস্পষ্ট ইচ্ছায় নয়।

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

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

5. একটি সাবসিস্টেম সত্যিই প্রতিস্থাপন করতে হলে ক্রমবর্ধমান স্ট্র্যাংলার ফিগ পদ্ধতি ও পুনর্লিখনের মধ্যে কীভাবে ঠিক করব, এবং পুনর্লিখনে না বলার কর্তৃত্ব কার? বিগ-ব্যাং পুনর্লিখন টেবিলের সবচেয়ে প্রলুব্ধকর ও সবচেয়ে ব্যর্থতা-প্রবণ বিকল্প, কারণ কাগজে পরিষ্কার স্লেট সবসময় পুরোনো সীমাবদ্ধতা নিয়ে বাঁচার চেয়ে সস্তা দেখায়। একটি বড় প্রতিষ্ঠানের জন্য ক্রমবর্ধমান পথ (একটি ফাসাদ, একবারে একটি টুকরো, প্রোডাকশনে যাচাই) সিস্টেম বাঁচিয়ে রাখে ও ঝুঁকি সীমিত করে, কিন্তু তা ধীর, শেষ করতে শৃঙ্খলা দাবি করে, এবং নতুন করে শুরুর ক্ষুধার সঙ্গে প্রতিযোগিতা করে। সাবসিস্টেমের পরিবর্তন-ঘনত্ব মানচিত্র, মূল্য দেওয়ার আগে পুনর্লিখন কতদিন চলত তার সৎ অনুমান, এবং সমান্তরাল পুনর্লিখনকে যে আচরণের ফাঁক বন্ধ করতে হতো তা আনুন। সরকারি ও নিয়ন্ত্রিত পরিবেশে শেষে মার্জ হওয়া বহু-বছরের পুনর্লিখন নিরীক্ষার অধীনে কদাচিৎ টেকে, তাই উত্তরের ডিফল্ট হওয়া উচিত স্ট্র্যাংলার ফিগ বা ব্রাঞ্চ বাই অ্যাবস্ট্র্যাকশন এবং যেকোনো পুনর্লিখনকে প্রমাণ দিয়ে যুক্তি দিয়ে প্রতিষ্ঠা করা ব্যতিক্রম গণ্য করা।

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

খাতভেদে দৃষ্টিভঙ্গি

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

ছোট ব্যবসা। কোনো নিবেদিত প্ল্যাটফর্ম বা টুলিং বিশেষজ্ঞ নেই আর বাজেট কম, তাই আপনার IDE এবং ভাষা ইকোসিস্টেম বিনামূল্যে যা দেয় তার ওপর ভরসা করুন: স্বয়ংক্রিয় rename ও extract পদক্ষেপ, একটি লিন্টার, এবং একটি মৌলিক কভারেজ সংকেত। বেশিরভাগ ঋণ স্বাভাবিক কাজের ধারায় সামলানো কিছু ভাবুন, সারাতে পরামর্শদাতা নিয়োগের কিছু নয়, এবং নিজের বানিয়ে পরে রিফ্যাক্টর করার চেয়ে ভালো-রক্ষণাবেক্ষণ হওয়া লাইব্রেরি কেনা পছন্দ করুন। বিরল অর্থ-ব্যয়ী প্রচেষ্টা সংরক্ষণ করুন সেই একটি সিস্টেমের জন্য, যার ধীরতা সরাসরি আপনার গ্রাহক খরচ করছে।

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

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

উদাহরণ

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

এন্টারপ্রাইজ। একটি বৈশ্বিক লজিস্টিক্স কোম্পানি পনেরো বছরের পুরোনো একটি অর্ডার সিস্টেম চালায় যা অনেক দল প্রতি সপ্তাহে বদলায়। পুনর্লিখনের বদলে তারা স্ট্র্যাংলার ফিগ প্যাটার্ন গ্রহণ করে: মনোলিথের সামনে একটি ফাসাদ বসে, এবং একবারে একটি সীমিত সামর্থ্য তার পেছনের নতুন সার্ভিসে পুনঃপথ হয়, পরের টুকরো শুরুর আগে প্রোডাকশনে যাচাই হয়ে। এটি দল ও একটি দীর্ঘজীবী সিস্টেম জুড়ে সমন্বয় করা (অধ্যায় 10.4) কঠিন অংশ, তাই তারা একটি ভাগ করা ঋণ রেজিস্টার রাখে, পরিবর্তন-ঘনত্ব ও জটিলতা দিয়ে হটস্পট ট্যাগ করে, এবং শোধের জন্য প্রতিটি দলের সক্ষমতার একটি নির্দিষ্ট অংশ সংরক্ষণ করে। অভ্যন্তরীণ-গুণমান মেট্রিক কোথায় দেখতে হবে তা জানায় কিন্তু কারও পারফরম্যান্স পর্যালোচনা গেট করে না, যা সংখ্যাগুলো সৎ রাখে। দুই বছরে মনোলিথ স্থিরভাবে ছোট হয় এবং কোনো একক পরিবর্তন কখনো পুরো সিস্টেমকে ঝুঁকিতে ফেলে না।

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

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

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

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

অ্যান্টি-প্যাটার্ন ও ফাঁদ

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

পরিপক্বতা মডেল

• স্তর ১, সূচনা: রিফ্যাক্টরিং অ্যাড হক ও প্রতিক্রিয়াশীল, প্রায়ই একই কমিটে আচরণ পরিবর্তনের সঙ্গে মেশানো। কোনো বিশ্বাসযোগ্য সুরক্ষা জাল নেই, প্রযুক্তিগত ঋণ অদৃশ্য ও অনুসরণহীন, এবং পরিষ্কার ঘটে কেবল মাঝেমধ্যের বীরত্বপূর্ণ বিস্ফোরণে বা একেবারেই নয়।
• স্তর ২, বিকাশ: কিছু দল রিফ্যাক্টরিংকে আচরণ পরিবর্তন থেকে আলাদা করে এবং যেখানে আছে সেখানে টেস্টের ওপর ভরসা করে, আর নামকরা রিফ্যাক্টরিং ও চারিত্র্য-নির্ণায়ক টেস্ট কোনো কোনো জায়গায় দেখা দেয়। দল জুড়ে চর্চা অসঙ্গত, ঋণ আলোচিত ও কখনো লগ করা হয়, এবং শোধ অ্যাড হকভাবে ফিচারের বিপরীতে প্রতিযোগিতা করে ও সাধারণত হারে।
• স্তর ৩, মানসম্মতকরণ: দুই-টুপি শৃঙ্খলা, লিগ্যাসি কোডের জন্য চারিত্র্য-নির্ণায়ক টেস্ট, এবং ছোট নামকরা রিফ্যাক্টরিং নথিবদ্ধ এবং সর্বত্র প্রত্যাশিত। ঋণ একটি ভাগ করা রেজিস্টারে অনুসরণ করা হয় যা মূলধন ও সুদ আলাদা করে, এবং শোধের জন্য সুরক্ষিত সক্ষমতা প্রতিটি চক্রে পরিকল্পিত ও পর্যালোচনায় প্রয়োগ করা হয়।
• স্তর ৪, ব্যবস্থাপনা: ঋণ ও পরিষ্কার ভিত্তিরেখার বিপরীতে তথ্য দিয়ে মাপা ও নিয়ন্ত্রিত। আপনি হটস্পট খুঁজতে পরিবর্তন-ঘনত্ব ও জটিলতা অনুসরণ করেন, রিফ্যাক্টর করা এলাকায় পরিবর্তন-ব্যর্থতার হার ও পরিবর্তন লিড টাইম লক্ষ্য রাখেন, এবং প্রতিটি উল্লেখযোগ্য আইটেমের সুদ কত খরচ তা লিপিবদ্ধ করেন, তাই শোধ সিদ্ধান্ত প্রমাণের ওপর দাঁড়ায় এবং বাদ-দেওয়া-বা-বিনিয়োগের সিদ্ধান্ত অভিযোগের পরিমাণের বদলে প্রবণতায় নেওয়া হয়। গুণমান সংকেত এমন গেটে না বেঁধে বিনিয়োগকে জানায়, যা মানুষ খেলতে পারে।
• স্তর ৫, সমন্বয়: ঋণ একটি নিরন্তর পুনর্ভারসাম্যে আনা পোর্টফোলিও হিসেবে পরিচালিত, যা পুরো প্রতিষ্ঠান জুড়ে পণ্য ও রক্ষণাবেক্ষণ পরিকল্পনার সঙ্গে একীভূত। কাঠামোগত পরিবর্তন নিয়মিত দল জুড়ে সমন্বিত স্ট্র্যাংলার ফিগ ও ব্রাঞ্চ বাই অ্যাবস্ট্র্যাকশন ব্যবহার করে, শোধ নিরন্তর এবং যেখানে পরিবর্তন ঘন ঘন ও যন্ত্রণাদায়ক সেখানে মেলানো, এবং সিস্টেম ও তার ঝুঁকির চিত্র সরলে চর্চা খাপ খায়, তাই দীর্ঘজীবী কোড দশকের পর দশক বদলানো-যায় থাকে।

আলোচনার ভাবনা

1. রিফ্যাক্টরিংকে আচরণ পরিবর্তন থেকে আলাদা রাখার জন্য আপনার দলের প্রকৃত, প্রয়োগ করা নিয়ম কী, এবং সময়সীমার চাপে তা কোথায় ভাঙে?
2. কোন কোডের পরিষ্কার প্রাপ্য আর কোনটি একা ছাড়াই ভালো, তা প্রমাণ দিয়ে কীভাবে ঠিক করেন?
3. যে লিগ্যাসি এলাকা আপনি বর্তমানে এড়িয়ে চলেন, চারিত্র্য-নির্ণায়ক টেস্ট কোথায় আপনাকে সেটি নিরাপদে রিফ্যাক্টর করতে দিত?
4. আপনার পরবর্তী বড় আধুনিকীকরণের জন্য স্ট্র্যাংলার ফিগ পদ্ধতি কেমন দেখাত, এবং আপনি প্রথমে কোন ফাসাদ বা অ্যাবস্ট্র্যাকশন আনতেন?
5. প্রযুক্তিগত-ঋণ রেজিস্টারের মালিক কে, এবং শোধ ফিচার কাজের বিপরীতে আসলে কীভাবে সক্ষমতা জেতে?

প্রধান শিক্ষা

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

তথ্যসূত্র ও আরও পড়ার জন্য

• Martin Fowler, Refactoring: Improving the Design of Existing Code, দ্বিতীয় সংস্করণ
• Michael Feathers, Working Effectively with Legacy Code
• Ward Cunningham, The WyCash Portfolio Management System (OOPSLA 1992 অভিজ্ঞতা প্রতিবেদন, ঋণ রূপকের উৎস)
• Martin Fowler, “TechnicalDebtQuadrant” এবং “StranglerFigApplication” (martinfowler.com)
• Kent Beck, Tidy First? A Personal Exercise in Empirical Software Design
• Steve McConnell, Code Complete: A Practical Handbook of Software Construction
• Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship