معرفی توسعه رفتار محور

توسعه رفتار محور مجموعه‌ای از شیوه‌های مهندسی نرم افزار است که در ساخت و ارائه سریعتر، با ارزش تر و با کیفیت تر نرم افزار طراحی شده است، از شیوه‌های چابک و ناب مانند TDD و DDD بهره میبرد و از همه مهمتر با یک زبان مشترک ساده بین توسعه دهندگان ،ذینفعان و تحلیلگران کسب و کار جهت ارتباط باهمدیگر ارائه میدهد

در ابتدای مسیر BDD یک رویکرد ساده‌تر برای یادگیری TDD بود (پس اگه جایی خوندین که BDD همان TDD است تعجب نکنید این رویکرد اولیه آن بود)

در واقع TDD یک رویکرد مبتنی بر تست‌های واحد unit test برای تعیین و طراحی و ازمایش کدهای برنامه است

متخصصان TDD در ابتدا یک تست شکست خورده مینویسند که توصیفگر ویژگی جدید است و سپس کدهای زیادی مینویسند تا تست با موفقیت اجرا شود و سپس با بازنگری کد خود آن را بهبود داده تا جایی که مطمئن شوند که نگهداری کد ساده است، این رویکرد تا میزان قابل توجهی خطاهای سیستم را کاهش میدهد

با وجود مزایای TDD بسیاری از تیم‌ها با مشکل مواجه هستند اینکه از کجا شروع کنند و چه تست‌هایی باید در ابتدا نوشته شود و از کجا شروع کنند، TDD یک مشکل اساسی دارد اینکه ممکن است توسعه دهندگان را چنان درگیر جزئیات کند که از اهداف اصلی کسب و کار دور شده و آن را فراموش کنند بعدها تیم ممکن است متوجه شود که نگهداری تعداد زیادی تست واحد کار بسیار مشکل سازی باشد

بسیاری از تست‌های سنتی یا حتی نوشته شده با رویکرد TDD با بخش خاصی از کدها ارتباط دارند و فراموش میکنند که باید با قسمت تجاری هماهنگ شوند

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

جناب نورث (مخترع رویکرد BDD) مشاهده کرد با افزودن کلمه should به ابتدای نام تست‌های واحد میتوان تست‌های واحد با معنی داری نوشت که بیانگر این هستند که آن تست باید چکاری کند و بدین شکل شما متوجه میشوید که کلاس باید چکاری انجام دهد بجای اینکه چه روش یا عملکردی در حال آزمایش است اینگونه راحتتر میتوانید تلاش‌های خود را بر روی نیازهای اساسی کسب و کار متمرکز کنید و تست‌های بیشتر و بهتری نوشته شود که کیفیت کار را بالا ببرد، تست‌هایی که بدین شکل نوشته میشود بیشتر شبیه مشخصات است تا تست‌های واحد و بر روی رفتار برنامه تمرکز میکنند و از تست‌ها برای تایید و بیان ان رفتار استفاده میکنند و نگهداری آنها بدلیل واضح بودن هدف آنها بسیار آسانتر است (جناب نورث بعد از مشاهده تاثیر آن دیگر به آن TDD نگفت و امروزه شیوه‌های کاملا متمایزی از همدیگر هستند)

هدف مخترعان BDD ایجاد یک زبان فراگیر ساده که قابل درک برای تحلیلگران کسب و کار باشد که بتوانند از آن برای تعریف نیازمندی‌های خود استفاده کنند، به مثال زیر دقت کنید

Given a customer has a current account 

When the customer transfers funds from this account to an overseas account 

Then the funds should be deposited in the overseas account 

And the transaction fee should be deducted from the current account

یک صاحب کسب و کار می تواند به راحتی سناریویی را که به این شکل نوشته شده درک کند. اهداف روشن و عینی را برای هر داستان از نظر اینکه چه چیزی باید توسعه یابد و چه چیزی باید آزمایش شود ارائه می دهد و امروز به شکل نمادین با عنوان Gherking تبدیل شد

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


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



#BDD
#behavior_driven_design

@code_crafters

اکتشاف قابلیت‌ها و ویژگی‌ها (spectulat):
در رویکردهای سنتی تحلیلگر کسب و کار یک لیست از ویژگی‌های جهت پیاده سازی ارائه میداد، اما در رویکردهای اجایل و تیم BDD تیم توسعه نقش فعالتری دارد و با ایجاد یک نقشه و طرح چهار سوال بنیادی جهت کشف ویژگی‌ها اقدام می‌کند

۱- ما چرا اینکار رو انجام میدیم (هدف بیزنس چیست why)

۲ـرفتار چه کسانی را باید تغییر دهیم (نقش‌های کلیدی چه کسانی هستند who)

۳ـچگونه میتوانیم این رفتارها رو تغییر بدهیم (چه رفتاری در آنها به ما در دسترسی به اهداف تجاری کمک میکند how)

۴ـچه ویژگی‌هایی میتواند در تغییر این رفتار به ما کمک کند(what)

تصویر اول در کامنت‌ها

ما به همراه بخش تجاری کارگاه نقشه برداری رو راه اندازی میکنیم و این به درک عمیق ما از پروژه کمک خواهد کرد، اگر چه رفتار نهایی کاربران و ویژگی‌های آنها تاثیر چشمگیری بر روی آن خواهد داشت

در نهایت ما بر روی دو قابلیت کلیدی توافق میکنند، توانایی برنامه ریزی راحت‌تر سفرهای روزانه و توانایی مقابله با توقف‌های غیر منتظره و در نهایت به خروجی سمت راست نقشه what میرسند

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

شما می‌توانید با جابجا کردن سه مقدار مطرح شده در بالا (انتخاب ارزش تجاری-چه کشی نیاز به ان دارد-چه چیزی میتواند از آن پشتیبانی کند) داستان‌ها را به شکل‌های مختلف نوشت که به تیم توسعه در درک عمیق مسئله کمک میکند و ذینفعان با خواندن آن میدانند در انتظار چه چیزی خواهند بود

توصیف کردن، کشف ویژگی‌های جدید (illustrate):
اکنون تیم ما یک لیست از ویژگی‌ها جهت توسعه دارد و درک درستی از آنچه باید انجام دهد و بهترین راه کشف آن پرسش راجب ان با مثال است

کشف ویژگی:
زمانیکه از کاربران یک ویژگی جدید را میشنوید سریع اقدام به ساخت یک مدل ذهنی میکنید که این مدل چه مشکلی را خل میکند، این رویکرد موجب ساخت ویژگی‌هایی میشود که با نرخ خطای بالایی همراه است، بهترین رویکرد این است که از ذینفعان بخواهید آنچه را که میخواهند با مثال مطرح کنند. در طی گفتگو با مثال‌ها شما با موارد مختلفی روبرو می‌شوید قوانین تجاری، سوالات بی پاسخ، نمونه‌ها و ضد نمونه‌ها، یکی از راه‌های بصری کردن این موضوع استفاده از تابلو با کارتهای رنگی است که هر رنگ یک موضوع از یه موضوع بالا رو نمایش می‌دهد که به این تابلو example mapping (تصویر دوم در کامنت) گفته می‌شود رویکرد دیگر نقشه برداری است تیم‌های BDD از این دو رویکرد استفاده می‌کنند تا مکالمات را هدایت و متمرکز کنند و مثالهای کلیدی را ثبت کنند

برش ویژگی در user stiry:
اغلب این مکالمات عدم قطعیت و پیچیدگی را به ما نسان می‌دهد، در اسکرام داستان کاربر باید بقدری کوچک باشد که در یک sprint جای داده شود، اگر ساخت یک ویژگی بیش از یک اسپرینت طول میکشد باید آنرا به چندین داستان کاربر تقسیم کنید که بصورت تدریجی در چند اسپرینت تحویل داد، این به نوبه خود بشدت موجب کاهش خطا میشود

اسپرینت یک دوره زمانی معمولا بین دو تا چهار هفته کاری در اسکرام برای تیم توسعه دهنده محصول است

فرموله کردن از نمونه ها تا مشخصات اجرایی (formulate):
ما اکنون مجموعه‌ای از داستان‌ها و نمونه‌هایی داریم که میخواهند پیاده سازی شود، با تبدیل آن به قالب مشخصات اجرایی (given, when, then) و خودکار سازی آن منحر به کشف کدهایی می‌شود که باید نوشته شود و این مسخصات اجرایی تبدیل به یک ابزار کزارش دهی و مستندسازی می‌شود و بعنوان معیارهای پذیرش از آن استفاده کرد

معیار پذیرش چیزیست که ذینفعان و QA را راضی میکند که برنامه دقیقا همان چیزیست که باید انجام دهد

نمونه یک مشخصه اجرایی:
Given <a context>
When <something happens>
Then <you expect some outcome>

خودکار از مشخصات اجرایی تا تست های خودکار (automate):
ابزارهای تخصصی BDD زیادی وجود دارد که می توانید برای خودکارسازی معیارهای پذیرش خود از آنها استفاده کنید. انتخاب های محبوب شامل ابزارهایی مانند Cucumber (برای جاوا، جاوا اسکریپت، روبی و بسیاری از زبان های دیگر)، SpecFlow (برای دات نت) و Behave (برای پایتون) است. اگرچه این ابزارها ضروری نیستند، اما بیان تست های خودکار را به شکل ساختار یافته ای شبیه به داده می‌کنند


#BDD
#behavior_driven_design


@code_crafters