ডেভেলপমেন্টে মৃত কোড এবং জম্বি কোড: কী, কারণ এবং অনুসন্ধান

লেখক: IT Sectr প্রকাশিত: 2026-07-26 পড়ার সময়: 10 মিনিট

মৃত কোড — প্রোগ্রামের সেই টুকরো যা কখনো নির্বাহিত হয় না এবং ফলাফলকে প্রভাবিত করে না, কিন্তু প্রকল্পের সোর্স ফাইলে শারীরিকভাবে থেকে যায়। মন্তব্য করা অংশের বিপরীতে, মৃত কোড কম্পাইল হয় এবং বাইনারিতে অন্তর্ভুক্ত হয়, যার আকার বাড়ায় এবং নেভিগেশন জটিল করে তোলে। TIOBE Index (2025) গবেষণা অনুসারে, গড় বাণিজ্যিক প্রকল্পে 10 থেকে 25 শতাংশ কোড থাকে যা কখনো কল করা হয় না। জম্বি কোড — মৃত কোডের একটি উপপ্রকার যা অতীতে কাজ করত, কিন্তু রিফ্যাক্টরিংয়ের পরে প্রাসঙ্গিকতা হারিয়েছে এবং এখন কেবল জায়গা দখল করে আছে। এই ধরনের টুকরোগুলির নিয়মিত পরিষ্কার ডেভেলপারদের জ্ঞানীয় বোঝা কমায় এবং পরিবর্তন আনার সময় ত্রুটির ঝুঁকি হ্রাস করে।

মূল বিষয়

  • মৃত কোড — টুকরো যা কখনো নির্বাহিত হয় না, কিন্তু প্রকল্পে থেকে যায়।
  • জম্বি কোড — কোড যা আগে নির্বাহিত হত, কিন্তু পরিবর্তনের পরে অপ্রাপ্য হয়েছে।
  • মৃত কোড বাইনারির আকার, বিল্ড সময় এবং টিমের জ্ঞানীয় বোঝা বাড়ায়।
  • প্রধান অনুসন্ধান সরঞ্জাম: স্ট্যাটিক বিশ্লেষণ (SonarQube, ESLint) এবং কভারেজ প্রোফাইলার।
  • মৃত কোড নিরাপদে মুছুন টেস্ট কভারেজ পরীক্ষা এবং কোড রিভিউর মাধ্যমে।

মৃত কোড কী?

মৃত কোড (dead code) — সেই সোর্স কোড যা প্রোগ্রামে অন্তর্ভুক্ত, কিন্তু ব্যবহারের যেকোনো পরিস্থিতিতে কখনো নির্বাহিত হয় না। কম্পাইলার বা ইন্টারপ্রেটার এটি প্রক্রিয়া করে, কিন্তু রানটাইমে নিয়ন্ত্রণ কখনো এই অংশে যায় না।

মৃত কোডের ক্লাসিক উদাহরণ: ভেরিয়েবল যাদের মান নির্ধারণ করা হয়েছে কিন্তু কখনো পড়া হয় না; ফাংশন বা মেথড যা কোথাও কল করা হয় না; শর্ত শাখা যা কখনো সত্য হয় না (if(false)); লুপ যাদের বডি একবারও নির্বাহিত হয় না।

SonarQube State of Code Quality (2025) রিপোর্ট অনুসারে, বাণিজ্যিক Java প্রকল্পে প্রায় 15 শতাংশ সতর্কতা অব্যবহৃত private মেথড এবং ফিল্ডের সাথে সম্পর্কিত। JavaScript প্রকল্পে, ভাষার গতিশীল প্রকৃতি এবং থার্ড-পার্টি লাইব্রেরির প্রাচুর্যের কারণে অব্যবহৃত কোডের হার 30 শতাংশ পর্যন্ত পৌঁছাতে পারে।

নিয়মিত আপনার প্রকল্পে মৃত কোডের উপস্থিতি পরীক্ষা করুন — বিশেষ করে বড় রিফ্যাক্টরিং এবং ফিচার মুছে ফেলার পরে। একটি ভুলে যাওয়া import বা আজকের অব্যবহৃত ফাংশন আগামীকাল জম্বি কোডে পরিণত হতে পারে যা টিমের নতুন সদস্যদের বিভ্রান্ত করে।

মৃত কোড এবং জম্বি কোডের পার্থক্য

জম্বি কোড (zombie code) — মৃত কোডের একটি বিশেষ ক্ষেত্র যা ঐতিহাসিক প্রেক্ষাপটে ভিন্ন। জম্বি কোড একসময় কাজ করত, কিন্তু সিস্টেমে পরিবর্তনের পরে অপ্রাপ্য হয়ে গেছে, তবুও এটি মুছে ফেলা হয়নি, বরং «যদি প্রয়োজন হয়» রেখে দেওয়া হয়েছে।

মৃত এবং জম্বি কোডের মধ্যে পার্থক্য — উৎপত্তিতে। মৃত কোড ভুলভাবে লেখা হতে পারে (কখনো কাজ করেনি), যেখানে জম্বি কোড — পূর্বের জীবিত কোড যা রিফ্যাক্টরিংয়ের পরে প্রাসঙ্গিকতা হারিয়েছে। উদাহরণস্বরূপ, পুরানো ব্যবসায়িক যুক্তি অনুসারে ডিসকাউন্ট গণনা ফাংশন যা নতুন দিয়ে প্রতিস্থাপিত হয়েছে, কিন্তু পুরানো মেথডটি মুছে ফেলা হয়নি — প্রয়োজনে ফিরে আসার জন্য।

প্রধান বিপদ জম্বি কোডের — কার্যকারিতার মায়া। একজন নতুন ডেভেলপার ফাংশন দেখে, তার ডকুমেন্টেশন পড়ে, ধরে নেয় এটি কোথাও কল করা হয় — এবং একটি আর্টিফ্যাক্ট অধ্যয়নে সময় নষ্ট করে। এটি সরাসরি কল করার চেষ্টায় দেখা যেতে পারে যে এটি মুছে ফেলা সত্ত্বা বা পুরানো API-র উপর নির্ভর করে।

git ইতিহাসের মাধ্যমে জম্বি কোড ট্র্যাক করুন: যদি কোনো ফাংশন দুই বছর ধরে পরিবর্তিত না হয় এবং ব্যবহার না হয় — এটি জম্বি। দ্বিধা ছাড়াই এটি মুছে ফেলুন, কারণ git ইতিহাস রাখে, এবং প্রয়োজন হলে কোড সবসময় পুনরুদ্ধার করা যেতে পারে।

মৃত কোডের উপস্থিতির কারণ

প্রথম এবং সবচেয়ে সাধারণ কারণ — পুনরাবৃত্তিমূলক উন্নয়ন অসম্পূর্ণ রিফ্যাক্টরিং সহ। টিম পুরানোটিকে প্রতিস্থাপন করে নতুন কার্যকারিতা যোগ করে, কিন্তু প্রতিস্থাপিত মডিউল মুছে ফেলে না। স্প্রিন্ট এই ধরনের «লেজ» জমা করে, এবং এক বছর পর প্রকল্প মৃত কোডের স্তরে আবৃত হয়ে যায়।

দ্বিতীয় কারণ — A/B পরীক্ষণ এবং ফিচার টগল। নতুন ফিচার চালু করার শর্ত সময়ের সাথে স্থির হতে পারে (উদাহরণস্বরূপ, সবসময় true), কিন্তু else শাখা বিকল্প যুক্তি সহ কোডে থাকে। ডেভেলপাররা এটি মুছতে ভয় পান যাতে ভুলবশত সিস্টেম ভেঙে না যায় যদি টগল আবার সুইচ করা হয়।

তৃতীয় কারণ — স্বয়ংক্রিয় জেনারেশন এবং কপি-পেস্ট। কোড জেনারেটর (IDE, টেমপ্লেটাইজার) মেথড সহ টেমপ্লেট তৈরি করে যা ডেভেলপার পূরণ করে না বা ব্যবহার করে না। অন্য প্রকল্প থেকে কপি করা কোডে প্রায়ই সম্পূর্ণ ব্লক থাকে যা নতুন প্রসঙ্গের জন্য প্রাসঙ্গিক নয়।

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

মৃত কোড কতটা বিপজ্জনক

মৃত কোড সরাসরি প্রকল্পের গুণমানের চারটি দিককে প্রভাবিত করে: বিল্ড পারফরম্যান্স, আর্টিফ্যাক্ট আকার, টিমের জ্ঞানীয় বোঝা এবং রিফ্যাক্টরিংয়ের নির্ভরযোগ্যতা।

কম্পাইলেশন সময় বৃদ্ধি: কম্পাইলার অব্যবহৃত ফাইল প্রক্রিয়া করে, নির্ভরতা বিশ্লেষণ করে এবং সেই টুকরোগুলির জন্য বাইট-কোড বা মেশিন কোড তৈরি করে যা কখনো চলবে না। বড় প্রকল্পে, এটি প্রতিটি বিল্ডে মিনিট যোগ করে। ইন্টারপ্রেটেড ভাষার (JavaScript, Python) জন্য, মডিউল লোডের সময় এবং মেমরি খরচ বাড়ে।

পরিবর্তনের সময় বাগের ঝুঁকি: ডেভেলপার কোড পরিবর্তন করে এবং সন্দেহ করে না যে ফাংশনটি শুধু মৃত শাখায় ব্যবহৃত হয়। রিফ্যাক্টরিংয়ের পরে মৃত কোড কম্পাইল করা বন্ধ করে দেয় বা ত্রুটি উৎপন্ন করে — টিম একটি সমস্যা নির্ণয়ে সময় নষ্ট করে যা অ্যাপ্লিকেশনের কাজকে প্রভাবিত করে না।

জ্ঞানীয় বোঝা — সবচেয়ে ব্যয়বহুল ফ্যাক্টর। প্রতিটি অব্যবহৃত ফাংশন কোড পড়ার সময় মনোযোগ দাবি করে। ডেভেলপার মানসিক শক্তি ব্যয় করে বুঝতে যে এই কোড কেন বিদ্যমান এবং এটি কোথায় কল করা হয়। Developer Productivity Lab (2025) গবেষণায় দেখা গেছে: 20 শতাংশ মৃত কোড মুছে ফেলা অনবোর্ডিং সময় গড়ে 18 শতাংশ কমায়।

আবিষ্কারের সাথে সাথেই মৃত কোড মুছে ফেলুন। প্রতিদিন বিলম্ব সম্ভাবনা বাড়ায় যে টিমের কেউ একটি আর্টিফ্যাক্ট অধ্যয়নে ঘন্টা নষ্ট করবে যা গতকালই মুছে ফেলা উচিত ছিল।

মৃত কোড অনুসন্ধানের সরঞ্জাম

মৃত কোড অনুসন্ধান দুটি প্রধান পদ্ধতিতে করা হয়: স্ট্যাটিক বিশ্লেষণ (প্রোগ্রাম না চালিয়ে) এবং ডায়নামিক বিশ্লেষণ (রানটাইমে কভারেজ প্রোফাইলিং)। প্রতিটি পদ্ধতি বিভিন্ন ধরনের মৃত কোডের জন্য কার্যকর।

স্ট্যাটিক বিশ্লেষক সকল জনপ্রিয় প্রোগ্রামিং ভাষা সমর্থন করে। Java এবং Kotlin-এর জন্য — SonarQube, IntelliJ IDEA Inspections, SpotBugs। JavaScript এবং TypeScript-এর জন্য — ESLint নিয়ম no-unused-vars এবং no-unused-modules সহ। Swift-এর জন্য — SwiftLint নিয়ম unused_declaration সহ। Python-এর জন্য — pylint অপশন unused-import এবং গভীর অনুসন্ধানের জন্য vulture সহ।

ProGuard-এর মাধ্যমে Kotlin-এ অনুসন্ধানের উদাহরণ

groovy
// build.gradle.kts - Android-এর জন্য ProGuard কনফিগারেশন
android {
    buildTypes {
        release {
            proguardFiles(
                getDefaultProguardFile("proguard-android-optimize.txt"),
                "proguard-rules.pro"
            )
        }
    }
}

// proguard-rules.pro - শুধু প্রয়োজনীয় ক্লাস রাখুন
-keep class com.example.app.** { *; }
-assumenosideeffects class Timber {
    static <methods>;
}

ProGuard শুধু অব্যবহৃত ক্লাস এবং মেথড মুছে ফেলে না, বরং রিলিজ বিল্ডে নামও ছোট করে। ProGuard সক্রিয় সহ বিল্ড স্বয়ংক্রিয়ভাবে দেখায় কোন ক্লাস এবং মেথড অব্যবহৃত বলে বিবেচিত হয় — usage.txt রিপোর্টে সমস্ত মুছে ফেলা কোড তালিকাভুক্ত থাকে।

টেস্ট কভারেজের মাধ্যমে ডায়নামিক বিশ্লেষণ

কোড কভারেজ সরঞ্জাম (Java-র জন্য JaCoCo, Swift-এর জন্য XCTest coverage, JavaScript-এর জন্য Istanbul) দেখায় টেস্টের সময় কোন লাইন এবং শাখা নির্বাহিত হয়। শূন্য কভারেজের মেথড — মৃত কোডের প্রার্থী। তবে কভারেজের অভাব গ্যারান্টি দেয় না যে কোড প্রোডাকশনে কল হয় না — সম্পূর্ণ নিশ্চিততার জন্য স্ট্যাটিক এবং ডায়নামিক বিশ্লেষণের সমন্বয় ব্যবহার করুন।

আপনার CI পাইপলাইন কনফিগার করুন যাতে অব্যবহৃত ঘোষণার সীমা অতিক্রম করলে বিল্ড ব্যর্থ হয়। SonarQube Quality Gate নিয়ম «অব্যবহৃত private কোডের অংশ 3% এর বেশি নয়» ডেভেলপমেন্ট প্রক্রিয়া স্তরে মৃত কোড জমা হওয়া প্রতিরোধ করে।

কীভাবে নিরাপদে মৃত কোড মুছবেন

মৃত কোড মুছে ফেলার প্রক্রিয়া চারটি ধাপ নিয়ে গঠিত: খুঁজুন, পরীক্ষা করুন, মুছুন, আবার পরীক্ষা করুন। যেকোনো ধাপ বাদ দিলে রিগ্রেশনের ঝুঁকি বাড়ে।

প্রথম ধাপ — স্ট্যাটিক বিশ্লেষকের মাধ্যমে প্রার্থী অনুসন্ধান। অব্যবহৃত ঘোষণার রিপোর্ট পান: ফাংশন, ক্লাস, ভেরিয়েবল, ইম্পোর্ট। মিথ্যা পজিটিভ ফিল্টার করুন — বিশ্লেষক কখনো রিফ্লেকশন, ডায়নামিক ক্লাস লোডিং বা সিরিয়ালাইজেশনের মাধ্যমে লুকানো কলের ক্ষেত্রে ভুল করে।

দ্বিতীয় ধাপ — git blame এবং পরিবর্তনের ইতিহাসের মাধ্যমে পরীক্ষা। দেখুন কোড কখন এবং কেন লেখা হয়েছিল। যদি কোড কোনো ফিচারের অংশ হয় যা ফিচার টগল দিয়ে বন্ধ — নিশ্চিত করুন টগল স্থির এবং আবার চালু হবে না। যে কোড মুছতে সন্দেহ হয় তা কমেন্ট করুন এবং এক মাস পর পুনরায় পরীক্ষার জন্য TODO টিকিট রেখে দিন।

তৃতীয় ধাপ — পৃথক শাখায় মুছে ফেলা টেস্টের সম্পূর্ণ সেট চালানোর সাথে। যদি টেস্ট পাস হয় — রিগ্রেশনের সম্ভাবনা কম। যদি টেস্ট ব্যর্থ হয় — তাহলে কোড এখনও ব্যবহৃত হচ্ছে, এবং কোন পরিস্থিতিতে তা বোঝা দরকার।

cpp
// before - মৃত কোড এবং জম্বি কোড একই ফাইলে
int calculateV1(int price) { // কোথাও কল করা হয়নি
    int tax = price * 0.18;
    return price + tax;
}

int calculateV2(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

// after - মৃত কোড মুছে ফেলা হয়েছে, জম্বি কোড পরিষ্কার করা হয়েছে
int calculatePrice(int price, double rate) {
    return static_cast<int>(price * (1 + rate));
}

চতুর্থ ধাপ — পরিবর্তনের কোড রিভিউ। রিভিউয়ারকে নিশ্চিত করতে হবে যে কোড সত্যিই মৃত। যদি রিভিউয়ার নিশ্চিত না হন — কোডে কমেন্ট রেখে সম্পূর্ণ বিশ্লেষণ পর্যন্ত মুছে ফেলা স্থগিত করুন। শাখা মার্জ করার পরে — শাখা মুছে ফেলুন যাতে git রিপোজিটoryতে জম্বি কোড না বাড়ে।

নিয়ম চালু করুন: কোনো পুল রিকোয়েস্টে নতুন মৃত কোড থাকা উচিত নয়। প্রি-কমিট হুকে লিন্টার যোগ করুন যা অব্যবহৃত ভেরিয়েবল বা ইম্পোর্ট থাকলে কমিট ব্লক করে। প্রতিরোধ সবসময় পরিষ্কারের চেয়ে সস্তা।

সচরাচর জিজ্ঞাসা

মৃত কোড কি কম্পাইলেশন ত্রুটি সৃষ্টি করতে পারে?

হ্যাঁ, যদি মৃত কোডে সিনট্যাক্স ত্রুটি থাকে বা মুছে ফেলা টাইপ উল্লেখ করে। আধুনিক কম্পাইলার এখনও মৃত শাখা পরীক্ষা করে, তাই if(false) ব্লকের ত্রুটি বিল্ড ব্যর্থতার কারণ হবে। এটি সুরক্ষা: কোড এতটা মৃত হওয়া উচিত নয় যে কম্পাইলার এটি পরীক্ষা না করে।

টিমের নতুনদের জন্য জম্বি কোড কতটা বিপজ্জনক?

জম্বি কোড বিভ্রান্ত করে: একজন নতুন ডেভেলপার ডকুমেন্টেশন সহ ফাংশন দেখে এবং ধরে নেয় এটি ব্যবহৃত হয়। সে অকার্যকর কোড অধ্যয়নে সময় নষ্ট করে এবং ভুলবশত পুরানো সত্তার উপর নতুন যুক্তি বাঁধতে পারে, যা খুঁজে পাওয়া কঠিন একটি বাগ তৈরি করে।

JavaScript প্রকল্পে মৃত কোড কীভাবে খুঁজবেন?

ESLint ব্যবহার করুন no-unused-vars এবং no-unused-modules নিয়মের সাথে, পাশাপাশি knip ইউটিলিটি — এটি সম্পূর্ণ প্রকল্প জুড়ে exports এবং imports বিশ্লেষণ করে, অব্যবহৃত ফাইল, ফাংশন এবং নির্ভরতা খুঁজে বের করে। বড় মনোরিপোজিটরির জন্য knip সবচেয়ে সম্পূর্ণ চিত্র দেখায়।

রিলিজের আগে কি মৃত কোড মুছতে হবে?

ভালো রিলিজের আগে মুছুন, কিন্তু শেষ মুহূর্তে নয়। মৃত কোড মুছে ফেলা — প্রযুক্তিগত কাজ যা স্প্রিন্টে আলাদাভাবে পরিকল্পনা করা হয়। রিলিজের ঠিক আগে মুছে ফেলা অস্থিতিশীলতা আনতে পারে যদি কোড ততটা মৃত না হয় যতটা মনে হয়েছিল।

কম্পাইলাররা কি স্বয়ংক্রিয়ভাবে মৃত কোড মুছতে সাহায্য করে?

হ্যাঁ, আধুনিক কম্পাইলার এবং মিনিফায়ার (ProGuard, R8, Terser, Closure Compiler) Dead Code Elimination স্তরে অপ্রাপ্য কোড মুছে ফেলে। তবে এটি সোর্স পরিষ্কারের প্রয়োজনীয়তা বাতিল করে না: কম্পাইলার বাইনারি থেকে কোড সরিয়ে দেয়, কিন্তু রিপোজিটরি থেকে নয় — ডেভেলপাররা পড়ার সময় এতে হোঁচট খেতে থাকে।

সারসংক্ষেপ

  • মৃত কোড — অব্যবহৃত টুকরো যা কখনো নির্বাহিত হয় না, কিন্তু প্রকল্পে থেকে যায়।
  • জম্বি কোড — মৃত কোডের উপপ্রকার যা আগে কাজ করত কিন্তু রিফ্যাক্টরিংয়ের পরে প্রাসঙ্গিকতা হারিয়েছে।
  • প্রধান উপস্থিতির কারণ: পুনরাবৃত্তিমূলক উন্নয়ন, ফিচার টগল, স্বয়ংক্রিয় জেনারেশন এবং মুছে ফেলার ভয়।
  • মৃত কোড বিল্ড সময়, বাইনারি আকার এবং টিমের জ্ঞানীয় বোঝা বাড়ায়।
  • অনুসন্ধান সরঞ্জাম: SonarQube, ESLint, SwiftLint, pylint, vulture, knip, ProGuard, JaCoCo।
  • নিরাপদ মুছে ফেলা অন্তর্ভুক্ত: অনুসন্ধান, git বিশ্লেষণ, শাখায় মুছে ফেলা, টেস্ট চালানো এবং কোড রিভিউ।
  • মৃত কোড প্রতিরোধ: CI-তে লিন্টার, কোড রিভিউতে অব্যবহৃত কোড সম্পর্কে সতর্কতা এবং রিফ্যাক্টরিং সংস্কৃতি।

আমরা একটি মোবাইল অ্যাপ্লিকেশন টার্নকি তৈরি করব

IT Sectr 2017 সাল থেকে স্টার্টআপ এবং ব্যবসার জন্য iOS এবং Android অ্যাপ্লিকেশন তৈরি করে। আমরা আপনাকে পরামর্শ দেব এবং সেরা সমাধান প্রস্তাব করব।

প্রকল্প নিয়ে আলোচনা করুন

আরও পড়ুন