প্রোগ্রামিংয়ে ক্রাচ — এগুলো কী, কারণ এবং কখন ন্যায্য

প্রোগ্রামিংয়ে “ক্রাচ” কী

ক্রাচ (crutch) একটি সফটওয়্যার সমাধান যা কাজ করে কিন্তু “তাড়াহুড়ো করে” তৈরি: এটি একটি নির্দিষ্ট সমস্যার সমাধান করে কিন্তু তার কারণ দূর করে না, প্রকল্পের আর্কিটেকচার অনুসরণ করে না, এবং পরিবেশে সামান্য পরিবর্তনেই ভেঙে যেতে পারে। উপমাটি যথার্থ — বাস্তব ক্রাচের মতো, এই কোড “হাঁটতে” সাহায্য করে কিন্তু “পা” সারায় না।

ডেভেলপাররা “ক্রাচ দিয়ে ঠেকায়” বাগ, সংস্করণের অসামঞ্জস্য, প্ল্যাটফর্মের বিশেষত্ব এবং জরুরি ক্লায়েন্টের প্রয়োজনীয়তা। একটি সাধারণ ক্রাচ হল শর্তসাপেক্ষ ক্রাচ: যদি iOS 15 হয় তাহলে প্যাডিং যোগ করো, যদি Huawei হয় তাহলে বাটন লুকাও। এই ধরনের চেক বহুগুণে বেড়ে যায় এবং কোডকে প্ল্যাটফর্ম এবং সংস্করণ শাখার “লেয়ার কেক”-এ পরিণত করে।

ক্রাচ বিভিন্ন মাপের হতে পারে: একটি ক্রাচ শর্তযুক্ত এক লাইন থেকে শুরু করে পুরো র্যাপার মডিউল পর্যন্ত যা লাইব্রেরির আচরণ “ঠিক” করে। এটা বোঝা গুরুত্বপূর্ণ যে ক্রাচ সবসময় মন্দ নয়: সঠিক হাতে, এটি একটি হাতিয়ার যা পণ্যটি সময়মতো প্রকাশ করতে দেয়। সমস্যা শুরু হয় যখন ক্রাচ চিরকাল কোডে থেকে যায়।

ক্রাচ কেন দেখা যায়: কারণ এবং প্রসঙ্গ

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

আসুন চারটি প্রধান কারণ দেখি কেন ডেভেলপাররা সচেতনভাবে ক্রাচের আশ্রয় নেয়। এই কারণগুলি বোঝা ক্রাচকে ভুল হিসেবে নয় বরং একটি ব্যবহারিক হাতিয়ার হিসেবে দেখতে সাহায্য করে যা পরিচালনার প্রয়োজন।

ডেডলাইন

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

সংস্করণের অসামঞ্জস্য

লাইব্রেরি A-র Android 12 প্রয়োজন, কিন্তু আপনার অ্যাপ Android 10 সমর্থন করে। সমাধান হল একটি র্যাপার লেখা যা OS সংস্করণ পরীক্ষা করে এবং নির্বাহের পথ নির্বাচন করে। এটি একটি ক্রাচ কারণ লাইব্রেরি আপডেট করলে র্যাপার পুনরায় লিখতে হবে। কিন্তু বিকল্প — লাইব্রেরি বা পুরনো ডিভাইসের সমর্থন ত্যাগ করা — আরও খারাপ হতে পারে।

// API 29 সামঞ্জস্যের জন্য ক্রাচ
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

বাগ সহ তৃতীয়-পক্ষের নির্ভরতা

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

সিস্টেমের অসম্পূর্ণ বোঝাপড়া

একটি লিগ্যাসি প্রকল্পে নতুন ডেভেলপার বুঝতে পারে না কেন কোড এইভাবে কাজ করে। বোঝার পরিবর্তে, তারা বিদ্যমান শর্তের উপরে একটি নতুন শর্ত যোগ করে। এটি সবচেয়ে বিপজ্জনক ধরনের ক্রাচ কারণ লেখক বুঝতে পারেন না যে এটি একটি ক্রাচ। একমাত্র প্রতিকার হল কোড রিভিউ এবং দলের নতুন সদস্যদের জন্য পেয়ার প্রোগ্রামিং।

ক্রাচ কখন ন্যায্য: ব্যবহারিক পদ্ধতি

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

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

একটি ন্যায্য ক্রাচের উদাহরণ

রিলিজ শাখায় একটি সমালোচনামূলক বাগ যা আগামীকালের ডিপ্লয়মেন্টের আগে ঠিক করতে হবে। পরিচ্ছন্ন সমাধানের জন্য আর্কিটেকচার রিফ্যাক্টরিং প্রয়োজন এবং দুই সপ্তাহ লাগবে। ক্রাচ: nil চেক যোগ করুন এবং ফিক্সটি hotfix হিসেবে পাঠান। ন্যায্যতার শর্ত: ট্র্যাকারে একটি রিফ্যাক্টরিং টিকিট তৈরি করা হয়েছে, একজন মালিক নিযুক্ত করা হয়েছে, এবং ক্রাচটি একটি মন্তব্য দিয়ে চিহ্নিত করা হয়েছে। দুই সপ্তাহ পরে, দল কাজে ফিরে আসে।

// TODO: IT-1234 — AuthService রিফ্যাক্টরিংয়ের পর এই ক্রাচ সরান
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

কীভাবে অস্থায়ী ক্রাচকে আর্কিটেকচার সমস্যা থেকে আলাদা করা যায়

সচেতন ক্রাচ এবং আর্কিটেকচার সমস্যা (টেকনিক্যাল ডেট) এর মধ্যে সীমানা দুটি প্যারামিটারের মধ্য দিয়ে যায়: সিদ্ধান্ত সম্পর্কে সচেতনতা এবং এটি দূর করার পরিকল্পনার অস্তিত্ব। ক্রাচ সর্বদা একটি পরিচিত জীবনকাল সহ অস্থায়ী সমাধান। টেকনিক্যাল ডেট হল অনেকগুলি অবহেলিত ক্রাচের পরিণতি।

ক্রাচ কখন সমস্যা হয়ে ওঠে

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

ক্রাচ সংকটের লক্ষণ

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

• একই ক্রাচ তিন বা ততোধিক জায়গায় পুনরাবৃত্ত হয় — একটি ঐক্যবদ্ধ সমাধান তৈরি করার সময়
• একটি ক্রাচ অপসারণ পরিকল্পনা ছাড়া তিন স্প্রিন্টের বেশি বেঁচে থাকে — এটি ইতিমধ্যেই টেকনিক্যাল ডেট
• নতুন ডেভেলপার বুঝতে পারে না কেন কোড এইভাবে কাজ করে — ক্রাচ নথিভুক্ত নয়
• ক্রাচ অপসারণ ত্রুটির শৃঙ্খল প্রতিক্রিয়া সৃষ্টি করে — ক্রাচের উপর নির্ভরতা আর্কিটেকচারাল হয়ে গেছে

ক্রাচ রিফ্যাক্টরিং: কৌশল এবং অনুশীলন

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

অগ্রাধিকার কৌশল

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

ধাপে ধাপে অপসারণ প্রক্রিয়া

ধাপ 1: তালিকা — ক্রাচ সম্পর্কিত সব TODO এবং FIXME খুঁজুন। ধাপ 2: মূল্যায়ন — নির্ধারণ করুন কোনগুলি এখনও প্রাসঙ্গিক। ধাপ 3: পরিকল্পনা — উচ্চ অগ্রাধিকার থেকে শুরু করে স্প্রিন্টে ক্রাচ রিফ্যাক্টরিং নির্ধারণ করুন। ধাপ 4: প্রতিস্থাপন — পরিচ্ছন্ন সমাধান বাস্তবায়ন করুন, ক্রাচ এবং এর TODO মন্তব্য সরান। ধাপ 5: যাচাই — নিশ্চিত করুন যে পরীক্ষাগুলি পাস করে এবং কোনো রিগ্রেশন নেই।

# প্রকল্পে সব TODO-ক্রাচ খুঁজুন
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

নতুন ক্রাচ প্রতিরোধ

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