پرش به مطلب اصلی

2 پست با برچسب "تغییرپذیری"

یادداشت‌هایی درباره طراحی برای تغییر و کاهش هزینه‌ی تغییرات آینده

مشاهده تمام برچسب‌ها

وقتی هر قابلیت تازه یعنی دست زدن به کدهای قدیمی

· ۱۰ دقیقه مطالعه
مهدی مالوردی
مهندس نرم‌افزار و نویسندهٔ این سایت

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

فرض کنید در یک سامانه‌ی مالی، چند نوع تراکنش داریم: واریز، برداشت و انتقال. کد هم مدت‌هاست کار می‌کند. گزارش‌ها درست‌اند، آزمون‌ها سبزند، و کسی دوست ندارد بی‌دلیل به مسیرهای قدیمی دست بزند.

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

function calculateFee(transaction: Transaction) {
if (transaction.type === 'deposit') {
return 0
}

if (transaction.type === 'withdraw') {
return transaction.amount * 0.01
}

if (transaction.type === 'transfer') {
return 500
}

if (transaction.type === 'refund') {
return 0
}
}

در یک فایل دیگر هم همین الگو تکرار شده است:

function buildReportRow(transaction: Transaction) {
if (transaction.type === 'deposit') {
return {title: 'واریز', sign: '+'}
}

if (transaction.type === 'withdraw') {
return {title: 'برداشت', sign: '-'}
}

if (transaction.type === 'transfer') {
return {title: 'انتقال', sign: '-'}
}

if (transaction.type === 'refund') {
return {title: 'برگشت وجه', sign: '+'}
}
}

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

نرم‌افزاری که فقط کار می‌کند، هنوز لزوماً خوب نیست

· ۱۰ دقیقه مطالعه
مهدی مالوردی
مهندس نرم‌افزار و نویسندهٔ این سایت

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

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

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