پرووید
آموزش برنامه نویسی فول استک (Full-stack) و معماری نرم افزار
آموزش برنامه نویسی فول استک Full-stack و معماری نرم افزار در دات نت سری سوم یکی دیگر از آموزش های گروه آموزشی پرووید می باشد که در این قسمت آن را به شما معرفی می کنیم. این بسته ی آموزشی نیز یکی از دوره های آموزشی دیگر که در حوزه ی فارسی سازی آموزش های انگلیسی تنظیم شده است می باشد. عنوان این بسته ی آموزشی تبدیل شدن به یک توسعه دهنده Full-stack در دات نت - معماری و تست است که با نام اصلی Become a Full stack .NET Developer Architecture and Testing از شرکت Pluralsight منتشر شده است.
یک توسعه دهنده ی Full-stack کیست؟
یک توسعه دهنده ی Full-stack یا همان Full-Stack Developer برنامه نویسی است که می تواند هم بر روی قسمت front-end یک نرم افزار کار کند و هم قسمت back-end.
یک Full-Stack Developer ممکن است دانش عمیق و تخصص کامل بر روی تکنولوژی های front-end و back-end نداشته باشد ولی دانش کافی بر روی این تکنولوژی ها را دارد. در قسمت زیر مهارت های مورد نیاز برای یک Full-Stack Web Developer را بررسی می کنیم.
HTML CSS Bootstrap JavaScript jQuery AJAX C# دیتابیس ها
علاوه بر این تکنولوژی ها، برخی از تکنولوژی های جدید از قبیل موارد زیر نیز وجود دارند که در توسعه نرم افزارهای وب مورد استفاده قرار می گیرند.
Node.js TypeScript Angular MVC .NET Core
ضمناً ذکر این نکته نیز مهم است که سری اول و دوم این محصول با عنواین آموزش برنامه نویسی فول استک Full-stack در دات نت سری اول و آموزش پیشرفته برنامه نویسی فول استک Full-stack در دات نت سری دوم پیش از این بر روی وبسایت پرووید منتشر شده اند.
Clean Architecture در توسعه Full-stack چیست؟
Clean Architecture رویکردی برای سازمان‌دهی نرم‌افزار است که بر جداسازی مسئولیت‌ها و کاهش وابستگی میان بخش‌های مختلف سیستم تأکید دارد. در چنین ساختاری، منطق اصلی برنامه نباید به جزئیات پیاده‌سازی مانند چارچوب رابط کاربری یا روش دسترسی به داده وابستگی غیرضروری داشته باشد. این جداسازی به توسعه‌دهندگان کمک می‌کند تغییرات یک بخش را با اثرگذاری کمتر بر سایر بخش‌ها اعمال کنند و ساختار برنامه را در طول توسعه قابل فهم‌تر نگه دارند.
در این دوره، ریفکتور کردن کد به سمت Clean Architecture و برنامه‌نویسی در مقابل Interfaceها بررسی می‌شود. این مباحث به توسعه‌دهنده نشان می‌دهند که چگونه می‌توان وابستگی‌های مستقیم میان اجزای برنامه را کاهش داد و قراردادهای مشخصی برای تعامل آن‌ها تعریف کرد. چنین رویکردی به‌ویژه در پروژه‌های Full-stack اهمیت دارد؛ زیرا منطق کسب‌وکار، لایه دسترسی به داده و بخش‌های مختلف برنامه باید به شکلی هماهنگ اما مستقل‌تر طراحی شوند.
چرا برنامه‌نویسی در مقابل Interfaceها اهمیت دارد؟
در طراحی نرم‌افزار، Interface قرارداد مشخصی برای رفتار یک بخش از سیستم تعریف می‌کند، بدون آنکه جزئیات پیاده‌سازی آن را الزاماً آشکار کند. زمانی که یک کلاس به Interface وابسته باشد، می‌توان پیاده‌سازی‌های متفاوتی را با رعایت همان قرارداد به کار گرفت. این شیوه به کاهش وابستگی میان اجزای برنامه کمک می‌کند و امکان تغییر یا جایگزینی یک پیاده‌سازی را بدون ایجاد تغییرات گسترده در کدهای مصرف‌کننده افزایش می‌دهد.
برنامه‌نویسی در مقابل Interfaceها همچنین می‌تواند طراحی و تست نرم‌افزار را ساده‌تر کند. برای نمونه، اگر یک Controller از طریق یک Interface با Repository ارتباط داشته باشد، می‌توان هنگام تست، پیاده‌سازی واقعی را با یک نمونه آزمایشی جایگزین کرد. در این آموزش، این مفهوم در کنار ریفکتور کردن ساختار برنامه مطرح می‌شود تا ارتباط میان طراحی لایه‌ای، کاهش وابستگی‌ها و قابلیت آزمون‌پذیری بهتر روشن شود.
تست Controller و Repository در .NET
تست کردن Controllerها و Repositoryها به بررسی رفتار بخش‌های مختلف برنامه کمک می‌کند. Controller معمولاً درخواست‌های ورودی را دریافت و جریان اجرای یک قابلیت را مدیریت می‌کند، در حالی که Repository مسئولیت دسترسی به داده‌ها را بر عهده دارد. با نوشتن تست‌های مناسب می‌توان رفتار مورد انتظار هر بخش را بررسی کرد و در صورت ایجاد تغییر در کد، خطاهای احتمالی را زودتر شناسایی کرد. تفکیک مسئولیت‌ها در طراحی برنامه، نوشتن تست‌های متمرکز را آسان‌تر می‌کند.
در این دوره، تست Controllerها و Repositoryها در کنار اضافه کردن Integration Testها بررسی می‌شود. Unit Test معمولاً رفتار یک بخش را در شرایط کنترل‌شده می‌سنجد، در حالی که Integration Test تعامل میان چند جزء را بررسی می‌کند. استفاده از هر دو نوع تست می‌تواند دید کامل‌تری از صحت عملکرد برنامه فراهم کند. برای توسعه‌دهندگان Full-stack، درک تفاوت این روش‌ها و انتخاب تست متناسب با هدف، بخشی مهم از فرایند ساخت و نگهداری نرم‌افزار است.
ماژول‌بندی JavaScript و ریفکتور کردن کد
با بزرگ‌تر شدن یک Web Application، نگهداری تمام کدهای JavaScript در ساختاری یکپارچه می‌تواند دشوار شود. ماژول‌بندی به تقسیم کد به بخش‌هایی با مسئولیت‌های مشخص کمک می‌کند و خواندن، توسعه و نگهداری آن را ساده‌تر می‌سازد. وقتی هر ماژول وظیفه روشن‌تری داشته باشد، درک ارتباط میان قابلیت‌های مختلف آسان‌تر می‌شود و تغییر در یک بخش می‌تواند با اثرگذاری محدودتری بر سایر قسمت‌ها انجام شود.
در این آموزش، ماژول‌بندی کد JavaScript در کنار تکمیل Use Caseها، ریفکتور کردن و پیاده‌سازی تست‌ها مطرح می‌شود. این ترکیب نشان می‌دهد که معماری مناسب فقط به ساختار سمت سرور محدود نیست و سازمان‌دهی کدهای سمت کاربر نیز اهمیت دارد. اگر در توسعه برنامه‌های Full-stack با افزایش پیچیدگی کد روبه‌رو هستید، آشنایی با این مباحث می‌تواند به شکل‌گیری ساختاری منظم‌تر و قابل نگهداری‌تر کمک کند.
سرفصل مطالب آموزش ویدئویی تبدیل شدن به یک توسعه دهنده Full-stack در دات نت سری سوم
فصل اول: پیاده سازی Use Case های باقی مانده
- مقدمه
- برنامه ریزی کردن Iteration سوم
- تمرین
- مرور کردن Gig
- استفاده کردن از Lookup ها
- پیدا کردن Affected Area ها در کد
- پیاده سازی Toggle Behavior
- مرور کردن کد
- جمع بندی
فصل دوم: ماژول بندی کردن کد جاوا اسکریپت
- مقدمه
- Extract کردن کد جاوا اسکریپت
- مشخص کردن الگوی Revealing Module
- ریفکتور کردن با استفاده از الگوی Revealing Module
- Clean کردن متد Init
- اعمال کردن اصل DRY
- اعمال بهتر Separation of Concerns
- Dependency های Module ها
- بررسی Physical Separation
- بررسی Optimization ها
- تمرین
- مرور کردن کد
- جمع بندی
فصل سوم: ریفکتور کردن به سمت یک Clean Architecture
- مقدمه
- Extract کردن Query ها
- الگوی Repository
- زمان صحبح استفاده از الگوی Repository
- Extract کردن Repository ها
- Extract کردن Query ها با Eager Loading
- تمرین
- مرور کردن کد
- بررسی Clean Architecture
- Decouple کردن از Entity Framework
- الگوی Unit of Work
- پیاده سازی الگوی Unit of Work
- منسجم کردن Dependency ها
- جمع بندی
فصل چهارم: برنامه نویسی در مقابل Interface ها
- مقدمه
- اصل Dependency Inversion
- Extract کردن Interface ها
- الگوی Dependency Injection
- اضافه کردن Ninject
- آیا Entity Framework واقعاً الگوی Repository را پیاده سازی می کند؟
- بررسی Package Dependency ها
- ساختاربندی کردن مجدد برنامه
- بررسی کردن Complexity Fallacy
- بررسی کردن Productivity Fallacy
- تمرین
- ریفکتور کردن Data Annotation ها
- جمع بندی
فصل پنجم: تست کردن Controller ها
- مقدمه
- قوانین کلی
- راه اندازی کردن Test Project
- Mock کردن User فعلی
- ریفکتورینگ
- اولین تست
- استفاده کردن از Live Template های ReSharper
- تست دوم
- تست سوم
- تست چهارم
- Behavior را تست کنید، نه Implementation را
- ریفکتور کردن Unit Test
- تست کردن Domain Class ها
- بررسی کردن Test Initilize
- تمرین
- جمع بندی
فصل ششم: تست کردن Repository ها
- مقدمه
- Unit Test ها و Integration Test ها
- Mock کردن DbContext
- Mock کردن DbSet
- اولین تست
- دومین تست
- سومین تست
- جهارمین تست
- تمرین
- جمع بندی
فصل هفتم: اضافه کردن Integration Test ها
- مقدمه
- راه اندازی کردن پروژه ی Integration Test
- راه اندازی کردن دیتابیس Integration Test
- Seed کردن داده
- Isolate کردن Test Data ها
- استراتژی های انجام تست
- Mock کردن User فعلی
- Mock Object های Clean تر
- اولین تست
- دومین تست
- Test Coverage ها
- تمرین
- جمع بندی
محصولات مرتبط
