2 پست با برچسب "پیچیدگی نرم‌افزار"

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

آیا می‌توانیم بگوییم خانه را نوسازی کرده‌ایم؟

خیلی از تیم‌ها با نرم‌افزارشان همین کار را می‌کنند. فناوری تازه می‌آورند، سامانه را به ریزخدمت‌ها تقسیم می‌کنند یا زیرساخت را به فضای ابری می‌برند؛ اما مرزهای بد، فرایندهای پیچیده و وابستگی میان تیم‌ها را دست‌نخورده باقی می‌گذارند. ظاهر معماری عوض می‌شود، ولی دردهای قدیمی سر جایشان می‌مانند.

تیم وسط یک تصمیم سخت گیر کرده بود. از یک طرف، چند نفر می‌گفتند باید از همین حالا همه‌چیز را کامل جدا کنیم: ماژول مستقل، پایگاه داده‌ی جدا، قراردادهای رسمی، صف پیام، بسته‌بندی جداگانه و حتی شاید سرویس مستقل. از طرف دیگر، چند نفر می‌گفتند هنوز زود است؛ بهتر است همه‌چیز در همان کد فعلی بماند تا کار سریع‌تر جلو برود. بحث، ظاهراً درباره‌ی معماری بود، اما در عمل به دو گزینه‌ی افراطی تقلیل پیدا کرده بود: یا دیوار کامل بسازیم، یا اصلاً مرزی نکشیم.

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