مختصری از اصول توسعه نرم‌افزار

در بحث‌های مهندسی نرم‌افزار و مخصوصا توسعه‌ نرم‌افزار و برنامه‌نویسی یکسری اصول و بهترین‌روشها (Best Practices) و الگوهای طراحی (Design Patterns) وجود دارد، که در واقع اگر به‌خوبی درک شوند و البته در جای متناسب استفاده شود، راحتی و پایداری توسعه را تضمین میکند و عمر مفید نرم‌افزار را به‌شدت افزایش میدهد.

با هم چند اصل مهم و معروف دنیای نرم‌افزار را مرور میکنیم

DRY – Don't Repeat Yourself: The guiding thought behind the Don't Repeat Yourself (DRY) principle is that duplication is a waste of time and effort.

KISS - Keep It Simple Stupid: stresses that simplicity should be the goal and complexity should be avoided.

You Aren't Gonna Need It (YAGNI) simply states that functionality should only be added when it is required

By taking a Minimum Viable Product (MVP) approach, the scope of a piece of work is limited to the smallest set of requirements in order to produce a functioning deliverable.

SOLID

• Single responsibility principle : A class should have only one responsibility.
• اصل SRP برای رفع این مشکل میگوید "هر ماژول نرم افزاری میبایست تنها یک دلیل برای تغییر داشته باشد".
• اصل OCP  -  Open Close Principle میگوید : "ماژول‌های نرم افزار باید برای تغییرات بسته و برای توسعه باز باشند.”
• 1- استفاده از وراثت (inheritance):
• 2- متدهای  الحاقی (Extension Method):
• اصل LSP -  Liskov substitution principle میگوید : "زیر کلاس‌ها باید بتوانند جایگزین نوع پایه‌ی خود باشند".
• اصل ISP– Interface Segregation principle
• اصل ISP  میگوید : " کلاینت‌ها نباید وابسته به متدهایی باشند که آنها را پیاده سازی نمی‌کنند. “
• بجای پیاده‌سازی کلیه متدها در یک اینترفیس، در ایتنرفیس‌های جداگانه بنا به نیاز طراحی میشود که پیاده‌کنندگان آن اینترفیس فقط موارد مدنظرشان پیاده‌سازی شود.

public interface IEmployeeReportBAL{
void GeneratePFReport();
void GenerateESICReport();
}

public interface IManagerReportBAL : IEmployeeReportBAL{
void GenerateResourcePerformanceReport();
void GenerateProjectSchedule();
}

public interface IAdminReportBAL : IManagerReportBAL{
void GenerateProfitReport(); // فقط ادمین نیاز به پیاده‌سازی چنین متدی دارد و نه کارمند و مدیر
}

• • اصل DIP  به ما میگوید : " ماژول‌های سطح بالا نباید به ماژولهای سطح پایین وابسته باشند، هر دو باید به انتزاعات وابسته باشند. انتزاعات نباید وابسته به جزئیات باشند، بلکه جزئیات باید وابسته به انتزاعات باشند. ".

بقول Uncle Bob، سیستم‌هایی که مدیریت وابستگی در آن رعایت نمی‌شود این ۴ بو (Smell) را همراه خود خواهند داشت:

• سختی یا Rigidity
• سختی یا Rigidity یعنی ناتوانی در تغییر. /  اگر برای تغییر دادن بخش کوچکی از کد مجبور شویم کل سیستم را مجددا rebuild کنیم، آنوقت آن سیستم سخت شده یا دچار Rigidty شده است.
• شکنندگی یا Fragility
• مفهوم Fragility و Rigidity بسیار بهم نزدیک اند. درواقع شکنندگی و سختی، علت و معلول یکدیگر هستند. شکنندگی یا Fragility اشاره دارد به اینکه هر موقع تغییری در سیستم ایجاد می‌کنید در بخش (یا بخش‌های) دیگری از سیستم - که حتی هیچ ربطی با آن قسمت ندارد - با خطا و مشکل مواجه می‌شوید.
• عدم تحرک یا Immobility
• نتوانیم آن قسمت از کد یا کامپوننت را در دیگر بخش‌های سیستم استفاده کنیم.
• چسبناکی یا Viscosity
• چسبناکی، ویسکوزیته یا Viscosity مقاومت در مقابل تغییر است. وقتی که ساخت مجدد و تست سیستم برای ما سخت می‌شود و ترجیح بدهیم از خیر تغییرات آن قسمت بگذریم، آنگاه کد ما viscous یا چسبناک است.