کدهای قدیمی با گذشت زمان بدتر می‌شوند

کدهای قدیمی (Legacy Code) مثل شراب با گذشت زمان بهتر نمی‌شوند؛ بلکه هر روزی که نادیده‌شان بگیرید، بدتر می‌شوند.

هفته گذشته، سه ساعت وقت صرف عیب‌یابی مشکلی کردم که باید ۲۰ دقیقه طول می‌کشید. مقصر، یک ماژول اعتبارسنجی (validation module) متعلق به سال ۲۰۱۹ بود. بقیه به آن دست نمی‌زدند چون کار می‌کرد. اما کار نمی‌کرد. من یک کامنت با متن "TODO: refactor this" مربوط به سال ۲۰۲۰ پیدا کردم.

بسیاری با کدهای قدیمی مثل یک بدهی اختیاری برخورد می‌کنند. آن‌ها فکر می‌کنند هر زمان که وقت داشتند، آن را تسویه خواهند کرد. کدهای قدیمی مثل کپک عمل می‌کنند؛ پخش می‌شوند و هر چیزی را که در اطرافشان هست آلوده می‌کنند. هر چه بیشتر صبر کنید، پاکسازی آن‌ها پرهزینه‌تر می‌شود.

این چرخه قابل پیش‌بینی است:

  • یک قابلیت (feature) به‌هم‌ریخته اما کارآمد را به ارث می‌برید.
  • برای اینکه کار کند، یک دستور if دیگر به آن اضافه می‌کنید.
  • شش ماه بعد، شخص دیگری همین کار را انجام می‌دهد.
  • یک سال بعد، آن فایل ۸۰۰ خط کد دارد و هیچ تستی ندارد.

این هزینه پنهان به سه روش به شما ضربه می‌زند:

  • سرعت کاهش می‌یابد. شما زمان بیشتری را صرف درک زمینه (context) می‌کنید تا نوشتن کد.
  • باگ‌ها زیاد می‌شوند. یک اصلاح باعث از کار افتادن چیز دیگری می‌شود، چون منطق کد در هم تنیده است.
  • فرآیند Onboarding با شکست مواجه می‌شود. توسعه‌دهندگان جدید برای درک اینکه چرا یک منطق مشابه در هفت جای مختلف وجود دارد، دچار مشکل می‌شوند.

مراقب این نشانه‌های خطر باشید:

  • کامنت‌های بی‌فایده مثل "HACK: do not touch this."
  • تکرار منطق تجاری (business logic) در فایل‌های مختلف.
  • وابستگی‌های چرخه‌ای (circular dependencies) که در آن سرویس‌ها به یکدیگر وابسته هستند.

همه چیز را از نو بازنویسی نکنید. بازنویسی‌های کامل در ۸۰٪ مواقع شکست می‌خورند. در عوض، از بازسازی تدریجی (incremental refactoring) همراه با تست‌های مشخصه‌سازی (characterization tests) استفاده کنید.

این فرآیند را دنبال کنید:

  • رفتار فعلی را با تست‌ها ثبت کنید، حتی بخش‌های عجیب و غریب آن را.
  • کد را بدون تغییر در آن رفتار، بازسازی (refactor) کنید.
  • این کار را تا زمانی که کد خوانا شود، تکرار کنید.
  • رفتار کد را تنها زمانی تغییر دهید که تست‌های واقعی داشته باشید.

قوانینی که باید رعایت کنید:

  • هرگز بدون تست، بازسازی (refactor) نکنید.
  • از بهبودهایی که رفتار کد را تغییر می‌دهند خودداری کنید. یک باگ ممکن است در واقع ویژگی‌ای باشد که مشتری به آن وابسته است.
  • به کدهای آرام (quiet code) دست نزنید. اگر ماژولی در سه سال گذشته تغییری نکرده و مشکلی ایجاد نمی‌کند، به آن دست نزنید.

انرژی خود را روی کدهایی متمرکز کنید که اغلب با آن‌ها کار می‌کنید.

Source: https://dev.to/taina_costa_f/legacy-code-nao-envelhece-como-vinho-quanto-mais-espera-pior-fica-132h