“কাজ করছে — ছোঁয়ো না” — এটি কী, নীতির সারাংশ এবং ঝুঁকি

“কাজ করছে — ছোঁয়ো না” নীতিটি কী?

“কাজ করছে — ছোঁয়ো না” — একটি অভিজ্ঞতামূলক নিয়ম যা ডেভেলপারদের পর্যাপ্ত কারণ ছাড়া কাজ করা কোডে পরিবর্তন করতে সতর্ক করে। নীতিটি সহজ পরিসংখ্যানের উপর ভিত্তি করে: বেশিরভাগ ত্রুটি বিদ্যমান কোড পরিবর্তনের সময়ই তৈরি হয়।

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

মাইক্রোসফট কর্পোরেশনের একটি গবেষণা (2024) অনুসারে, প্রোডাকশনে সমস্ত গুরুতর ঘটনার প্রায় 60% সাম্প্রতিক কোড পরিবর্তনের সাথে সম্পর্কিত যা ভাল উদ্দেশ্যে করা হয়েছিল কিন্তু বাস্তব লোড অবস্থায় পর্যাপ্তভাবে পরীক্ষা করা হয়নি।

নীতির ইতিহাস এবং উৎপত্তি

প্রবাদটি “যদি এটি ভাঙা না হয় তবে এটি ঠিক করবেন না” বিংশ শতাব্দীর মাঝামাঝি আমেরিকান ইঞ্জিনিয়ারিং সংস্কৃতি থেকে উদ্ভূত। প্রথম নথিভুক্ত ব্যবহার বার্ট ল্যান্স (1977) কে কৃতিত্ব দেওয়া হয়, যিনি মার্কিন সিনেট অর্থ কমিটিতে কাজ করতেন এবং অতিরিক্ত নিয়ন্ত্রণের বিরোধিতা করতেন।

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

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

কখন নীতিটি প্রয়োগ করবেন

“কাজ করছে — ছোঁয়ো না” নীতিটি বিশেষ করে সেই পরিস্থিতিতে প্রাসঙ্গিক যেখানে ত্রুটির মূল্য পরিবর্তনের সম্ভাব্য সুবিধার চেয়ে বেশি।

পরীক্ষা ছাড়া লিগ্যাসি প্রকল্প

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

গুরুত্বপূর্ণ সিস্টেম

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

কঠিন সময়সীমা

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

নীতি অনুসরণের ঝুঁকি

অন্ধভাবে নীতি “কাজ করছে — ছোঁয়ো না” অনুসরণ করা অন্তহীন রিফ্যাক্টরিংয়ের চেয়ে কম ঝুঁকিপূর্ণ নয়। আসুন প্রধান বিপদগুলি পরীক্ষা করি।

টেকনিক্যাল ঋণ জমা হওয়া

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

অপ্টিমাইজেশনের সুযোগ হাতছাড়া

কখনও কখনও একটি পরিবর্তন যা ঝুঁকিপূর্ণ মনে হয় আসলে কর্মক্ষমতা বা নিরাপত্তা উল্লেখযোগ্যভাবে উন্নত করে। “কাজ করছে — ছোঁয়ো না” নীতিটি এমন পরিবর্তনগুলিকে বাধা দেওয়া উচিত নয় যা পরিমাপযোগ্য সুবিধা নিয়ে আসে — সার্ভার খরচ কমানো, পৃষ্ঠা লোডিং দ্রুত করা, নিরাপত্তা বাড়ানো।

দক্ষতা হারানো

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

সুবর্ণ মধ্য: গোঁড়ামি ছাড়া রিফ্যাক্টরিং

সর্বোত্তম কৌশল — অন্ধভাবে নীতি অনুসরণ না করে, বরং প্রসঙ্গ বিবেচনায় নিয়ে সচেতনভাবে প্রয়োগ করা। রিফ্যাক্টরিং প্রয়োজনীয়, তবে এটি নিরাপদ হতে হবে।

বয় স্কাউটের নিয়ম

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

পরীক্ষার সুরক্ষায় রিফ্যাক্টরিং

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

// উদাহরণ: টেস্ট কভারেজের অধীনে নিরাপদ রিফ্যাক্টরিং
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // পুরনো কিন্তু কাজ করা কোড
        return basePrice - (basePrice * discount / 100.0)
    }
}

// পরীক্ষা যা রিগ্রেশন থেকে রক্ষা করে
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

এই উদাহরণটি সঠিক পদ্ধতি প্রদর্শন করে: প্রথমে পরীক্ষা, তারপর রিফ্যাক্টরিং। যদি পরীক্ষা পাস হয়, পরিবর্তন নিরাপদ। “কাজ করছে — ছোঁয়ো না” নীতিটি রূপান্তরিত হয় “পরীক্ষার অধীনে কাজ করে — সাহসের সাথে রিফ্যাক্টর করুন”-এ।

বাস্তব উদাহরণ

আসুন বাস্তব দৃশ্যকল্প দেখি যেখানে “কাজ করছে — ছোঁয়ো না” নীতিটি জীবন রক্ষাকারী এবং ধ্বংসাত্মক উভয়ই প্রমাণিত হয়েছে।

জীবন রক্ষাকারী ঘটনা: Y2K-সদৃশ সমস্যা

একজন ডেভেলপার আবিষ্কার করলেন যে তারিখ প্রক্রিয়াকরণ কোড YYYY-এর পরিবর্তে DD/MM/YY ফরম্যাট ব্যবহার করছে। কোডটি 2000 থেকে 2025 পর্যন্ত সঠিকভাবে কাজ করছিল। “ঠিক” করার ইচ্ছা থাকা সত্ত্বেও, তিনি কোডটি যেমন ছিল তেমন রেখে দিলেন, শুধুমাত্র একটি মন্তব্য যোগ করলেন। 2026 সালে, কোম্পানি সিস্টেম আপডেট করল, এবং নতুন সমাধান সঠিকভাবে শতাব্দীগুলি পরিচালনা করল। অকাল পরিবর্তন কাজ করা লজিক ভেঙে দিত।

ধ্বংসাত্মক ঘটনা: “উন্নতি”-র কারণে ডেটা ক্ষতি

একজন ইঞ্জিনিয়ার পুরনো কিন্তু কাজ করা ডেটা ইম্পোর্ট কোডকে একটি আধুনিক লাইব্রেরি দিয়ে প্রতিস্থাপন করে “উন্নত” করার সিদ্ধান্ত নিলেন। তিনি লক্ষ্য করলেন না যে পুরনো লাইব্রেরিটি একটি নির্দিষ্ট প্রান্তিক ক্ষেত্র পরিচালনা করত যা নথিভুক্ত ছিল না। রিলিজের পর — ব্যাপক ডেটা ক্ষতি। “কাজ করছে — ছোঁয়ো না” নীতিটি লঙ্ঘিত হল, এবং ত্রুটির মূল্য ছিল পুনরুদ্ধারের জন্য টিমের দুই সপ্তাহের কাজ।