স্প্যাগেটি কোড কী

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

খারাপ কোডের বিপরীতে, যা কেবল অগোছালো হতে পারে, স্প্যাগেটি কোড একটি মৌলিক আর্কিটেকচারাল সমস্যা। এমনকি ভাল ভেরিয়েবল নাম সহ নিখুঁতভাবে ফরম্যাট করা কোডও স্প্যাগেটি কোড হতে পারে যদি এর আর্কিটেকচার বিশৃঙ্খল হয়। সমস্যাটি প্রোগ্রাম কাঠামোর স্তরে, লেখার শৈলীতে নয়।

IEEE (2022) অনুসারে, বড় প্রকল্পগুলিতে প্রায় 35% ত্রুটির কারণ জটিল কোড কাঠামো, ডেভেলপারের লজিক্যাল ত্রুটি নয়। ডেভেলপার ভুল করে কারণ সে কাজটি ভুল বোঝেনি, বরং সে স্প্যাগেটি কোডে এক্সিকিউশন প্রবাহ অনুসরণ করতে পারেনি।

অন্যান্য অ্যান্টি-প্যাটার্ন থেকে মূল পার্থক্য

যদি খারাপ কোড একটি ফাংশন বা ফাইলের স্কেলে খারাপ কোড হয়, তাহলে স্প্যাগেটি কোড পুরো অ্যাপ্লিকেশনের স্কেলে খারাপ আর্কিটেকচার। নুডলস পৃথকভাবে ভালভাবে লেখা ফাংশন নিয়ে গঠিত হতে পারে, কিন্তু তাদের মিথস্ক্রিয়া বিশৃঙ্খল এবং অপ্রত্যাশিত।

শব্দটির ইতিহাস এবং goto যুগ

শব্দটি “স্প্যাগেটি কোড” ১৯৭০-এর দশকে goto স্টেটমেন্টের সমালোচনার সাথে আবির্ভূত হয়। প্রাথমিক প্রোগ্রামিং ভাষায় (BASIC, FORTRAN, COBOL), goto ছিল এক্সিকিউশন প্রবাহ নিয়ন্ত্রণের প্রধান উপায়। একটি প্রোগ্রাম ছিল সংখ্যাযুক্ত লাইনের একটি ক্রম, এবং goto সেগুলির যেকোনোটিতে লাফ দেওয়ার অনুমতি দিত। এটি লাফের একটি “জট” তৈরি করত যা সমাধান করা অসম্ভব ছিল।

১৯৬৮ সালে, এডসগার ডেইকস্ট্রা তার বিখ্যাত চিঠি “Go To Statement Considered Harmful” প্রকাশ করেন, যা স্ট্রাকচার্ড প্রোগ্রামিং যুগের সূচনা করে। ডেইকস্ট্রা প্রমাণ করেছিলেন যে যেকোনো অ্যালগরিদম goto ছাড়া, শুধুমাত্র তিনটি কাঠামো ব্যবহার করে বাস্তবায়ন করা যায়: ক্রম, শাখা (if) এবং লুপ (while)। এটি আধুনিক প্রোগ্রামিংয়ের ভিত্তি হয়ে ওঠে।

স্ট্রাকচার্ড প্রোগ্রামিং সমস্যাটি সম্পূর্ণরূপে দূর করতে পারেনি। স্প্যাগেটি কোড একটি নতুন স্তরে চলে গেছে — শারীরিক gotos-এর পরিবর্তে, ডেভেলপাররা লজিক্যাল “goto” তৈরি করতে শুরু করে: গ্লোবাল ভেরিয়েবল, জাভাস্ক্রিপ্টে কলব্যাক হেল, জটিল কল চেইন এবং কম্পোনেন্টের মধ্যে অন্তর্নিহিত নির্ভরতা। সমস্যাটি রয়ে গেছে, শুধু রূপ বদলেছে।

goto-এর আধুনিক রূপ

কলব্যাক হেল, গভীরভাবে নেস্টেড Promises, ত্রুটি পরিচালনা ছাড়া async/await, ইভেন্ট যা কেউ বোঝে না কে বা কখন ট্রিগার করে — এগুলি সবই স্প্যাগেটি কোডের আধুনিক বৈচিত্র্য। অ্যান্টি-প্যাটার্ন বেঁচে আছে এবং বিকশিত হচ্ছে, শুধু এখন এটি goto স্টেটমেন্ট ব্যবহার করে না।

প্রকল্পে স্প্যাগেটি কোডের লক্ষণ

স্তরের অভাব — প্রথম এবং প্রধান লক্ষণ। স্প্যাগেটি কোডে, বিজনেস লজিক, ডেটাবেস অপারেশন, HTML মার্কআপ এবং নেটওয়ার্ক যোগাযোগ সব এক ফাইল বা এমনকি এক পদ্ধতিতে মিশে থাকে। একটি ডেটাবেস কোয়েরি পরিবর্তন UI ডিসপ্লে ভেঙে দিতে পারে কারণ এই স্তরগুলির কোড পৃথক নয়।

গ্লোবাল ভেরিয়েবল এবং সিঙ্গেলটন — দ্বিতীয় স্পষ্ট লক্ষণ। যখন অ্যাপ্লিকেশন স্টেট গ্লোবাল অবজেক্টে সংরক্ষিত হয়, এক্সিকিউশন প্রবাহ অপ্রত্যাশিত হয়ে ওঠে। যেকোনো ফাংশন গ্লোবাল স্টেট পরিবর্তন করতে পারে, এবং কোথায় এবং কখন এটি ঘটেছে তা ট্র্যাক করা কার্যত অসম্ভব।

গড ক্লাস এবং গড ফাংশন — তৃতীয় লক্ষণ। 2000+ লাইনের একটি ক্লাস যা বিজনেস লজিক, ডিসপ্লে এবং ডেটা অপারেশন পরিচালনা করে — এটি সাধারণ স্প্যাগেটি কোড। একটি ফাংশন যা 10 প্যারামিটার নেয় এবং 5 ভিন্ন কাজ করে — স্প্যাগেটি।

পরীক্ষার মাধ্যমে রোগনির্ণয়

যদি আপনি ১৫টি মক অবজেক্ট তৈরি না করে একটি ফাংশনের জন্য ইউনিট টেস্ট লিখতে না পারেন — এটি স্প্যাগেটি কোড। যদি একটি মডিউল পরীক্ষার জন্য পুরো অ্যাপ্লিকেশন ইনফ্রাস্ট্রাকচার চালু করার প্রয়োজন হয় — এটি স্প্যাগেটি কোড। অপরীক্ষণীয়তা জটিল আর্কিটেকচারের একটি উদ্দেশ্যমূলক সূচক।

নুডল কোড কেন দেখা যায়

আর্কিটেকচারাল ডিজাইনের অভাব — সবচেয়ে সাধারণ কারণ। যখন একটি দল পরিকল্পনা ছাড়া কোড লেখা শুরু করে, “যেতে যেতে” আর্কিটেকচার বেছে নেয়, ফলাফল অনিবার্যভাবে স্প্যাগেটিতে পরিণত হয়। প্রতিটি নতুন বৈশিষ্ট্য সেখানে যোগ করা হয় যেখানে “এখন সুবিধাজনক,” যেখানে এটি লজিক্যালি অন্তর্ভুক্ত সেখানে নয়।

ক্রমিক উন্নয়ন — দ্বিতীয় কারণ। একটি প্রকল্প একটি ছোট স্ক্রিপ্ট হিসাবে শুরু হয়, তারপর বৈশিষ্ট্য সহ বড় হয়, তারপর একটি অ্যাপ্লিকেশন এবং তারপর একটি মনোলিথ হয়ে ওঠে। এদিকে, আর্কিটেকচার পুনর্বিবেচনা করা হয় না। যা কোডের 100 লাইনের জন্য কাজ করত, তা 100,000 লাইনের জন্য বিপর্যয় হয়ে ওঠে।

SOLID নীতিমালা লঙ্ঘন — তৃতীয় কারণ। বিশেষ করে একক দায়িত্ব নীতি (S) এবং নির্ভরতা বিপরীত নীতি (D)। যখন একটি ক্লাস সবকিছুর জন্য দায়ী, নির্ভরতা কঠোর হয় এবং মডিউলগুলি শক্তভাবে সংযুক্ত থাকে — আপনি স্প্যাগেটি কোড পান।

সময়ের কারণ

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

স্প্যাগেটি কোডের পরিণতি

প্রধান পরিণতি — কোডবেসের উপর নিয়ন্ত্রণ হারানো। ডেভেলপাররা বুঝতে পারে না যে অ্যাপ্লিকেশনটি সামগ্রিকভাবে কীভাবে কাজ করে। এক জায়গায় পরিবর্তন অন্যটি ভেঙে দেয় যা আপাতদৃষ্টিতে সম্পর্কহীন। প্রতিটি প্যাচ দুটি নতুন বাগ তৈরি করে। টিম “পরিবর্তনের ভয়” অবস্থায় প্রবেশ করে।

টিমের উত্পাদনশীলতা দ্রুত হ্রাস পায়। Microsoft Research (2023) দেখিয়েছে যে স্প্যাগেটি কোডে নতুন বৈশিষ্ট্য যুক্ত করার সময় কোডবেস আকারের তুলনায় দ্বিগুণভাবে বৃদ্ধি পায়। পরিষ্কার আর্কিটেকচারের জন্য, এই বৃদ্ধি রৈখিক। পার্থক্যটি 50,000+ লাইন কোডে গুরুত্বপূর্ণ হয়ে ওঠে।

নিরাপত্তা — আরেকটি শিকার। স্প্যাগেটি কোডে, অপরিচালিত ব্যতিক্রম, ভুল ইনপুট ভ্যালিডেশন বা ডেটা ফাঁস মিস করা সহজ। জটিল আর্কিটেকচার সহ প্রকল্পে নিরাপত্তা অডিট কার্যত অসম্ভব — ব্যবহারকারী ইনপুট ব্যবহার করা সমস্ত জায়গা খুঁজে পাওয়া অকার্যকর।

টিমের উপর প্রভাব

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

কীভাবে স্প্যাগেটি কোড রিফ্যাক্টর করবেন

প্রথম — স্তর পৃথক করে শুরু করুন। কোডকে তিনটি স্তরে ভাগ করুন: উপস্থাপনা (UI, কন্ট্রোলার), বিজনেস লজিক (সেবা, ব্যবহারের ক্ষেত্রে) এবং ডেটা অ্যাক্সেস (রিপজিটরি, DAO)। এমনকি আংশিক পৃথকীকরণ অবিলম্বে কাঠামো উন্নত করে এবং কোডকে পরীক্ষণীয় করে তোলে।

দ্বিতীয় — ডিপেন্ডেন্সি ইনজেকশন বাস্তবায়ন করুন। কনস্ট্রাক্টর বা প্যারামিটারের মাধ্যমে নির্ভরতা পাস করে সরাসরি নির্ভরতা তৈরি প্রতিস্থাপন করুন। এটি কম্পোনেন্টের মধ্যে কঠোর সংযোগ ভেঙে দেয় এবং প্রতিটি মডিউলকে পৃথকভাবে পরীক্ষা করতে দেয়।

তৃতীয় — গড ক্লাস এবং গড ফাংশন আলাদা করুন। এগুলিকে একক দায়িত্ব সহ ছোট ক্লাস এবং পদ্ধতিতে ভাঙ্গুন। জটিল উপ-সিস্টেম সরল করতে Facade প্যাটার্ন ব্যবহার করুন। মনে রাখবেন: 20 লাইনের ক্লাস 2000 লাইনের ক্লাসের চেয়ে স্পষ্ট।

// স্প্যাগেটি — সবকিছু এক পদ্ধতিতে
function handleRequest(req, res) {
  const db = new Database("mysql://...");
  const user = db.query("SELECT * FROM users WHERE id =" + req.params.id);
  let html = "";
  html += "
" + user.name + "
";
  html += "
Balance: " + user.balance + "
";
  html += "";
  res.send(html);
}

// পরিষ্কার আর্কিটেকচার — আলাদা স্তর
class UserController {
  constructor(userService) {
    this.userService = userService;
  }

  async getUser(req, res) {
    const user = await this.userService.findById(req.params.id);
    res.json(new UserResponse(user));
  }
}

class UserService {
  constructor(userRepository) {
    this.userRepository = userRepository;
  }

  async findById(id) {
    return await this.userRepository.findById(id);
  }
}

রিফ্যাক্টরিং কৌশল: সার্জিক্যাল পদ্ধতি

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

নুডল কোড প্রতিরোধ

আর্কিটেকচারাল পরিকল্পনা — প্রতিরোধের ভিত্তি। উন্নয়ন শুরু করার আগে, একটি আর্কিটেকচারাল শৈলী অনুমোদন করুন: MVC, MVVM, Clean Architecture, VIPER বা অন্য কোন। পছন্দকে ন্যায্যতা দিয়ে একটি ADR (Architecture Decision Record) লিখুন। কোড রিভিউতে আর্কিটেকচার মেনে চলার দাবি করুন।

নির্ভরতা বিপরীত নীতি (DIP) — স্প্যাগেটি কোডের বিরুদ্ধে একটি শক্তিশালী হাতিয়ার। উচ্চ-স্তরের মডিউলগুলি নিম্ন-স্তরের মডিউলের উপর নির্ভর করবে না। উভয়ই অ্যাবস্ট্রাকশনের উপর নির্ভর করবে। ডিপেন্ডেন্সি ইনজেকশন এই নীতির ব্যবহারিক বাস্তবায়ন।

পরীক্ষা — সর্বোত্তম প্রতিরোধ। যদি আপনি কোডের আগে পরীক্ষা লেখেন (TDD), আপনি অনিবার্যভাবে শিথিলভাবে যুক্ত কম্পোনেন্ট ডিজাইন করেন। পরীক্ষণীয় কোড সুগঠিত কোড। অপরীক্ষণীয় কোড প্রায় সবসময় স্প্যাগেটি কোড।

• আর্কিটেকচার কোডের আগে: স্তর এবং নির্ভরতা স্কিম অনুমোদন করুন
• ডিপেন্ডেন্সি ইনজেকশন প্রধান বন্ধন প্যাটার্ন হিসাবে
• TDD বা অন্তত উচ্চ পরীক্ষা কভারেজ
• কোড রিভিউ আর্কিটেকচার পরীক্ষা সহ, শুধু শৈলী নয়
• নিয়মিত রিফ্যাক্টরিং উন্নয়ন প্রক্রিয়ার অংশ হিসাবে

স্প্যাগেটি কোড মোকাবেলার সরঞ্জাম

SonarQube — চক্রীয় জটিলতা, উত্তরাধিকার গভীরতা, পদ্ধতি আকার ট্র্যাক করে। JDepend (Java) — প্যাকেজের মধ্যে নির্ভরতা পরিমাপ করে। PhpMetrics — PHP প্রকল্পগুলির জন্য রক্ষণাবেক্ষণযোগ্যতা সূচক প্রদান করে। CI/CD-তে মেট্রিক্স পর্যবেক্ষণ করুন — নুডলস দেখা দেওয়ার আগে প্রতিরোধ করুন, পরে লড়াই না করে।