প্রোগ্রামিংয়ে সাইকেল: এটি কী, কারণ এবং কীভাবে এড়ানো যায়

প্রোগ্রামিংয়ে সাইকেল কী

সাইকেল ডেভেলপার সম্প্রদায়ের একটি শব্দ যা ইতিমধ্যে লাইব্রেরি, ফ্রেমওয়ার্ক বা পরিষেবা হিসাবে উপলব্ধ কার্যকারিতার নিজস্ব বাস্তবায়ন তৈরি করাকে বোঝায়। ইংরেজি ভাষাভাষী পরিবেশে অভিব্যক্তি reinventing the wheel — চাকা পুনরায় উদ্ভাবন — ব্যবহৃত হয়।

রূপকের উৎপত্তি এই সত্যের সাথে সম্পর্কিত যে চাকা মানবজাতির প্রাচীনতম আবিষ্কারগুলির মধ্যে একটি। 21শ শতাব্দীতে এটি পুনরায় তৈরি করার চেষ্টা করা অর্থহীন। প্রোগ্রামিংয়ে, সাদৃশ্য আরও নির্ভul: প্রস্তুত লাইব্রেরি হল “চাকা” যা হাজার হাজার ইঞ্জিনিয়ার বছরের পর বছর ধরে অপটিমাইজ করেছে। নিজের নিম্নমানের চাকা তৈরি করা সম্পদের অপচয়।

RedMonk একটি বিশ্লেষণাত্মক প্রতিবেদনে (2023) গণনা করেছে যে গড় বাণিজ্যিক অ্যাপ্লিকেশন প্রায় 500 বাহ্যিক নির্ভরতা ব্যবহার করে। যদি ডেভেলপারদের প্রতিটি স্বাধীনভাবে লিখতে হত, প্রকল্পের খরচ দশগুণ বেড়ে যেত এবং বাজারে আসার সময় বছর পেরিয়ে যেত। প্যাকেজ ম্যানেজার ইকোসিস্টেম (npm, Maven, PyPI, NuGet) চাকা পুনরায় উদ্ভাবন এড়ানোর জন্যই বিদ্যমান।

সাইকেলের লক্ষণ

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

সাইকেল এবং কাস্টম সমাধানের মধ্যে পার্থক্য

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

কেন ডেভেলপাররা সাইকেল তৈরি করে

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

দ্বিতীয় কারণ নিয়ন্ত্রণের বিভ্রম। অভিজ্ঞ ডেভেলপাররা কখনও কখনও নিশ্চিত হন যে তারা “জনপ্রিয় লাইব্রেরির লেখকদের চেয়ে ভাল লিখতে পারেন।” পরিসংখ্যান বিপরীত বলে: লক্ষ লক্ষ প্রকল্প দ্বারা ব্যবহৃত লাইব্রেরিতে ত্রুটির সম্ভাবনা সদ্য লেখা কোডের তুলনায় উল্লেখযোগ্যভাবে কম। Synopsys (2024) অনুসারে, ওপেন সোর্স কোডে প্রতি হাজার লাইনে গড়ে 0.1 ত্রুটি থাকে, যখন কর্পোরেট কোডে 1–2 থাকে।

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

মনস্তাত্ত্বিক দিক

IKEA প্রভাব একটি মনস্তাত্ত্বিক ঘটনা যেখানে একজন ব্যক্তি নিজের তৈরি জিনিসকে বস্তুনিষ্ঠভাবে ভালো প্রস্তুত জিনিসের চেয়ে বেশি মূল্য দেয়। প্রোগ্রামিংয়ে, এটি “নিজের সাইকেল” নিয়ে গর্ব এবং স্পষ্ট সুবিধা থাকা সত্ত্বেও এটিকে প্রস্তুত লাইব্রেরি দিয়ে প্রতিস্থাপন করতে অনিচ্ছা হিসাবে প্রকাশ পায়।

প্রজেক্টে সাইকেল তৈরির পরিণতি

অর্থনৈতিক পরিণতি সবচেয়ে স্পষ্ট। Stripe (2022) এর অনুমান অনুসারে, ডেভেলপাররা তাদের কাজের সময়ের 35% পর্যন্ত ইতিমধ্যে প্রস্তুত সমাধান হিসাবে বিদ্যমান কোড তৈরি করতে ব্যয় করে। 10 জনের একটি টিমের জন্য, এটি চাকা পুনরায় উদ্ভাবনে ব্যয়িত প্রায় $200,000 বার্ষিক সমতুল্য।

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

Google তার গবেষণা “Why Google Stores Billions of Lines of Code” (2023) এ উল্লেখ করেছে যে এমনকি বৃহত্তম প্রযুক্তি কোম্পানিতেও নতুন নির্ভরতা যুক্ত করার বা নিজস্ব বাস্তবায়ন লেখার জন্য একটি কঠোর সিদ্ধান্ত গ্রহণ প্রক্রিয়া রয়েছে। বেশিরভাগ অভ্যন্তরীণ টিম প্রথমে একক কোড রিপোজিটরিতে প্রস্তুত সমাধান খোঁজে।

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

সাইকেল তথ্য অ্যাসিনক্রোনিসিটি তৈরি করে: যখন একজন ডেভেলপার চলে যায়, তার স্ব-নির্মিত উপাদান ডকুমেন্টেশন এবং সমর্থন ছাড়াই থাকে। টিমের নতুন সদস্যদের অ-মানক কোড বুঝতে হয়, সময় নষ্ট করে যা উৎপাদনশীল কাজে ব্যবহার করা যেত।

কোডে সাধারণ সাইকেলের উদাহরণ

সবচেয়ে সাধারণ উদাহরণ ম্যানুয়াল JSON বা XML পার্সিং, যদিও প্রায় সব আধুনিক ভাষায় বিল্ট-ইন টুল রয়েছে। ডেভেলপাররা অবজেক্ট ট্রি ট্রাভার্স করার জন্য রিকার্সিভ ফাংশন লেখে, না জেনে যে JSON.parse() একটি লাইনে সমস্যার সমাধান করে।

দ্বিতীয় উদাহরণ HTTP ক্লায়েন্টের নিজস্ব বাস্তবায়ন। স্ট্যান্ডার্ড লাইব্রেরি (fetch, axios, OkHttp, URLSession) ক্যাশিং, পুনঃসংযোগ, টাইমআউট এবং নিরাপত্তা সমর্থন করে। স্ব-নির্মিত ক্লায়েন্ট সাধারণত এই প্রয়োজনীয়তাগুলির মধ্যে কমপক্ষে একটি পূরণ করে না, যা উৎপাদনে বাগের দিকে নিয়ে যায়।

তৃতীয় উদাহরণ SLF4J, Winston বা Log4j ব্যবহার করার পরিবর্তে স্ব-নির্মিত লগিং সিস্টেম। একজন ডেভেলপার সপ্তাহ কাটায় যা প্রস্তুত লাইব্রেরি রোটেশন, লগ লেভেল, অ্যাসিঙ্ক রাইটিং এবং মনিটরিং সিস্টেম ইন্টিগ্রেশনের সমর্থন সহ বক্সের বাইরে করে।

# সাইকেল — ম্যানুয়াল CSV পার্সিং
def parse_csv(line):
    result = []
    current = ""
    for ch in line:
        if ch == ",":
            result.append(current)
            current = ""
        else:
            current += ch
    return result

# পরিবর্তে স্ট্যান্ডার্ড লাইব্রেরি ব্যবহার করা
import csv
with open("data.csv") as f:
    reader = csv.reader(f)

অ্যান্টি-প্যাটার্ন: কাস্টম ORM

নিজস্ব ORM (Object-Relational Mapping) লেখা সম্ভবত সবচেয়ে ব্যয়বহুল সাইকেল। Hibernate, Entity Framework বা SQLAlchemy এর মতো প্রস্তুত ORM বছরের পর বছর ধরে তৈরি করা হয়েছে, ক্যাশিং, লেজি লোডিং, মাইগ্রেশন এবং ডজন ডজন DBMS সমর্থন করে। কাস্টম ORM সাধারণত একটি ডাটাবেসে সীমাবদ্ধ এবং সংযোগ ব্যবস্থাপনায় গুরুতর ত্রুটি থাকে।

কখন সাইকেল ন্যায্য

শেখা একমাত্র পরিস্থিতি যেখানে সাইকেল কেবল ন্যায্য নয় বরং দরকারীও। শিক্ষাগত উদ্দেশ্যে নিজস্ব পার্সার, HTTP সার্ভার বা ORM লেখা বুঝতে সাহায্য করে যে এই টুলগুলি ভিতরে কীভাবে কাজ করে। শেখার প্রকল্প এবং উৎপাদন কোডের মধ্যে বিভ্রান্ত না হওয়া গুরুত্বপূর্ণ: যা পেট-প্রজেক্টের জন্য ভাল তা বাণিজ্যিক উন্নয়নে অগ্রহণযোগ্য।

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

লাইসেন্সিং সীমাবদ্ধতা আরেকটি বৈধ কারণ। কিছু ওপেন সোর্স লাইসেন্স (GPL, AGPL) কোম্পানির ব্যবসায়িক মডেলের সাথে অসঙ্গত হতে পারে। এই ধরনের ক্ষেত্রে, আরও অনুমতিমূলক লাইসেন্সের অধীনে নিজস্ব বাস্তবায়ন বিকাশ করা ন্যায্য।

তিনটি চেষ্টার নিয়ম

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

কীভাবে সাইকেল তৈরি এড়ানো যায়

প্রথম ধাপ যেকোনো মানক কাজ শুরু করার আগে প্রস্তুত সমাধান খোঁজার অভ্যাস তৈরি করা। প্যাকেজ ম্যানেজার, GitHub, Stack Overflow এ অনুসন্ধান ব্যবহার করুন। গবেষণায় ব্যয় করা সময় স্ব-নির্মিত কোড লেখা এড়িয়ে বহুগুণে ফিরে আসে।

দ্বিতীয় ধাপ সাইকেল সনাক্তকরণের উপর ফোকাস করে কোড রিভিউ বাস্তবায়ন করা। রিভিউতে, প্রশ্ন জিজ্ঞাসা করুন: “কেন আমরা এই কাজের জন্য প্রস্তুত লাইব্রেরি ব্যবহার করছি না?” যদি উত্তরে বস্তুনিষ্ঠ কারণ না থাকে — তবে এটি সাইকেল। বড় কোম্পানিতে (Google, Meta), কোড রিভিউতে চাকা পুনরায় উদ্ভাবন পরীক্ষা করার জন্য বাধ্যতামূলক পয়েন্ট অন্তর্ভুক্ত থাকে।

তৃতীয় ধাপ অভ্যন্তরীণ জ্ঞান রেজিস্ট্রি তৈরি করা। ডকুমেন্ট করুন প্রকল্পে কোন লাইব্রেরি এবং টুল ব্যবহার করা হয় এবং তারা কী কাজ সমাধান করে। নতুন ডেভেলপারদের এই তথ্যে অ্যাক্সেস থাকা উচিত যাতে তারা অজ্ঞতা থেকে সাইকেল না তৈরি করে। প্রতিটি পছন্দের যুক্তি সহ আর্কিটেকচার ডিসিশন রেকর্ড (ADR) এর তালিকা রাখুন।

• গবেষণা করুন প্যাকেজ ম্যানেজারে নতুন কাজ শুরু করার আগে
• পরীক্ষা করুন ভাষার স্ট্যান্ডার্ড লাইব্রেরি — এটি 80% সাধারণ কাজ কভার করে
• ব্যবহার করুন কোড রিভিউ সাইকেল সনাক্ত করতে
• ডকুমেন্ট করুন লাইব্রেরি নির্বাচনের সিদ্ধান্ত
• আপডেট করুন ইকোসিস্টেমের জ্ঞান কনফারেন্স এবং ব্লগে

নট ইনভেন্টেড হিয়ার সিনড্রোম

NIH সিনড্রোম (Not Invented Here) বাহ্যিক সমাধান ব্যবহারের বিরুদ্ধে একটি সাংগঠনিক পক্ষপাত। NIH সিনড্রোমযুক্ত কোম্পানিগুলি সবকিছু অভ্যন্তরীণভাবে বিকাশ করতে পছন্দ করে, ওপেন সোর্স লাইব্রেরি প্রত্যাখ্যান করে, এমনকি যখন সেগুলি নিজস্ব উন্নয়নের চেয়ে উন্নত। এই সিনড্রোম হল সাইকেলের কর্পোরেট সংস্করণ।

একটি ক্লাসিক উদাহরণ 1990 এর দশকের শেষে Netscape, যখন কোম্পানি বিদ্যমান কোডবেস বিকাশের পরিবর্তে ব্রাউজার স্ক্র্যাচ থেকে পুনরায় লিখতে বছর কাটিয়েছে। ফলাফল — বাজার শেয়ার হারানো এবং AOL দ্বারা অধিগ্রহণ। বিপরীতে, Android Linux কার্নেলের উপর নির্মিত এবং হাজার হাজার ওপেন সোর্স উপাদান ব্যবহার করে — এটি পণ্যটিকে রেকর্ড সময়ে বাজারে আনতে অনুমতি দিয়েছে।

Harvard Business Review (2023) এর একটি গবেষণায় দেখা গেছে যে NIH সিনড্রোমের নিম্ন স্তরের কোম্পানিগুলি পণ্য 40% দ্রুত বাজারে আনে এবং উন্নয়নে 30% কম খরচ করে। কোড পুনর্ব্যবহারের সংস্কৃতি আধুনিক উন্নয়নে একটি প্রতিযোগিতামূলক সুবিধা।

// সাইকেল — কাস্টম সাজানোর বাস্তবায়ন
function bubbleSort(arr) {
  for (let i = 0; i < arr.length; i++) {
    for (let j = 0; j < arr.length - i - 1; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }
  return arr;
}

// বিল্ট-ইন সর্ট — স্ট্যান্ডার্ড সমাধান
arr.sort((a, b) => a - b);