بدهی فنی: کِی بپذیریم و کِی بپردازیم
بدهی فنی همیشه بد نیست. بد آن است که ندانیم چقدر بدهکاریم و بهرهاش را کجا میپردازیم.
نویسنده
تیم بایتیرا
تاریخ انتشار
۱۸ شهریور ۱۴۰۵
زمان مطالعه
1 دقیقه
خلاصه
بدهی فنی همیشه بد نیست. بد آن است که ندانیم چقدر بدهکاریم و بهرهاش را کجا میپردازیم.
استعاره بدهی دقیق است: قرض گرفتن سرعت امروز، به قیمت پرداخت بهره فردا. مثل بدهی مالی، گاهی تصمیم درستی است.
بدهی عمدی و منطقی
راهاندازی نسخه اول با سادهترین پیادهسازی ممکن، برای اینکه بفهمید اصلاً کسی از آن استفاده میکند یا نه، عاقلانه است. ساختن معماری بینقص برای محصولی که هنوز تأیید نشده، اسراف است.
شرط این است که تصمیم آگاهانه باشد و ثبت شود.
بدهی تصادفی و خطرناک
بدهیای که کسی انتخابش نکرده: کدی که چون عجله بود کپی شد، تستی که نوشته نشد، تصمیمی که هیچجا مستند نشد. این نوع بهره مرکب دارد.
نشانههای اینکه بهره سنگین شده
تخمینها مدام اشتباه از آب درمیآیند. تغییر کوچک در یک بخش، بخش دیگری را میشکند. توسعهدهنده جدید هفتهها طول میکشد تا مفید شود. همه از دست زدن به بخش خاصی از کد میترسند.
چطور بپردازیم
بازنویسی کامل تقریباً همیشه اشتباه است؛ بدهی جدید میسازد و ارزشی تحویل نمیدهد. بهتر است هر بار که به بخشی از کد دست میزنید، کمی بهترش کنید — و برای مواردی که سرعت تیم را واقعاً کند کردهاند، کار مشخص تعریف کنید.
گفتوگو با کسبوکار
«باید ریفکتور کنیم» جمله بیاثری است. «این بخش باعث میشود هر تغییری سه برابر طول بکشد؛ دو روز کار روی آن، سرعت ما را برمیگرداند» جملهای است که تصمیمگیر میفهمد.
مطالب مرتبط
سرعت سایت: چه چیزی را واقعاً باید بهینه کرد
بیشتر تلاشهای بهینهسازی صرف چیزهایی میشود که کاربر حس نمیکند. سه چیز است که حس میشود.
خواندنAPI خوب چه ویژگیهایی دارد
API خوب آن است که مصرفکننده بتواند بدون خواندن کد سرور، رفتارش را حدس بزند.
خواندنچرا استقرار با داکر دردسر کمتری دارد
«روی سیستم من کار میکرد» یک شوخی نیست؛ نشانه این است که محیط اجرا بخشی از پروژه نیست.
خواندن