در دنیای توسعه نرمافزار، همواره با برنامهنویسانی مواجه میشویم که از تغییرات مداوم کارفرمایان یا مدیران محصول گلایه دارند. آنها اغلب تصور میکنند که باید یکبار کدی بنویسند و دیگر هرگز آن را دست نزنند. اما آیا این نگاه واقعبینانه است؟ مشخصاً خیر.
چرا نرمافزار «نرم» است؟
به محصولاتی که ما تولید میکنیم «نرمافزار» گفته میشود، و این واژه بهدرستی انتخاب شده است. چون بر خلاف سختافزار، نرمافزار باید قابلیت تغییر و انطباق مداوم با شرایط جدید را داشته باشد. اگر قرار بود نرمافزار تغییر نکند، میتوانستیم آن را هم «سختافزار» بنامیم.
واقعیت این است که نیازمندیهای یک پروژه نرمافزاری هرگز ثابت نمیمانند. تغییرات در بازار، کاربران، رقبا و تکنولوژی همواره در حال شکلدهی به نیازهای جدید هستند. بنابراین، نرمافزاری که نتواند به این تغییرات پاسخ دهد، عملاً مرده است.
راهحل چیست؟ معماری تمیز + کد تمیز
برای پاسخگویی مؤثر به تغییرات، ما به دو چیز نیاز داریم:
- معماری تمیز (Clean Architecture)
- کد تمیز (Clean Code)
۱. معماری: مهندسی ساختار نرمافزار
معماری یعنی ساختار. همانطور که یک خانه از دیوار، سقف، ستون و نقشهی مشخص ساخته شده، نرمافزار نیز باید ساختار داشته باشد. اما برخلاف خانه، اجزای سازندهی نرمافزار آجر یا سیمان نیستند، بلکه خود نرمافزارهای کوچکترند.
نرمافزارهای بزرگ از ماژولها و سرویسهای کوچکتری ساخته شدهاند. اگر این اجزا مرزبندیشده، مستقل و منعطف نباشند، هر تغییری در یک قسمت، مانند دومینو به دیگر قسمتها آسیب میزند.
معماری تمیز یعنی ساختن لایههایی با وابستگیهای کنترلشده.
یعنی دانستن اینکه “چه چیزی باید از چه چیزی آگاه باشد” و “چه چیزی نباید به چیزی دیگر وابسته باشد”.
مهمترین اصول معماری تمیز:
1- وابستگی به درون باشد نه بیرون
فرض کن در یک فروشگاه اینترنتی، ماژول سفارش (Order) نباید وابسته به دیتابیس MySQL یا یک API پرداخت خاص باشد. اگر روزی خواستید دیتابیس را به PostgreSQL یا MongoDB تغییر دهید، منطق سفارش همچنان سالم میماند.
راهحل: تعریف Interface برای PaymentService و پیادهسازی آن توسط هر درگاه پرداخت.
2- جزئیات قابل تعویض باشند، نه منطق اصلی
مثلاً در یک اپلیکیشن پیامرسان، منطق ارسال پیام نباید به WebSocket یا Firebase وابسته باشد. باید یک لایه انتزاعی (MessageSender) داشته باشیم تا بتوانیم بعداً روش ارسال را عوض کنیم.
3- چیدمان بر اساس انتزاع نه تکنولوژی
به جای اینکه پوشههایت را بر اساس controllers, services, repositories بسازی، بهتر است بر اساس Domain (مانند users, orders, products) بسازی. اینطوری تغییرات در یک حوزه مستقل خواهد بود.
۲. کد تمیز: مهندسی جزئیات
حتی اگر یک نقشهی معماری عالی داشته باشیم، ولی آجرها را بیدقت روی هم بچینیم، نتیجه خانهای زشت، ناامن و غیرقابل سکونت خواهد بود. همین موضوع در نرمافزار هم صادق است.
کدی که نامگذاری بد، تکرار زیاد، توابع طولانی یا وابستگیهای پیچیده دارد، هرچند در معماری خوبی قرار گرفته باشد، توسعهپذیر نخواهد بود.
کد تمیز یعنی کدی که خوانا، تغییرپذیر و قابل تست باشد.
کتاب “Clean Code” و “Clean Architecture” نوشتهی رابرت مارتین (عمو باب) منابعی اساسی هستند که توضیح میدهند:
- چگونه تشخیص دهیم یک کد یا معماری، تمیز یا کثیف است؟
- چه معیارهایی برای ارزیابی ساختار نرمافزار وجود دارد؟
- چگونه نرمافزاری بسازیم که در بلندمدت همچنان زنده و قابل نگهداری باشد؟
🔗 لینک خواندن بیشتر:
The Clean Architecture by Uncle Bob
برنامهنویسی، ساخت کد نیست، مهندسی کد است
برنامهنویسی فقط یعنی تایپ کردن کد؟ نه! برنامهنویسی یعنی «مهندسی»، یعنی تصمیمگیری درباره ساختار، وابستگیها، الگوها، اصول SOLID، تستپذیری و نگهداری.
متأسفانه در بسیاری از شرکتها، توسعهدهندگان شبانهروز مشغول کدنویسیاند، بدون آنکه به معماری، طراحی و اصول مهندسی فکر کنند. نتیجه؟ کدی که کار میکند ولی قابل تغییر نیست. نرمافزاری که اجرا میشود ولی هیچکس جرات نمیکند به آن دست بزند!
اگر معماری تمیز و کد تمیز را جدی بگیریم:
- توسعه سریعتر خواهد شد
- تغییرات کمهزینهتر خواهند بود
- تجربه تیم لذتبخشتر میشود
- نرمافزار عمر طولانیتری خواهد داشت
جمعبندی
معماری تمیز راهی برای مقابله با پیچیدگی، تغییرپذیری و آشفتگی نرمافزارهاست. این رویکرد به ما کمک میکند تا سیستمهایی بسازیم که با تغییرات رشد کنند، نه فروبپاشند.
پس اگر میخواهید از شغلتان لذت ببرید، نرمافزارهایی بسازید که مانند یک شهر خوب طراحیشدهاند: زیبا، منظم، قابل توسعه و آیندهنگر.
