اصول توسعه نرم‌افزار: ۱۲ اصلی که نرم‌افزار خوب را از بد جدا می‌کند

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

چرا اصول توسعه نرم‌افزار مهم است؟

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

این اصول را می‌شود در دو دسته دید: اصولی که به خود کد مربوط‌اند و اصولی که به فرایند ساخت مربوط‌اند. هر دو لازم‌اند؛ کد تمیز بدون فرایند درست دوام نمی‌آورد و فرایند خوب هم کد بد را نجات نمی‌دهد.

بخش اول: اصول طراحی و نوشتن کد

۱. KISS: ساده نگهش دار

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

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

۲. DRY: هر دانسته فقط یک جا

Don't Repeat Yourself می‌گوید هر قاعده‌ی کسب‌وکار باید فقط در یک نقطه تعریف شود. اگر نرخ مالیات در پنج فایل مختلف نوشته شده باشد، روزی که عوض شود، دیر یا زود یکی از آن پنج جا جا می‌ماند و باگی می‌سازد که پیدا کردنش سخت است.

۳. YAGNI: چیزی را که لازم نداری نساز

You Aren't Gonna Need It یعنی قابلیت‌ها را برای نیاز واقعی امروز بساز، نه برای نیاز فرضی فردا. بخش بزرگی از کدی که «برای آینده» نوشته می‌شود هیچ‌وقت استفاده نمی‌شود، ولی باید نگهداری شود، تست شود و فهمیده شود. همین اصل پایه‌ی فکری MVP هم هست: اول هسته را بساز، بعد بر اساس بازخورد واقعی گسترش بده.

۴. تفکیک مسئولیت‌ها (Separation of Concerns)

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

۵. SOLID: پنج اصل برای کد قابل توسعه

SOLID مجموعه‌ای از پنج اصل است که رابرت مارتین آن‌ها را شناخته‌شده کرد. خلاصه و بی‌اصطلاح:

• S (تک‌مسئولیتی): هر ماژول فقط یک دلیل برای تغییر داشته باشد.
• O (باز/بسته): برای اضافه کردن رفتار جدید، کد جدید اضافه کن؛ لازم نباشد کد سالم و تست‌شده‌ی قبلی را دستکاری کنی.
• L (جایگزینی لیسکوف): هر پیاده‌سازی یک قرارداد باید بتواند بی‌دردسر جای پیاده‌سازی دیگر همان قرارداد بنشیند.
• I (تفکیک رابط‌ها): رابط‌های کوچک و متمرکز بهتر از یک رابط غول‌پیکر همه‌کاره‌اند.
• D (وارونگی وابستگی): منطق اصلی به جزئیات (مثل یک پایگاه داده‌ی خاص) وابسته نباشد؛ هر دو به یک قرارداد انتزاعی وابسته باشند.

SOLID دستورالعمل مکانیکی نیست؛ ابزاری برای تشخیص است. وقتی تغییر یک بخش مدام بخش‌های دیگر را خراب می‌کند، معمولاً یکی از این پنج اصل زیر پا گذاشته شده.

۶. خوانایی مهم‌تر از زرنگی

کد یک بار نوشته می‌شود و ده‌ها بار خوانده می‌شود. نام‌گذاری روشن، تابع‌های کوتاه و یک سبک یکدست (که با ابزارهایی مثل linter و formatter خودکار می‌شود) از هر ترفند هوشمندانه‌ای ارزشمندترند. کامنت خوب توضیح می‌دهد چرا کاری انجام شده؛ چه کاری را باید خود کد بگوید.

بخش دوم: اصول فرایند ساخت

۷. کنترل نسخه برای همه چیز

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

۸. بازبینی کد (Code Review)

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

۹. تست خودکار، به‌اندازه و در جای درست

تست خودکار شبکه‌ی ایمنی تغییر است: وقتی تست‌ها سبزند، با خیال راحت کد را بهبود می‌دهی. الگوی رایج «هرم تست» است:

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

هدف پوشش صددرصدی نیست؛ هدف این است که مسیرهایی که خرابی‌شان گران تمام می‌شود همیشه تست شوند.

۱۰. یکپارچه‌سازی و تحویل مداوم (CI/CD)

هر تغییر باید به‌صورت خودکار ساخته، تست و در صورت موفقیت منتشر شود. وقتی انتشار یک دکمه یا حتی خودکار است، نسخه‌ها کوچک‌تر و مکرّرتر می‌شوند و هر مشکل سریع‌تر و با دامنه‌ی کوچک‌تر پیدا می‌شود. اجرای نرم‌افزار در کانتینر (مثل Docker) هم باعث می‌شود «روی سیستم من کار می‌کرد» دیگر بهانه نباشد.

۱۱. امنیت از روز اول

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

۱۲. مستندسازی و قابلیت مشاهده

دو سؤال باید همیشه جواب ساده داشته باشند: «چطور این پروژه را اجرا کنم؟» و «الان در سیستم چه اتفاقی می‌افتد؟». اولی با یک README خوب و مستندات راه‌اندازی جواب داده می‌شود؛ دومی با لاگ‌گیری منظم، مانیتورینگ و هشدار خطا. نرم‌افزاری که نمی‌توانی ببینی داخلش چه می‌گذرد را نمی‌توانی درست نگه داری.

این اصول در عمل: توازن، نه وسواس

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

اگر برنامه‌نویس نیستید: پنج سؤال از تیم سازنده

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

1. کد پروژه در کدام مخزن نگهداری می‌شود و آیا من به آن دسترسی دارم؟
2. کد قبل از انتشار توسط چه کسی بازبینی می‌شود؟
3. کدام بخش‌ها تست خودکار دارند؟
4. انتشار نسخه‌ی جدید چطور انجام می‌شود و اگر خراب شد، برگشت به نسخه‌ی قبل چقدر طول می‌کشد؟
5. اگر فردا تیم دیگری بخواهد کار را ادامه دهد، چه مستنداتی تحویل می‌گیرد؟

جواب‌های روشن و بدون مکث نشانه‌ی خوبی است. برای بررسی کامل‌تر هنگام تحویل پروژه، چک‌لیست تحویل نرم‌افزار را ببینید.

جمع‌بندی

اصول توسعه نرم‌افزار ابزار کندتر کار کردن نیستند؛ ابزار سریع ماندن‌اند. تیمی که ساده می‌نویسد، تکرار نمی‌کند، چیز اضافه نمی‌سازد، کدش را بازبینی و تست می‌کند و خودکار منتشر می‌کند، هفته‌ی صدم هم با همان سرعت هفته‌ی اول جلو می‌رود. ما در گیک‌ویر هر پروژه را، از یک MVP کوچک تا یک سامانه‌ی کامل، با همین اصول می‌سازیم.