«کار می‌کند — دست نزن» — چیست، ماهیت اصل و ریسک‌ها

اصل «کار می‌کند — دست نزن» چیست؟

اصل «کار می‌کند — دست نزن» (انگلیسی: «If it ain't broke, don't fix it») — یک قانون تجربی است که برنامه‌نویسان را از ایجاد تغییرات در کد در حال کار بدون دلایل کافی برحذر می‌دارد. اساس این اصل آمار ساده‌ای است: اکثریت قریب به اتفاق نقص‌ها دقیقاً در فرآیند تغییر کد موجود ایجاد می‌شوند.

این اصل یک دگما نیست — بلکه یک اکتشافی است که به تصمیم‌گیری در شرایط عدم قطعیت کمک می‌کند. هرچه پایگاه کد پیچیده‌تر و درهم‌تر باشد، احتمال اینکه یک تغییر «بی‌گناه» چیزی را خراب کند که هیچ‌کس انتظار خراب شدنش را نداشت، بیشتر است.

طبق تحقیق شرکت مایکروسافت (۲۰۲۴)، حدود ۶۰٪ از تمام حوادث بحرانی در محیط تولید با تغییرات اخیر کد مرتبط است که با نیت خوب انجام شده اما در شرایط بار واقعی به اندازه کافی آزمایش نشده‌اند.

تاریخچه و خاستگاه اصل

اصطلاح «If it ain't broke, don't fix it» به فرهنگ مهندسی آمریکایی اواسط قرن بیستم بازمی‌گردد. اولین استفاده مستند به برت لنس (۱۹۷۷) نسبت داده می‌شود که در کمیته مالی سنای ایالات متحده کار می‌کرد و با مقررات‌گذاری بیش از حد مخالف بود.

این اصل از مهندسی سخت‌افزار به برنامه‌نویسی راه یافت، جایی که تعویض یک تراشه کارکرده با تراشه جدید می‌توانست به عواقب غیرقابل پیش‌بینی منجر شود. در زمینه نرم‌افزار، این اصل با افزایش پیچیدگی سیستم‌های نرم‌افزاری و ظهور کدهای قدیمی (legacy) رواج ویژه‌ای یافت.

جالب است که در برنامه‌نویسی این اصل یک روی دیگر نیز دارد — «کار می‌کند، اما بهتر است دست نزنید» اغلب بهانه‌ای برای امتناع از بازآفرینی می‌شود که در بلندمدت به انباشت بحرانی بدهی فنی منجر می‌شود. به گفته شرکت مشاوره‌ای Thoughtworks (۲۰۲۳)، حدود ۴۰٪ پروژه‌ها به دلیل محافظه‌کاری بیش از حد در قبال تغییرات با مشکلات جدی مواجه می‌شوند.

چه زمانی اصل را اعمال کنیم

اصل «کار می‌کند — دست نزن» به ویژه در شرایط خاصی که هزینه خطا از مزایای بالقوه تغییرات فراتر می‌رود، کاربرد دارد.

پروژه‌های قدیمی بدون تست

در کد قدیمی که با تست پوشش داده نشده، هر تغییری قمار با رولت روسی است. اگر برنامه‌نویس نمی‌تواند بررسی کند که تغییر ماژول‌های مجاور را خراب نکرده، بهترین استراتژی دست نزدن به کد در حال کار است. استثنا — فقط باگ‌های بحرانی یا الزامات امنیتی.

سیستم‌های حیاتی

در سیستم‌هایی که توقف غیرقابل قبول است یا هزینه خطا بسیار زیاد است — نرم‌افزار پزشکی، اویونیک، تراکنش‌های مالی — اصل «کار می‌کند — دست نزن» یک استاندارد دوفاکتو است. هر تغییری مراحل چندگانه تأیید و آزمایش را طی می‌کند.

ضرب‌الاجل‌های سخت

اگر انتشار فرداست و کد کار می‌کند — سعی نکنید معماری آن را بهبود دهید. فقط چیزی را تغییر دهید که مستقیماً بر عملکرد انتشار تأثیر می‌گذارد. بازآفرینی را به اسپرینت بعدی موکول کنید (اما آن را فراموش نکنید).

خطرهای پیروی از اصل

پیروی کورکورانه از اصل «کار می‌کند — دست نزن» خطر کمتری از بازآفرینی بی‌پایان ندارد. بیایید خطرات اصلی را بررسی کنیم.

انباشت بدهی فنی

اگر هر برنامه‌نویسی از این اصل پیروی کند، پایگاه کد به سرعت به یک «لایه‌لایه» از راه‌حل‌های قدیمی، چاره‌های موقت و الگوریتم‌های غیربهینه تبدیل می‌شود. دیر یا زود بدهی فنی غیرقابل تحمل می‌شود — هر تغییری هفته‌ها تحلیل نیاز دارد.

بهینه‌سازی از دست رفته

گاهی تغییری که به نظر پرریسک می‌رسد در واقع عملکرد یا امنیت را به طور قابل توجهی بهبود می‌بخشد. اصل «کار می‌کند — دست نزن» نباید تغییراتی را که سود قابل اندازه‌گیری دارند — کاهش هزینه‌های سرور، تسریع بارگذاری صفحات، افزایش امنیت — مسدود کند.

از دست دادن شایستگی‌ها

وقتی تیم سال‌ها به بخش‌های خاصی از کد دست نمی‌زند، درک چگونگی عملکرد آنها را از دست می‌دهد. برنامه‌نویس کلیدی می‌رود — و کد به legacy بدون امکان پشتیبانی تبدیل می‌شود. اصل باید با در نظر گرفتن پشتیبانی بلندمدت پروژه اعمال شود.

حد وسط: بازآفرینی بدون تعصب

استراتژی بهینه — پیروی کورکورانه از اصل نیست، بلکه اعمال آگاهانه آن با در نظر گرفتن زمینه است. بازآفرینی لازم است، اما باید ایمن باشد.

قانون پیشاهنگ

قانون پیشاهنگ در برنامه‌نویسی: «کد را تمیزتر از آنچه یافتی رها کن». اگر برنامه‌نویسی در ماژولی تغییر ایجاد می‌کند، باید ساختار آن را بهبود بخشد، اما در محدوده معقول. نه اینکه همه چیز را از نو بنویسد، بلکه حداقل متغیرهای غیرقابل خواندن را تغییر نام دهد و کامنت اضافه کند.

بازآفرینی تحت حفاظت تست‌ها

تست‌ها — تنها راه ایمن برای اعمال اصل «کار می‌کند — دست نزن» هستند. اگر کد با تست پوشش داده شود، هر بازآفرینی قابل پیش‌بینی می‌شود: برنامه‌نویس کد را تغییر می‌دهد، تست‌ها را اجرا می‌کند و می‌بیند که چیزی خراب نشده است. بدون تست — دست نزن. با تست — با اطمینان بازآفرینی کن.

// مثال: بازآفرینی ایمن تحت پوشش تست
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

برنامه‌نویس کشف کرد که در کد پردازش تاریخ از فرمت DD/MM/YY به جای YYYY استفاده می‌شود. کد از سال ۲۰۰۰ تا ۲۰۲۵ به درستی کار می‌کرد. علیرغم تمایل به «رفع» — کد را به حال خود رها کرد و به یک کامنت بسنده کرد. در سال ۲۰۲۶ شرکت سیستم را به‌روز کرد و راه‌حل جدید قرن‌ها را به درستی پردازش می‌کرد. تغییر زودهنگام منطق کار را خراب می‌کرد.

مورد مخرب: از دست دادن داده به دلیل «بهبود»

مهندس تصمیم گرفت کد قدیمی اما کارآمد واردات داده را با جایگزینی آن با یک کتابخانه مدرن «بهبود» دهد. او در نظر نگرفت که کتابخانه قدیمی یک مورد مرزی خاص را پردازش می‌کرد که مستند نشده بود. پس از انتشار — از دست دادن انبوه داده. اصل «کار می‌کند — دست نزن» نقض شد و هزینه خطا دو هفته کار تیم برای بازیابی بود.