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

resumeworded

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

چندتا مورد بهتون بگم:
ایمیل شما باید مختص نام شما و شامل اعداد نشده (حتی شده ته فامیلیتون حرف اخر رو دوبار تکرار کنید ولی عدد داخلش نزارید)

از قالب پیش فرض بالا فراتر نرید

اگه گواهینامه و مدرک معتبر دارید اضافه کنید

در بخش سابقه کاریتون قسمت توضیحاتش با درصد و عدد حرف بزنید که کار شما چه مقدار تاثیر مثبت گذاشته

ساختار متنیتون درست و بدون غلط املایی باشه (از gpt کمک بگیرید دوستان حتی اگر هم شد ببرید تا ترجمه کنن براتون)

رنگهای عجیب و غریب نزارید (رزومه شما تابلو فرش نیست)

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

(همین قالب با ساختار متن درست، رزومه خودم رو ساختم و با استانداردهای بین المللی 85 از 100 گرفت )


@code_crafters

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

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

نوع زیردامنه در حال بازی، بر تصمیمات طراحی استراتژیک و تاکتیکی تأثیر می گذارد:

• نحوه طراحی مرزهای زمینه های محدود

• نحوه هماهنگ سازی یکپارچگی بین زمینه ها

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

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

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

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

دامنه پشتیبانی به عمومی
شرکت A برای پشتیبانی از بخش بازاریابی خود متکی به قراردادهایی است که دارد هیچ چیز خاصی وجود ندارد یکسری عملیات‌های CRUD است با OCR در طی گذشت زمان با روی کار آمدن جستجوهای متن کامل و ارائه راهکارهای جدید شرکت تصمیم میگیرد از قراردادهای خود بنفع یک برنامه باز open source کنار بگیرد و آنرا بالا اوردن و جایگزین رویکرد خود کند

دامنه پشتیبانی به اصلی
یک زیر دامنه پشتیبانی می تواند به یک زیر دامنه اصلی نیز تبدیل شود برای مثال: اگر یک شرکت راهی برای بهینه سازی منطق پشتیبانی به گونه ای پیدا کند که یا هزینه ها را کاهش دهد یا سود اضافی ایجاد کند. علامت معمول چنین تحولی، پیچیدگی فزاینده منطق تجاری زیردامنه پشتیبانی کننده است. طبق تعریف، زیر دامنه‌های پشتیبانی ساده هستند و عمدتاً شبیه رابط‌های CRUD یا فرآیندهای ETL هستند. با این حال، اگر منطق تجاری در طول زمان پیچیده تر شود، باید دلیلی برای پیچیدگی اضافی وجود داشته باشد. اگر بر سود شرکت تأثیر نمی گذارد، چرا پیچیده تر می شود؟ این پیچیدگی تصادفی کسب و کار است. از سوی دیگر، اگر سودآوری شرکت را افزایش دهد، نشانه ای از تبدیل شدن یک ساب دامنه پشتیبانی به یک زیر دامنه اصلی است

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

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

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


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

#DDD
#domain_driven_design

@code_crafters

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

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

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

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

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

#DDD
#domain_driven_design

@code_crafters

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

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

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

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

تغییرات سازمانی
نوع دیگری از تغییر که می تواند بر طراحی سیستم تأثیر بگذارد، تغییر در خود سازمان است. می‌توان به الگوهای مختلف ادغام زمینه های محدود نگاه کرد: مشارکت، هسته مشترک، سازگاری، لایه ضد فساد، سرویس میزبان باز و راه های جداگانه

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

مشارکت با مشتری-تامین کننده:
این الگو فرض می کند که ارتباط و همکاری قوی بین تیم ها وجود دارد که با گذشت زمان، این ممکن است از بین برود. برای مثال: زمانی که کار بر روی یکی از بافت‌های محدود به یک مرکز توسعه دور منتقل می شود بر ارتباطات تیم‌ها تأثیر منفی می‌گذارد و ممکن است منطقی باشد که از الگوی مشارکت به سمت رابطه مشتری-تامین کننده حرکت کنیم.

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

#DDD
#domain_driven_design

@code_crafters

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

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

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

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


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


#daily

@code_crafters

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

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

روند استخدامی در شرکت‌های مطرح چجوریه؟؟

۱ـ بخش فنی اعلام به نیاز نیرو با تخصص‌های مدنظر خود میکنه

۲ـ فراخوان استخدامی در کانال‌ها و رسانه‌ها پخش میشه

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

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

۵- افراد دارای صلاحیت، در مرحله قبل به مصاحبه فنی رفته و تخصص آنها سنجیده خواهد شد به افراد قبول شده یک تسک داده خواهد شد و از بین پاسخ دهندگان با سنجش تسک بصورت حضوری گزینه انتخابی جهت استخدام خواهد رفت


آزمونهای هوش شامل:

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

آزمونها بصورت سیستمی و حداکثر تایم ان دو ساعت است (برخی شرکت‌ها ممکن است آزمون بیشتر یا کمتر داشته باشند)

در مصاحبه hr دو‌ دسته سوال از شما پرسیده خواهد شد:
یک دسته سوالات عمومی جهت بازشناسی رفتاری شما
یک دسته سوالات که متناسب با حیطه کار و نیاز سازمان است

تفکیک این دو‌ دسته سوال از هم امکان پذیر نیست براتون

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

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


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

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


#free

@code_craftets

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

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

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

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

زیردامنه ها

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

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

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

#DDD
#domain_driven_design

@code_crafters

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

مصالح (تجمیع):
اصل راهنمای زیر برای طراحی مرزهای مصالح:

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

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

#DDD
#domain_driven_design

@code_crafters

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

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

با سرچ‌ کردن تو گوگل میشه پیدا کرد این موارد رو

اما وب سایت زیر اومده تا جایی که تونسته برای اکثر ابزارهای پر استفاده دفتر تقلب‌ نوشته و برامون گذاشته

https://quickref.me/


#free

@code_craftets

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