‏۴ نشانه‌ی طراحی بد نرم‌افزار

یه مهندس نرم‌افزار باتجربه چهار نشانه‌ی کلاسیک طراحی بد رو معرفی می‌کنه که احتمالاً توی هر پروژه‌ی واقعی باهاشون روبرو شدی — حتی اگه اسمشون رو ندونی.

۱. Rigidity (سختی تغییر) وقتی یه تغییر کوچیک توی یه ماژول، یه دومینوی از تغییرات توی بقیه‌ی سیستم راه می‌ندازه، سیستمت rigid شده. معمولاً دلیلش کوپلینگ بیش از حده — همه چیز به هم گره خورده. راه‌حل: الگوی Strategy و اصل Open/Closed. به جای یه switch بزرگ برای منطق‌های مختلف، یه اینترفیس تعریف کن و هر رفتار رو در یه کلاس جداگانه پیاده‌سازی کن. اضافه کردن حالت جدید یعنی ساختن یه کلاس جدید، نه لمس کردن کد قدیمی.

۲. Fragility (شکنندگی) وقتی یه باگ توی ماژول پرداخت رو درست می‌کنی و گزارش انبار خراب می‌شه، سیستمت شکننده‌ست. دلیل اصلی وابستگی‌های پنهان و اطلاعات بیش از حدیه که ماژول‌ها از درون هم دارن. راه‌حل: Interface Segregation — یه آبجکت کانفیگ سراسری نداشته باش؛ به جاش برای هر ماژول یه اینترفیس جداگانه تعریف کن مثل PayrollConfig و ReportConfig تا هر بخش فقط چیزی رو ببینه که بهش مربوطه.

۳. Immobility (ناتوانی در استفاده‌ی مجدد) یه الگوریتم عالی نوشتی ولی نمی‌تونی ازش توی پروژه‌ی دیگه‌ای استفاده کنی چون به UI، دیتابیس و کتابخونه‌های خارجی وابسته‌ست؟ این یعنی سیستمت immobile شده. راه‌حل: Clean Architecture — منطق کسب‌وکار رو توی یه کلاس خالص (مثلاً یه Use Case ساده) بنویس که نه از UI چیزی می‌دونه و نه از دیتابیس. دیتابیس رو از طریق اینترفیس بهش تزریق کن (Dependency Inversion). نتیجه: می‌تونی اون کد رو ببری هر جایی.

۴. Viscosity (مقاومت در برابر روش درست) وقتی روش تمیز یه ساعت طول می‌کشه ولی یه هک کثیف ۵ دقیقه‌ای هست، اکثر توسعه‌دهنده‌ها مسیر سریع‌تر رو انتخاب می‌کنن. viscosity هم می‌تونه مشکل نرم‌افزار باشه (معماری پیچیده)، هم مشکل محیط (کامپایل کند، تست‌های طولانی). راه‌حل: اتوماسیون و ابزارهایی مثل MapStruct یا AutoMapper که کدهای تکراری (boilerplate) رو حذف می‌کنن. هدف اینه که «روش درست» تقریباً به همون سرعت «روش اشتباه» باشه.

نکات کلیدی:

• سیستم rigid رو با الگوهایی مثل Strategy از هم جدا کن تا تغییر آسون‌تر بشه
• از state سراسری و وابستگی‌های پنهان دوری کن تا شکنندگی کنترل بشه
• منطق کسب‌وکار نباید به UI یا فریمورک وابسته باشه — وگرنه قابل انتقال نیست
• اگه روش درست سخت‌تر از هک باشه، سیستم پر از هک می‌شه — توی محیط توسعه سرمایه‌گذاری کن
• این چهار نشانه قابل درمانن؛ شناختنشون اولین قدم به سمت ریفکتور واقعیه