تغییرات آسان تر و ایمن تر:
تغییر و گسترش برنامه های شما را بسیار آسان تر می کند. مستندات زنده از مشخصات اجرایی با استفاده از اصطلاحاتی که ذینفعان با آن آشنا هستند تولید می شود. این امر درک آنچه که برنامه واقعاً انجام می دهد را برای ذینفعان بسیار آسان تر می کند. مشخصات اجرایی سطح پایین همچنین به عنوان مستندات فنی برای توسعه دهندگان عمل می کند و درک پایه کد موجود و ایجاد تغییرات خود را برای آنها آسان تر می کند. شیوه‌های 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

در پروژه‌های نرم‌افزاری، مدیریت و نگهداری کد منبع یکی از بخش‌های مهم توسعه هستش، ما از ابزارهای متعددی برای این منظور استفاده می‌کنیم، مثه GitLab، Bitbucket و GitHub. این پلتفرم‌ها با فراهم کردن قابلیت همکاری و اشتراک‌گذاری کد، به توسعه‌دهندگان این امکان رو‌ میدن تا به راحتی تغییرات در کد رو مدیریت و دنبال کنه. اما هسته اصلی تمام این ابزارها، Git هستش که در اکثر سازمان‌ها به عنوان استاندارد مدیریت نسخه مورد استفاده قرار می‌گیره (هرچند هنوز روش‌هایی مثل زیپ کردن کد منبع هم در برخی تیم‌ها دیده می‌شود😅)

یکی از مهم‌ترین مواردی که در کار با Git باید رعایت کنیم، نگارش صحیح کامیت‌ هستش(اینکه چه تعداد کامیت زده بشه، مورد اختلاف علما هستش) اما کیفیت و شیوه نوشتن متن کامیت بسیار مهم هستش. یک کامیت خوب باید به گونه‌ای باشه که سایر اعضای تیم بتونن به راحتی متوجه بشن چه تغییری انجام شده و دلیلش چیه. به همین منظور، یک ساختار استاندارد برای نوشتن کامیت‌ پیشنهاد شده که به ما کمک می‌کنه متن‌های کامیت واضح و مفهومی باشند

دسته‌بندی کامیت‌ها
کامیت‌ها رو می‌تونیم به ۹ دسته اصلی تقسیم کرد:

1. feat: افزودن یک ویژگی جدید به کد
2. fix: رفع یک مشکل یا باگ
3. docs: تغییرات مرتبط با مستندات
4. style: تغییرات فرمت‌بندی که تأثیری بر عملکرد یا معنای کد ندارند (مانند فاصله‌گذاری یا استفاده از نقطه‌ویرگول)
5. refactor: تغییرات در ساختار کد بدون تغییر در عملکرد یا رفع باگ
6. perf: تغییراتی که به بهبود عملکرد منجر می‌شوند
7. test: اضافه یا تغییر تست‌های نرم‌افزار
8. chore: تغییرات مرتبط با ابزارها، کتابخانه‌ها یا فرایندهای پشتیبان (مثل تنظیمات build)
9. ci: تغییرات مربوط به سیستم‌های یکپارچه‌سازی مداوم و استقرار

بیایید چندتا مثال بزنیم
۱. افزودن ویژگی‌های جدید
- افزودن یک قابلیت جدید به سیستم ثبت‌نام:

feat(auth): add user registration with email verification

- اضافه کردن پنل ادمین جدید:

feat(admin): add dashboard for managing users and orders

۲. رفع باگ‌ها
- رفع مشکل ورود کاربران:

  fix(auth): fix login issue with incorrect password handling

- رفع خطای محاسبه مالیات در فاکتورها:

fix(invoice): correct tax calculation in final price

۳. مستندسازی
- اضافه کردن راهنمای نصب برای پروژه:

  docs: add installation guide for new developers

- به‌روزرسانی README:

docs: update README with new API endpoints

۴. تغییرات فرمت و سبک کد
- بهبود خوانایی کد:

style: format code according to eslint rules

- استفاده از کاما در جای درست:

style: add missing commas in product component

۵. بازسازی و بازنویسی کد
- بازنویسی یک تابع بزرگ برای ساده‌تر شدن:

refactor(cart): split calculateTotal function into smaller functions

- بهینه‌سازی ساختار پروژه:

refactor(folder-structure): reorganize components and services folders
  

۶. بهبود کارایی
- بهینه‌سازی عملکرد کوئری‌های دیتابیس:

perf(database): optimize query for retrieving large datasets
  

- کاهش زمان بارگذاری صفحات:

perf(page-load): lazy load images to improve page load time
  

۷. تست‌ها
- اضافه کردن تست‌های جدید برای تابع جستجو:

test(search): add unit tests for search functionality
  

- به‌روزرسانی تست‌های قدیمی:

test(cart): update tests to reflect changes in cart logic
  

۸. تغییرات جانبی و ابزارها
- به‌روزرسانی پکیج‌های pip:

chore(deps): update pip packages to latest versions
  

- تنظیم محیط توسعه برای استفاده از Docker:

chore(docker): add Dockerfile for local development
  

۹. یکپارچه‌سازی مداوم (CI)
- افزودن یک اسکریپت CI برای ساخت اتوماتیک پروژه:

ci: add CI script for automated builds
  

- رفع خطای پیکربندی در pipeline:

fix(ci): fix incorrect variable in CI pipeline

نکات مهم:
1. وضوح و شفافیت: پیام کامیت باید به وضوح تغییرات ایجاد شده را بیان کند. از عبارات گنگ یا نامفهوم پرهیز کنید
2. سازگاری با استانداردها: استفاده از کلمات کلیدی مانند feat، fix و... برای دسته‌بندی کامیت‌ها، کمک می‌کند تا تاریخچه تغییرات پروژه ساختاریافته و قابل پیگیری باشد
3. توضیحات کوتاه اما مفید: در پیام کامیت به‌خصوص در خط اول، تلاش کنید مختصر و مفید تغییرات را بیان کنید. در صورت نیاز، توضیحات اضافی می‌تواند در خطوط بعدی پیام کامیت اضافه شود

#git
#gitlab

@code_crafters

در DevOps، مفهوم "ناک" (NOC: Network Operations Center) به تیم یا مرکزی اشاره دارد که وظیفه نظارت، مدیریت و رفع مشکلات زیرساخت‌های شبکه و سرویس‌های یک سازمان را دارد. ناک‌ها به بررسی و پاسخ‌دهی به حوادث و رخدادهای مختلف در سیستم‌ها و شبکه‌ها می‌پردازند تا اطمینان حاصل شود که سرویس‌ها به درستی کار می‌کنند و در صورت بروز هرگونه مشکل، سریعاً حل می‌شوند.

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

1. ناک سطح 1 (L1 یا Frontline Support):
- این تیم اولین نقطه تماس برای مشکلات گزارش‌شده است.
- وظایف اصلی این سطح شامل نظارت بر سیستم‌ها و شبکه، بررسی اولیه مشکلات، و حل مسائل ساده و روزمره است.
- معمولاً مشکلاتی مانند ری‌استارت سرویس‌ها، بررسی لاگ‌های پایه، یا پیکربندی‌های ابتدایی در این سطح حل می‌شوند.
- اگر مشکلی در این سطح حل نشود، به سطح بعدی منتقل می‌شود.

2. ناک سطح 2 (L2 یا Advanced Support):
- این سطح با تخصص بیشتری در ارتباط با مشکلات فنی درگیر است.
- مشکلات پیچیده‌تر که نیاز به تجزیه و تحلیل بیشتر دارند (مانند بررسی عمقی لاگ‌ها، کار با ابزارهای پیشرفته‌تری مانند مانیتورینگ‌های پیچیده‌تر) به این تیم ارجاع داده می‌شود.
-در L2 همچنین ممکن است با مسائل زیرساختی یا تنظیمات شبکه‌ای پیچیده‌تر مانند مشکلات سرورهای مجازی یا کلاسترهای Kubernetes سر و کار داشته باشد.
- در صورت عدم توانایی حل مشکل در این سطح، مشکل به L3 ارجاع می‌شود.

3. ناک سطح 3 (L3 یا Expert Support):
- این تیم از متخصصان بسیار ماهر و دارای تجربه‌های پیشرفته در زمینه دواپس و شبکه تشکیل شده است.
- مشکلاتی که در سطوح پایین‌تر حل نشده‌اند یا نیاز به تغییرات ساختاری، تنظیمات بسیار پیچیده و یا کدنویسی دارند، در این سطح رسیدگی می‌شوند.
- تیم‌های L3 ممکن است با مهندسان نرم‌افزار، توسعه‌دهندگان، یا تیم‌های معماری زیرساخت برای حل مشکلات به صورت مستقیم کار کنند.
- در این سطح، مسائل ممکن است به راهکارهای دائمی، اصلاحات سیستمی یا تغییرات در کد پایه نیاز داشته باشند.

4. ناک سطح 4 (L4 یا External Vendor Support):
- در برخی موارد نادر، مشکلات ممکن است خارج از کنترل داخلی سازمان باشد و نیاز به همکاری با تأمین‌کنندگان خارجی (مانند سرویس‌دهندگان ابری یا تولیدکنندگان نرم‌افزار) داشته باشد.
- این سطح به مواردی می‌پردازد که نیاز به پشتیبانی فنی از سوی شرکت‌های تأمین‌کننده یا شرکای تجاری دارند.

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

#devops
#k8s

@code_crafters

رمان فلسفی سقوط از آلبرکامو

کتاب یکی از شاهکارهای کامو در باب اگزیستانسیالیست و پوچگرایی به سبک کامو هستش(ذکر کنم که کتاب +۱۸ هستش)

موضوعیت کتاب در باب قضاوت کردن و تاثیر قضاوت شدن بر انسان در جامعه هستش و به سبک ادبی بینظیری نوشته شده (جای حرف برای گفتن زیاد داره نگم که اسپویل نشه)

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


در انتهای هر آزادی حکم دادگاهی هست
برای همین است که بار آزادی بر دوش سنگینی میکند
مخصوصا هنگامی که تب داری یا در رنجی یا هیچکس را دوست نداری


#book

@code_crafters

یه سوال ساده از مهندس دوستم پرسیدم و رسیدیم به BCM

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

و این دوتا برگ فقط اسامی و سربرگ موضوعاتی بود که برام تشریح کرد

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


#free

@code_crafters

در این سری پست میخوایم بررسی کنیم api gateway در معماری میکروسرویس چکاری میکند


یک api gateway در واقع یک ابزار مدیریت api هستش که بین یک کلاینت و یک مجموعه از سرویس‌هایی بکند قرار میگیره

در این حالت یک کلاینت یک‌ برنامه است که روی دیوایس‌های کاربران میشنه و سرویس‌های بکند در سرورهای قرار دارند

یک api gateway جزو یک برنامه تحویل است (ترکیبی از سرویس‌هایی که یک برنامه کاربردی در اختیار کاربران قرار میده) و شبیه یک پروکسی معکوس (revers proxy) عمل میکنه که همه درخواست‌ها api رو‌ می‌پذیره و پاسخ میده، تجمیعی از خدمات مختلف مورد نیاز برای برای انجام دادن و بازگشت نتایج مناسب

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


چرا از api gateway استفاده میکنیم؟
بیشتر apiهای سازمانی از طریق api gateway مستقر میشوند. معمولا api gateway هندل میکنه وظایف که استفاده میشوند در سرتاسر یک سیستم از سرویس‌های api، مانند احراز هویت کاربران، محدودیت نرخ و آمار گیری

در حالت ابتدایی یک api سرویس میپذیره یک درخواست بیرونی و برمیگردون یک پاسخ رو، اما حیات اون انقدر ساده نیست، نگرانی‌ در یک مقیاس بزرگ رو‌در نظر بگیرید:

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

شما میخواهید بدونید که مردم چقدر از api شما استفاده میکنن و ابزارهای مانتیورینگ و تحلیل اضافه کنید

اگر یک api تجاری دارید شما میخواهید به یک سیستم صورتحساب متصل شوید

ممکنه شما یک معماری میکروسرویس اتخاذ کرده باشید در این صورت یک درخواست میتواند به تماس ده‌ها برنامه مجزا نیاز داشته باشد

با گذشت زمان شما سرویس‌های جدیدی بالا میاورید و سرویس‌هایی رو بازنشسته میکنید (در مبحث soa اشاره کردیم قبلا) اما مشتریان میخواهند تمامی سرویس‌های شما را در یکجا داشته باشند

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


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

کاری که یک api gateway انجام می‌دهد از یک پیاده سازی تا انجام دیگری متفاوت است. برخی از توابع رایج شامل احرازهویت، مسیردهی، نرخ محدودیت، صورتحساب، مانیتورینگ، تحلیل، سیاست گذاری، هشدارها و امنیت است. api gateway فراهم میکنه این منافع رو:

کاهش تاخیر:

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

مدیریت ترافیک:

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

۱-سیاست‌های محدود کننده نرخ در یک بازه زمانی را مشخص میکند، برای هر کلاینت یا کلید، در برابر بار اضافی محافظت میکنند

۲-قواعد مهار درخواست،قوانین و محدودیت‌هایی را برای تنظیم ترافیک درخواست تعریف می‌کنند مانند: حداکثر نرخ‌های درخواست، مجوزهای انفجاری و سهمیه‌ها

۳-قواعد کنترل همزمانی بالاخص سقف تعداد درخواست‌های از ارتباط همزمان یا درخواست‌های که میتونن بصورت همزمان سرویس‌های بکند هندل کنند

۴-قواعد قطع مدار سلامت مانیتورینگ و پاسخگویی از سرورهای بکند و بلاک موقت یا تغییر مسیر ترافیک موقت، تا از خرابی عادی و ابشاری یا کندی سرویس‌ها جلوگیری کنید

۵-توزیع بار پویا از api gateway، بطور مداوم سلامت سرور را نظارت می‌کند و مسیریابی ترافیک را در زمان واقعی تنظیم می‌کند تا بتوانند افزایش تقاضا رو مدیریت کند، زمان پاسخ را حداقل و توان عملیاتی را به حداکثر برساند

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

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

#api_gateway
#microservice



@code_crafters

هزینه اثربخشی:

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

۱-انعطاف پذیری:  apiهای http که عمومی‌ترند، می‌توانند از هر روش http استفاده کنند. که سادگی و انعطاف پذیری را در توسعه ارائه می‌دهند و کاهش هزینه می‌دهند rest api که به قواعد خاصی تمرکز و پایبند دارند ممکن است به تلاش و تخصص بیشتری نیاز داشته باشند جهت پیاده سازی و هزینه رو افزایش دهند

۲-زیرساخت: به دلیل انعطاف apiهای http ممکن است هزینه زیرساخت کمتری داشته باشند برای res api ها جهت پشتیبانی از از ویژگی‌ها نیاز به اجزای اضافی در زیرساخت یا خدمات اضافی باشد که به‌طور بالقوه باعث افزایش هزینه‌های زیرساخت شود

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

#api_gateway
#microservice


@code_crafters

گمانه زنی: از اهداف تجاری تا اولویت بندی ویژگی‌ها

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

در فضای گمانه‌زنی چه سوالاتی مطرح میکنیم

۱- چگونه بدانیم یک ویژگی خاص به نفع سازمان است؟
۲-آیا نرم افزار تاثیر مثبت و قابل اندازه گیری برای کسب و کار داشته است؟
۳-آیا پروژه ما تفاوتی ایجاد خواهد کرد؟

گاهی اوقات یک برنامه خاص و یا ویژگی خاص به وضوح مزایای تجاری مورد انتظار از آن را ارائه نمیدهد و نباید پیاده سازی شود

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

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

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

فعالیت‌ها شامل مدیران و ذینفعان و تیم‌هاست که ویژگی‌ها را ساخته و ارایه می‌دهند 

ذینفعان کسب و کار، با حمایت اعضای تیم تحویل، مهم ترین مشکلات کسب و کار را که نیاز به حل دارند و فرصت های امیدوارکننده برای کشف را شناسایی و بیان می کنند

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

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

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

یک فرضیه یک عبارت ساده رو توصیف و چگونگی تایید آنرا مطرح می‌کند، یک نمونه ساده به این صورت است

We believe <some capability> will result in <some outcome>
We will know this to be true when <some measurable result is observed>

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

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

#BDD
#behavior_driven_development

@code_crafters

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


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

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

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

FOR <target customer>

WHO <needs something>

THE <product name> is a <product category>

THAT <key benefit, compelling reason to buy>

UNLIKE <primary competitive alternative>

OUR PRODUCT <statement of primary differentiation>

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

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

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

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

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

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

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

اگر نرم افزار اهداف تجاری را براورده کند(حتی اگر دامنه متفاوت از آن‌چیزی باشد که در ابتدا متصور می‌شد) از نظر طراحان کسب و کاری موفقیت آمیز تلقی می‌شود در غیر این صورت یک شکست در نظر گرفته می‌شود حتی اگر الزامات مشتریان را تا حد بالایی برآورده کند

#BDD
#behavior_driven_development

@code_crafters