Event storming

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

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

در دنیای DDD ما نیاز به رویکردی جدید و مدرنتر داشتیم که بتوان موارد زیر رو رفع کرد:
۱- فضای مسئله و راه حل‌ها
۲- شناخت و یافتن BC یا همان مرزهای محدود
۳ـ جلسات منفعل با BR یا همان متخصصان کسب و کار
۴- فرار از مدلسازی‌های نامناسب
۵- تهیه کردن لیست نیازمندی ها
۶- دست یافتن سریع به یک زبان مشترک


همیشه دیدگاه اشتباهی راجب DDD وجود دارد اینکه این رویکرد فقط برای سیستم‌هایی جوابگو هستش که در ابتدای راه و ساختن قراردارد اما این یک اشتباه هست اتفاقا این رویکرد برای سیستم‌های قهوه‌ای (امیدوارم منظور نویسنده از قهوه‌ای را گرفته باشید) بهتر پاسخ میدهد

در سال ۲۰۱۳ یک روش خلاقانه با عنوان event storming معرفی شد که پایان هرآنچه که در بالاتر مطرح کردیم رو ختم کرد

این رویکرد یک طوفان فکری را بپا میکرد که به سرعت موجب فرآیندسازی کسب و کار میشد و مشکل UML را نیز با خود نداشت


با توجه به اینکه مطالب مربوط به event storming زیاد و گوناگون است لذا این بخش از کتاب رو بهتر هستش خودتون با سرچ کردن و خوندن مقالات متنوع یاد بگیرید

#DDD
#domain_driven_design

@code_crafters

یه نگاه به اینجا بندازید خالی از لطف نیست ببینید موزیلا چی برامون درست کرده


developer.mozilla.org


#free

@code_crafters

وضعیت شرکت وقتی پروژه رو بدون تست دیپلوی میکنی

#fun

@code_crafters

از جان مهندسین نرم افزار چه میخواهند؟؟


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

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

من در ذهن خودم بدین شکل می‌اندیشم: مهندسی نرم افزار کلاسیک و مهندسی نرم افزار مدرن مبتنی بر اجایل

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

در این سری از پست‌ها میخواهیم راجب BDD (Behavior-Driven Development) توسعه مبتنی بر رفتار صحبت کنیم که از بالاترین سطح تا پایین‌ترین سطح کدزنی را تحت تاثیر خواهد گذاشت و منجر به ایجاد یک نرم افزار مناسب میشود و علاوه بر آن به شما کمک خواهد کرد تا به یکی از بزرگترین چالش‌های موجود که زمان تحویل بموقع نرم افزار است فائق آیید


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


شما با ردگیری دو هشتک زیر در کانال ازین به بعد میتوانید به سلسله پست‌ها مربوط به توسعه رفتار محور دست پیدا کنید

#BDD
#behavior_driven_development

@code_crafters

ساخت نرم افزاری که تفاوت ایجاد کند

ما در تلاشیم نرم افزاری بسازیم که به خوبی کار کند و تغییر و نگهداری آن آسان باشد، اما مهمتر ساخت نرم افزاریست که ارزش واقعی را به کاربران بدهد

ما میخواهیم نرم افزاری رو بخوبی بسازیم اما باید نرم افزاری بسازیم که ارزش ساختن داشته باشد

بیایید با یک مثال پیش برویم:
رییس یک سازمان میخواهد به نرم افزار حساب داری خود یک ویژگی را اضافه کند، او مراحل زیر را در پی خواهد گرفت

۱- او به تحلیلگر کسب و کار خود میگوید چه ویژگی را لازم دارد 

۲- تحلیلگر نیازمندی‌های ویژگی جدید را بر اساس بیانات رییس برای توسعه دهنده نوشته و آنرا مستند میکند

۳- توسعه دهنده مستندات را گرفته و آنرا تبدیل به کد میکند

۴ـ تستر مستندات را خوانده و آزمایشات خود را جهت تایید آنچه در سند نوشته شده است را انجام میدهد

۵- خروجی کار همراه کدها توسط توسعه دهنده مستند میشود

در طی فرآیند بالا امکان گم شدن و یا نادیده گرفته شدن الزامات اولیه رییس شرکت به تحلیلگر کسب و کار وجود دارد

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

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

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

۳- توسعه دهندگان و تسترها مشخصات اجرایی را به آزمونهای پذیرش خودکار تبدیل میکنند تست‌ها به هدایت فرآیند توسعه و تعیین زمان اتمام یک ویژگی کمک میکنند

۴- هنگامی که ازمونهای خودکار به درستی اجرا شوند تیم‌شواهد مشخصی دارد که آنچه در مرحله ۲ ذکر شده، صورت گرفته است 

۵ـ تست‌های خودکار بعنوان مستندات محصول عمل می‌کنند و نمونه‌های دقیق و به روزی از نحوه عملکرد سیستم ارائه می‌دهند

نرم‌افزارها بابت مسائل زیادی شکست میخورن اما عمده اونها به دو دلیل است

۱- عدم ساختن نرم افزار درست (انواع بگ‌ها و مشکلات)
۲- عدم ساختن درست نرم افزار (غیر قابل استفاده برای کاربران)

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

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

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

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


#BDD
#behavior_driven_development


@code_crafters

طبق تحقیقات ۴۵ درصد از ویژگی‌های توسعه داده شده در محصولات هیچوقت استفاده نشدند، در انتقال پروژه‌های قدیمی به زیرساخت‌های مدرن هم این مسیله بوفور دیده میشود که بسیاری از بخش‌ها نیاز به بروز رسانی دارند و یا دیگر ضروری نیستند، اگر شما درک صحیحی از نیاز مشتریان برای رسیدن به اهدافشان نداشته باشید(حتی در سیستم‌های قابل پیش بینی) هرچند بدرستی هم کدزنی شده باشند راه بجایی نخواهد برد

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

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


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

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

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

یک ضرب‌المثل سوئیسی میگه

وقتی زمین با نقشه مخالف است، به زمین اعتماد کنید

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

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


#BDD
#behavior_driven_development


@code_crafters

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

توسعه رفتار محور مجموعه‌ای از شیوه‌های مهندسی نرم افزار است که در ساخت و ارائه سریعتر، با ارزش تر و با کیفیت تر نرم افزار طراحی شده است، از شیوه‌های چابک و ناب مانند 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

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

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

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

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

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

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

مثال‌ها نقش اصلی را در BDD بازی میکنند و به همه کمک می‌کنند تا نیازمندی‌ها را واضحتر درک کنند

اصول و شیوه‌های BDD با استفاده از ابزارهای اختصاصی BDD مانند Cucumber و specflow خودکار می‌شوند. به این ترتیب هم نیازها مستند میشود هم تست‌های خودکار اجرا میشود

نیازهای gherking به زبان انگلیسی ساده، اما با ساختاری خاص بیان میشود، هر سناریو از تعدادی مرحله تشکیل شده است، جایی که هر مرحله با یکی از تعداد کمی از کلمات کلیدی (Given, When, Then, And, But) شروع میشود

ترتیب طبیعی بدین شکل است:
Given ... When ... Then

Given (پیش شرط‌های سناریو را شرح میدهد و محیط آزمون را آماده میکند)

When (عمل تحت آزمایش را توصیف میکند)

Then (نتایج مورد انظار را شرح میدهد)

از and و but برای پیوستن بین چند مرحله بالا استفاده می‌شود

Feature: Transferring money between accounts
   In order to manage my money
   As a bank client  I want to transfer
   Scenario: Transferring money ...
       Given Tess has a current account with $1000  
       And a savings account with $2000.00  
       When she transfers $500 from current to savings  
       Then she should have $500 in her current account  
       And she should have $2500 in her savings account

#BDD
#behavior_driven_development


@code_crafters

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

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

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

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

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

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

فراموش نکنید مستندات و مشخصه‌ها در کنار سایر موضوعات موجود در پروژه، مانند: معماری و عملکردی تاثیر چشمگیری خواهد داشت و تنهایی ارزش چندانی خلق نمیکنند

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

کاهش هزینه:
با حذف ویژگی‌های غیر تجاری و غیر کاربری موجب افزایش تمرکز بر روی کد و ویژگی‌های تجاری خواهد شد که در نهایت موجب افزایش کیفیت کد (ساخت صحیح نرم افزار) و کاهش باگ و هزینه نگهداری و دیباگ میشود

#BDD
#behavior_driven_development


@code_crafters

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

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

چالش‌ها و مشکلات BDD:
به تعامل تجاری و همکاری بالایی نیاز دارد:
در واقع، مکالمات باعث ایجاد درک تیم از الزامات و نحوه ارائه ارزش تجاری بر اساس الزامات می شود. اگر ذینفعان مایل نباشند یا نتوانند در گفتگوها و همکاری شرکت کنند، یا قبل از دادن هر بازخوردی تا پایان پروژه منتظر بمانند، استخراج کامل مزایای BDD دشوار خواهد بود

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

در یک silo به خوبی کار نمی کند:
در بسیاری از سازمان های بزرگتر، رویکرد توسعه siloed هنوز معمول است. مشخصات دقیق توسط تحلیلگران تجاری نوشته شده و سپس به تیم های توسعه که اغلب خارج از سایت یا خارج از کشور هستند، تحویل داده می شود. به طور مشابه، آزمایش به یک تیم QA کاملاً مجزا واگذار می شود. در سازمان‌هایی مانند این، هنوز هم می‌توان BDD را در سطح کدگذاری تمرین کرد اما عدم تعامل بین تیم‌های تحلیلگر کسب‌وکار و توسعه‌دهندگان، استفاده از شیوه‌های BDD را برای شفاف‌سازی و درک تدریجی نیازمندی‌های واقعی دشوارتر می‌کند. رویکرد siloed می‌تواند چالش برانگیز باشند. اگر تیم QA برای مداخله تا پایان پروژه صبر کند، یا این کار را به صورت مجزا انجام دهد، شانس خود را برای کمک به الزامات زودتر از دست خواهند داد، که منجر به هدر رفتن تلاش‌های صرف شده برای رفع مشکلاتی می‌شود که می‌توانستند زودتر پیدا شده و راحتتر رفع شود اگر تیم QA در تعریف و احتمالاً خودکارسازی سناریوها مشارکت داشته باشد، خودکارسازی معیارهای پذیرش نیز بسیار سودمندتر است

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


#BDD
#behavior_driven_development


@code_crafters

تور گردباد توسعه رفتار محور

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

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

۱ـ حدس و گمان speculate:
در این مرحله تیم بابت شناخت و درک اهداف تجاری سطح بالا و شناسایی ویژگی‌هایی که به ما در شناخت آن کمک میکند وارد گفتگو با افراد افراد کسب و کار میشود

۲- توصیف کردن illustrate:
در این مرحله افراد تیم دانش عمیقی مخصوص به آن ویژگی‌ می‌سازند و این از طریق مکالمات در مورد بتن مثال‌های از قواعد تجاری و داستان کاربر (user story) می‌باشد

داستان کاربر یک ابزار از متدلوژی چابک agile است (چیزی که کاربر نیاز دارد در پروژه باشد-ویژگی را از دیدگاه کاربر نظاره گر باشد)

۳-فرموله کردن Formulate:
جایی که اعضای تیم نمونه های کلیدی را به مشخصات اجرایی (در بخش قبلی به اهمیت آن و نحوه مصرف به تفصیل سخن گفتیم) تبدیل می کنند، با استفاده از نمادی که هم برای افراد تجاری قابل خواندن است و هم می تواند به عنوان آزمایش خودکار اجرا شود

۴-خودکار کردن automate:
جایی که توسعه‌دهندگان و آزمایش‌کنندگان این مشخصات اجرایی را به تست‌های پذیرش خودکار تبدیل می‌کنند و از این تست‌های پذیرش خودکار برای هدایت فرآیند توسعه استفاده می‌کنند

۵-نشان دادن demonstrate:
جایی که گذراندن آزمون‌های پذیرش خودکار به عنوان مدرکی مبنی بر اینکه یک ویژگی به درستی پیاده‌سازی شده است و به عنوان مستنداتی که ویژگی‌های فعلی و نحوه کار آنها را نشان می‌دهد عمل می‌کند. اینجاست که تیم تأیید می‌کند که یک ویژگی آنچه از آن خواسته شده است را انجام می‌دهد

۶-اعتبارسنجی validate:
جایی که تیم و کسب‌وکار می‌بینند که ویژگی‌ها در دنیای واقعی چگونه عمل می‌کنند و آیا ارزش تجاری را که وعده داده بودند ارائه می‌دهند یا خیر

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

بیایید با یک مثال عملی آنچه در بالا بیان شد را یاد بگیریم

۱-گمانه زنی-شناسایی ارزش و مقادیر کسب و کار:
تصور کنید در یک شرکت از ما خواسته شده تا یک تیم کوچک رو مدیریت کنیم که بر روی یک شبکه ریلی(قطار) بزرگ برنامه‌ای نوشته بشه که ساعات حرکت، توقف، دیرکرد و ... رو شامل بشه

شناسایی اهداف تجاری:
آیا اعضای تیم می توانند اهداف تجاری را بیان کنند؟ آیا می توانند در چند جمله ساده بیان کنند که چه مشکل تجاری را حل می کنند؟
یک تیم با درک عمیقی از اهداف مشترک می‌تواند در برابر تغییرات و موانع غیرمنتظره بشکل موثرتری واکنش نشان دهد حتی اگر به دلایل فنی نتواند راهکاری را پیاده سازی کند میتوانند مواردی را جایگزین کنند که به همان اهداف تجاری برسد، وقتی یک تیم خودش رو با هدف بزرگتری تصور کند در واقع خودش رو جز یک کل بالاتر می‌داند و این موجب می‌شود که بهتر عمل کند، در وهله اول ما باید مطمین شویم که همه اعضای تیم درک درستی از اهداف پروژه دارند و در جلسات همراه با اسپانسر در خصوص این اهداف بصورت کامل و شفاف صحبت کنند به گفته اسپانسر «هدف اصلی ما این است بستری فراهم گردد که مسافران بتوانند سفر خود را بصورت آنلاین برنامه ریزی کنند»
در بخشی از بیانیه مطرح شده که وظیفه جذابتر و کارآمدتر کردن حمل و نقل عمومی برای مسافران است، مسافران زمان انتظار را دوست ندارند و میخواهند این زمان را کمتر کنند همچنین آنها در دانستن اینکه سوار کدام قطار شوند مشکل دارند.
اما هدفی که بالاتر مطرح شد شامل هیچ یک از این موارد نیست لذا طی گفتگو با اسپانسر هدف رو به این شکل تغییر دادیم «این برنامه به کاهش ۱۰ درصدی متوسط زمان سفر برای مسافران عادی در عرض یکسال کمک میکند و کمک میکند سفرهای خود را موثرتر برنامه ریزی کند» حال یکمقدار قابل اندازه گیری داریم که توسط گرفتن میانگین زمان ورود و خروج مسافران از ریل قطار قابل اندازه گیری است و این کمک میکند تا پی ببریم آیا برنامه به وعده خود عمل میکند یا خیر.
اکنون برای ادامه کار میتوانیم با تحلیلگران کسب و کار وارد گفتگو شویم


#BDD
#behavior_driven_development


@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

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

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

#BDD
#behavior_driven_development


@code_crafters

ترانه ی زیبای فرانسوی به نام برف می بارد
اثر شکوهمند

سالواتور آدامو

#free

@code_crafters

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

roadmap.sh/backend


#free

@code_crafters

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


https://survey.alchemer.com/s3/8009809/python-developers-survey-2024