اکنون، مردم اغلب درباره توسعه چابک صحبت می‌کنند.
توسعه چابک چیست؟
توسعه چابکیک قابلیت توسعه نرم‌افزار است که به نیازهای به سرعت در حال تغییر پاسخ می‌دهد. نام‌ها، مفاهیم، فرآیندها و اصطلاحات خاص آن‌ها متفاوت است. در مقایسه با غیر چابکآن‌ها بر همکاری نزدیک بین تیم‌های برنامه‌نویس و کارشناسان کسب‌وکار، ارتباط رو در رو (که مؤثرتر از مستندات مکتوب در نظر گرفته می‌شود) تأکید می‌کنند و به‌طور مکرر نسخه‌های جدید نرم‌افزار را منتشر می‌کنند، کوچک و تیم‌های خودسازماندهبرای نوشتن ویژگی‌های کوچک و با ارزش و رویکردهای سازماندهی تیم که به نیازهای در حال تغییر سازگار می‌شوند، با تمرکز بیشتر بر نقش افراد در توسعه نرم‌افزار.
با این حال، چندین نسخه مشابه از روش‌های توسعه چابک TDD وجود دارد، مانند TDD: BDD، DDD و ATDD. اجازه دهید این روش‌ها را به‌طور مختصر معرفی کنم قبل از اینکه TDD را به تفصیل معرفی کنم:
TDD: توسعه مبتنی بر تست
توسعه مبتنی بر تست (TDD) یک فرآیند توسعه نرم‌افزار است که به تبدیل نیازهای نرم‌افزاری به موارد تست قبل از توسعه کامل نرم‌افزار متکی است و تمام توسعه نرم‌افزار را با آزمایش مکرر نرم‌افزار برای تمام موارد تست پیگیری می‌کند. این برعکس توسعه نرم‌افزار اول و سپس ایجاد موارد تست است. برخی مدل‌های محبوب به‌خوبی از TDD پشتیبانی می‌کنند، مانند MVC و MVP.
BDD: توسعه مبتنی بر رفتار (توسعه مبتنی بر رفتار)
توسعه مبتنی بر رفتار (BDD) نیز یک فرآیند توسعه نرم‌افزار چابک است. این فرآیند همکاری بین توسعه‌دهندگان، تست‌کنندگان تضمین کیفیت و نمایندگان مشتری در پروژه‌های نرم‌افزاری را تشویق می‌کند. این فرآیند تیم‌ها را تشویق می‌کند تا از گفتگوها و مثال‌های عینی برای رسمی کردن درک مشترک از نحوه عملکرد برنامه استفاده کنند. این از توسعه مبتنی بر تست (TDD) نشأت می‌گیرد.
ATDD: توسعه مبتنی بر تست پذیرش
برای ترویج تحقق کد کاربردی از طریق موارد تست واحد، تیم نیاز دارد که استانداردهای کیفیت مورد انتظار و قوانین پذیرش را تعریف کند و تمرین TDD توسعه‌دهندگان و عملکرد تست‌کنندگان را از طریق یک برنامه تست پذیرش واضح و سازگار (شامل یک سری سناریوهای تست) ترویج کند. برای توسعه‌دهندگان، این بر نحوه پیاده‌سازی سیستم و نحوه تست آن تأکید می‌کند.
DDD: طراحی مبتنی بر دامنه
DDD به طراحی مبتنی بر دامنه اشاره دارد، یعنی توسعه مبتنی بر دامنه. DDD در واقع بر این پایه ساخته شده است زیرا بر طراحی لایه خدمات تمرکز دارد، بر پیاده‌سازی کسب‌وکار تمرکز می‌کند، تجزیه و تحلیل و طراحی را ترکیب می‌کند و دیگر آن را در حالت تقسیم شده نگه نمی‌دارد، تا نیازهای مشتری را به‌درستی و به‌طور جامع پیاده‌سازی کند و مدلی از مقیاس‌پذیری کسب‌وکار بسازد.
برنامه پیاده‌سازی TDD
از طریق تست برای ترویج کل توسعه، اما توسعه مبتنی بر تست تنها یک کار تست ساده نیست، بلکه یک فرآیند کمی‌سازی تحلیل نیازها، طراحی و کنترل کیفیت است.
اصول توسعه
ابتدا کد تست را بنویسید و سپس کد تابع را بنویسید.
- کد تست را بر اساس سند نیازها بنویسید، نه برای تحقق تابع؛
- نمی‌خواهید با یک لقمه چاق شوید. هنگام تست بلوک‌های عملکردی بزرگ، ابتدا باید آن‌ها را به بلوک‌های عملکردی کوچکتر برای تست تقسیم کنید؛
- به یاد داشته باشید که کد را برای تکمیل تابع ننویسید، از ساده‌ترین کد ممکن برای پیاده‌سازی تابع استفاده کنید؛
- اگر نیازها قابل تست هستند، کد تست بنویسید و از آن‌هایی که قابل تست نیستند یا احساس می‌کنید نیازی به تست ندارند، صرف‌نظر کنید؛
- قبل از تغییر/اضافه کردن هر کد تابع، ابتدا باید فکر کنید که آیا می‌خواهید موارد تست را تغییر دهید/اضافه کنید؛
- کد تابع/تست، ساختار غیرمنطقی، کد تکراری و غیره، پس از گذراندن تست به‌موقع بازساخت کنید.
فرآیند توسعه TDD
- تحلیل و تعیین یک سناریوی تست هدف؛
- یک تست واحد اضافه کنید تا ورودی و خروجی سناریوی تست را تأیید کنید؛
- تست را اجرا کنید و نتیجه تست ناموفق را بگیرید؛
- ساده‌ترین کد تابع را بنویسید تا تست را پاس کند؛
- تست را دوباره اجرا کنید و ببینید که تست پاس می‌شود؛
- بازساخت کد را انجام دهید، شامل کد تابع و کد تست واحد؛
- مراحل فوق را تکرار کنید تا توسعه کامل شود.
مزایای TDD
- کاهش بار بر دوش توسعه‌دهندگان. از طریق یک فرآیند واضح، اجازه دهید فقط بر روی یک نقطه در یک زمان تمرکز کنیم و بار تفکر کمتر باشد.
- شبکه حفاظتی. پوشش کامل تست واحد یک شبکه حفاظتی برای کد محصول فراهم می‌کند و تغییرات در نیازها یا بهبود طراحی کد را آسان می‌سازد. بنابراین اگر نیازهای پروژه شما پایدار باشد، یک‌باره انجام شود و تغییرات بعدی وجود نداشته باشد، مزایای TDD کمتر است.
- نیازها را از قبل روشن کنید. نوشتن تست‌ها در ابتدا می‌تواند به ما کمک کند تا درباره نیازها فکر کنیم و جزئیات نیازها را از قبل روشن کنیم، نه اینکه فقط در نیمه راه کد نیازهای نامشخص را کشف کنیم.
- بازخورد سریع. بسیاری از مردم می‌گویند که وقتی TDD انجام می‌دهند، حجم کد من افزایش می‌یابد، بنابراین کارایی توسعه کاهش می‌یابد. با این حال، اگر تست‌های واحد نداشته باشید، باید آن‌ها را به‌صورت دستی تست کنید، زمان زیادی را صرف آماده‌سازی داده‌ها، راه‌اندازی برنامه‌ها، تغییر رابط‌ها و غیره می‌کنید و بازخورد کند است. به‌طور دقیق، بازخورد سریع یک مزیت تست واحد است.
اصول چابک و اسکرام
- مانیفست چابک و دوازده اصل
- ۱۰ قانون اساسی که در اسکرام بیشتر ذکر شده‌اند
- چگونه تیم اسکرام کار می‌کند؟ — راهنمایی مختصر
اسکرام در مقیاس بزرگ
This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.