بیایید پول بزاریم یه کمپر بخرم
یکی دیگه از آرزوهام براورده بشه

یکی از موارد مهم در خصوص یادگیری یک زبان جدید، املا نوشتن هستش، که بهتون کمک میکنه تو شنوایی و نوشتن و جمله سازی و ....

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

https://dailydictation.com/

فکر کنم با این دوتا پست اخیر لو دادم که برنامم چیه😅😅😅😅

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

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

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

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

در موارد نادر، ریشه‌ی باگ می‌تواند به تخصیص نادرست تسک (عدم تناسب سطح تسک با توان نیروی انسانی) برگردد.

سطح‌بندی باگ‌ها
باگ‌ها در سطوح مختلفی قرار می‌گیرند:
در سطوح Critical / Blocker باگ‌های واقعاً بحرانی و متوقف‌کننده

سایر موارد معمولاً در دسته‌ی Issue قرار می‌گیرند


نکته‌ی مهم اینجاست:
همه‌ی باگ‌ها لزوماً بد یا مخرب نیستند.

بدهی فنی، تهدید یا فرصت؟
در واقع Issueها و باگ‌های غیر بحرانی تا یک سطح مشخص، مصداقی از چیزی هستند که به آن می‌گوییم:

Technical Debt (بدهی فنی)

البته بدهی فنی فقط باگ نیست و می‌تواند شامل:
* طراحی غیر بهینه
* تصمیم‌های کوتاه‌مدت معماری
* تست‌نویسی ناکافی
* پیچیدگی‌های انباشته‌شده‌ی سیستم باشد.

اما بخشی از بدهی فنی می‌تواند خودش را به‌صورت باگ یا Issue نشان دهد.

بدهی فنی تا سطح متوسط:
باعث افزایش دانسته‌ی سازمانی (افزایش دانش فنی) می‌شود
تجربه‌ی تیم را بالا می‌برد
و یکی از نشانه‌های بلوغ فنی سازمان محسوب می‌شود
(این مفهوم به‌صورت انتزاعی با شاخص‌هایی مثل TRL / TRA هم‌راستاست)


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

زمان مورد نیاز (مقدار روز یا ساعت) برای رفع باگ و Issue تقسیم بر زمان کل توسعه (مقدار روز یا ساعت) ضرب در صد (که درصد به دست بیاریم)

حالا خروجی بالا؛
کمتر از ۱۵ درصد موجب دانسته (افزایش دانش فنی) میشه

تا ۳۰ درصد یعنی پروژه در لبه بحران هستش

و بیشتر از ۳۰ درصد نیاز به بازنگری جدی در فرآیند توسعه (اسکرام یا معادل آن) و تصمیم مدیریتی وجود دارد
(ادامه با هزینه، یا توقف/بازطراحی پروژه)


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

(اینم اضافه کنم نیروی بیش از حد شلوغ هم ضد معیار TRA/TRL هستش یعنی سازمان یک ایرادی داره)

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

فلوچارت و تحلیل جریان کار، در بسیاری از موارد حتی از تست‌نویسی مؤثرتر است

اکثر باگ‌ها ناشی از:
- نبود تصویر ذهنی شفاف
- مشخص نبودن مسیرها و حالت‌ها
- بی‌دقتی در سناریوها
هستند
+ نه کمبود دانش فنی

قبل از کدنویسی:
- فلوچارت بکشید
- سناریوها را مرور کنید
- و Design Review انجام دهید
+سپس کدنویسی و تست را شروع کنید


با تشکر از هوش مصنوعی که متنم رو‌ مرتب کرد (باورکنید فقط مرتبش کرد اه)

@code_crafters

یه روش بهتون بگم جهت رفع باگ با هوش مصنوعی

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

من چکار میکنم
اول از هر چیزی توی گوگل خودم سرچ میزنم (توی stack overflow, issue github) یا هر جای دیگه

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

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

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

یه کلیپ جالب دیدم امروز
یک مدیر آمریکایی با کارمندش در یک جلسه همگانی

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

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


این نشون دهنده یک مدیر باسواد، سالم و درست هستش

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

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

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

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

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

از نگاه اطرافیانش امروز اون یک آدم معمولیه و من میدونم که چه ذکاوت و هوش بالایی داره

📌 یادگیری کتابخانه Playwright واقعاً ارزشمنده

چه برای خزش وب (Web Crawling) و چه برای تست سامانه‌ها، Playwright یکی از ابزارهای بسیار قدرتمنده

دست شما رو کاملاً باز می‌ذاره و تقریباً هر چیزی که برای کار حرفه‌ای نیاز دارید رو فراهم کرده.
یکی از قابلیت‌های جذابش حالت Headless هست:

* اگر headless=false باشه، کد دقیقاً روی دسکتاپ اجرا می‌شه و توسعه و دیباگ رو خیلی راحت می‌کنه
* اگر headless=true باشه، آماده‌ی اجرا روی سرور می‌شه (ایده‌آل برای استفاده داخل CI/CD)

🧠 مفهوم Context رو به‌خوبی پیاده‌سازی کرده
(تصور کنید یک پروفایل جدید در مرورگر باز می‌کنید که می‌تونه چندین تب همزمان داشته باشه)

📸 امکان Screenshot و حتی Record کردن ویدیو از صفحه رو می‌ده
چه در حالت headless و چه غیر headless
(خیلی کاربردی برای مستندسازی، داکیومنت فنی و آموزش کار با سامانه‌ها)

🔌 کار با API رو هم به‌صورت native در اختیارتون می‌ذاره
مدیریت کوکی، سشن و احراز هویت در طول اجرای تست‌ها رو خودش کاملاً هندل می‌کنه

📦 با انواع فرمت‌های داده سازگاره و خیلی راحت می‌تونید با داده‌های مختلف کار کنید

🔥 اما یه نکته‌ی خیلی جذاب در تست سامانه‌ها:

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

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

@code_crafters

خب بیایم یکم راجب تست نویسی بگیم

توسعه تست محور TDD کم و بیش همه باهاش آشنا هستیم، تو حالت کلاسیکش با تست‌ها رفتار سیستم رو مشخص میکردیم و بعد کد میزدیم، بابت همین تو کتاب معروفش اگه بریم بیشترین تمرکز روی نوشتن تست‌های e2e هستش (تستی که رفتار کاربر رو شبیه سازی میکرد) و تا حدودی روی integration test و اندک روی unit test، بابت همین خیلی‌ها رویکرد TDD (کلاسیک) رو با BDD یکی میدونن و اشتباه چون تمرکز هردو روی رفتار (behavior) هستش

اما TDD دستخوش تغییرات شدیدی شد چون ضعف داشت روی سیستم‌های بزرگ و یک بازبینی راجبش انجام دادیم

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

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

چه اتفاقی افتاد اساسا رویکرد کلاسیک TDD اینجوری بود که
E2E -> unit test -> integration test

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

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

خب حالا چرا این رویکرد جدید
unit test -> integration test -> E2E

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

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

توسعه دهنده ابتدا تست‌های واحد ویو رو مینویسه و ویو رو پاس میکنه، تست‌های لایه سرویس رو مینویسه و پاس میکنه، آیتم‌های واحد تموم شد

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

بعد اینکه واحدها تموم شد
توسعه دهنده میاد و ویو و سرویس رو به هم دیگه می‌چسبوند و براشون تست یکپارچه (integration) می‌نویسه، که بیشتر بابت نگهداری و چک کردن در تغییرات بعدی جهت اطمینان از درستی عملکرد بود، در انتها تستر میاد و با نگاه ذی‌نفعی e2e رو مینویسه و تمام

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

حالا شاید براتون سوال شده، مزیت دیگه این رویکرد مدرن برای توسعه چی هستش؟؟؟

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

چندتا سوال از خودتون بپرسید

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

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


#test
#tdd
#ddd
#bdd

@code_crafters

چرا pytest ارزش یادگیری داره؟؟؟

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

اول اینکه خیلی ساده هستش و با اکو سیستم پایتون بشدت دوست هستش شما با assert و مقادیر قابل چک (== != > < is in و ...) درگیرید

یافتن تست‌ها با test_*.py / *_tets.py بصورت درونی داره

امکان group test در یک کلاس رو بهتون میده

امکان subtest رو بهتون میده کافیه از :: استفاده کنید برای مسیر به تابع تستتون (test_view.py::test_login/.)


بریم یه نگاه تخصصی تر بهش بندازیم با ویژگی‌های بیشترش، من ترتیب بگم تا یک سناریوی واقعی بهتون هم بدم

یک فایل conftest.py میتونید بسازید که کانفیگ های مدنظر رو اعمال کنید خصوصیت این فایل این هستش در هر جای مسیر تست بزارید از اون مسیر و به دایرکتوری‌های داخلی اعمال میشه

بهتون fixture میده که امکان تعریف توی scope های مختلف رو میده (module, function, session, class) و جالبترین قسمت بصورت داینامیک بودنش هست، این تو دنیای واقعی کاربرد داره که fixture رو برای حالت ci/cd بزارید رو session که تست‌ها موجب کند شدن اوتومیشن نشند و تو حالت توسعه بزارید روی function تا همه چی رو دقیق مشاهده کنید، اگه یک fixture دارید که تو تست‌های مختلف در مسیرهای مختلف اجرا میشه میتونید بزارید داخل conftest.py بالا و بدون دردسر حملش کنید و فقط کافیه صداش بزنید بعنوان پارامتر ورودی تست‌های دیگتون

گزینه autouse بهتون میده واسه وابستگی‌هایی که همه جا باید اجرا بشه مثه چی؟؟؟ تنظیم timezone, پاک کردن کش برای هر تست، ماک کردن یک سرویس و ....

میتونید از آرگومان کامند لاین استفاده کنید، شما تو محیط توسعه لوکال مقادیر environment هاتون رو داخل فایل .env میزارید و روی سروی و داخل stage های pipeline نزریق میشن، این قسمت بهتون کمک میکنه که با ارسال args در خط فرمان به conftest.py بگید که مقادیر environment رو از کجا بگیره، کافیه شما دو مقدار
--load-test
--load-dev
تعریف کنید و جالبتر اینکه با ترکیب این args و scope در پاراگراف بالاتر، یک معجزه در conftest.py واسه fixture بنویسید و خودتون رو درگیر جداسازی تست‌ها و scope برای محیط تست و اوتومیشن نکنید


بهتون امکان مارک‌گذاری رو‌میده یک سیستم شبیه به برچسب دهی یا تگ گذاری کردن برای تست‌هاتون (skipif , skip, fail , timeout , ...) یک قسمت محبوب برای توسعه دهنده‌ها parametrize هستش، در یک سناریوی ویو شما status های مختلف دارید 200, 400, 500 دارید لازم نیست چندتا تست بنویسید یا assert های مختلف برای هر بخش با این ویژگی می‌تونید یکبار یک تست جامع برای ویوتون بنویسید تو هر بخش اضافه شدن جدید بهش فقط parameterize رو بروز می‌کنید (یک مثال کاربردی تر ویویی که params میگیره) یا ویویی که با permission‌های مختلف کار میکنه هستش

و جالبترین قسمتش آرگومان‌های داخلی خودش برای cli هستش که میتونید یک حالت مانیتور مانند کامل برای تست‌هاتون داشته باشید

-v
-s
--tb
-ra
--lf
-m (unit/e2e/smoke/integration)
-k
--fixtures
--maxfail
--duration
--markers
-W ignore

#test

@code_crafters

چرا pytest ابزاری مهندسی شده هستش؟؟؟

یکی از موارد جذاب در این فریمورک در بخش markerها نهفته شده
یک نوع تست وجود داره که بهش میگیم smoke، کاربردش چیه فقط بررسی میکنه سیستم زنده هستش یا نه، تو حوزه تستر مورد استفاده زیادی هستش، شما کافیه روی یکسری تست‌ها که هدفشون بررسی حیات سیستم هستش این برچسب رو بزارین، چه اتفاقی میافته؟؟؟ درون ci قبل از اینکه همه تست‌هارو اجرا کنید اول smoke رو ران میکنید و اگه پاس شدن بعد سراغ مابقی روند میرید این باعث میشه ci سریعتر رخ بده
pytest -m smoke

ما تست‌های مختلفی داریم
تست unit که فقط منطق یک متد رو بررسی میکنه سمت side-efect و هر چیزی بیرون از منطق متد نمیره و نمیبرین این تست‌ها و کافیه با مارک. unit مشخص کنید
pytest -m unit

تست integration داریم که وابستگی‌های داخلی رو بررسی میکنه نه بیرون از پروژه با مارکر integeration مشخص کنید (فراموش نکنید در این نوع تست زیرساخت واقعی منتها در محیط ایزوله تست میشه)
pytest -m integeration

و همچنین برای تست e2e که رفتار واقعی یوزر رو تست میکنه با مارکر e2e مشخص کنید

تو برخی سیستم‌های خاص لازم هستش که رفتار اشتباه هم تست بشه (سیستم‌های مالی) با مارکر exception کار کنید

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

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

بیشترین تست رو unit
در حد معقول رو integeration
و تعداد کم رو e2e شامل میشه

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

چندتا ابزار مهندسی دیگه
تو سیاست نامه سازمان‌های حرفه‌ای، قوانین زمان ریسپانس برای یک اندپوینت میزارن، با استفاده از پکیج pytest-timeout و مارکر timeout میتونید این سیاست‌نامه رو بررسی کنید

@pytest.mark.timeout(3)
def test_timeout();
     time.sleep(4)
     assert 1 == 1

با استفاده از پکیج pytest-cov میتونید میزان پوشش کدهای تست شده رو بررسی کنید و علاوه بر اون حجم درست کدهای تست شده (درستی و کیفیت تست رو شامل نمیشه) و یک گزارش بگیرید که شامل جزئیات کمتر یا بیشتر باشه ، اینکه در متد یا کلاس یا ماژول یا برنامه یا پکیچ تا چه مقدار و میزانی کدها تست شده یا چه بخش‌هایی از یک متد تست شده یا نشده (try/except , if/else)


در نهایت pytest یک فریمورک در خدمت مهندسی نرم افزار هستش جایی که حلقه
(فرآیند -> تحلیل -> ساخت -> تست -> اجرا ) شکل میگیره


#test


@code_crafters

معماری به مثابه معنا، نه جداسازی سطحی (در سیستم‌های بزرگ و چند لایه)

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

بیاید مثال عملی تر بزنیم
ما مقادیر:
static
media
UI application(front)
api application(backends)

رو داریم همه اینها رو در ورودی بعد از web server نزارید، باید ساختار گرافی بسازید، به چه شکل؟؟؟

Nginx => static, media, ui, gateway

gateway=> BFF, identity service, cms service

BFF => (first level backends)

جالب شد BFF چیه؟؟؟
اینجا دقیقا جایی هستش که اوج معماری مدرن شروع میشه تفکیک بین microservice بر پایه DDD یا فقط modularity monoloth (که کابوس شکست سازمان‌هایی هستش که مهندس نرم افزار ندارن) یعنی چی؟؟؟ تفکیک پذیری بر اساس معنا، نه بر اساس جدا سازی

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

سه مفهوم رو در DDD براتون بگم تا یکم مسئله رو باز کنم
Ubiquitous language
SAGA
Aggregation

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

هویت: هر چیزی که به تنهایی بتونه مستقل معنا بده
موجودیت: هر چیزی که جهت معنا نیاز به اتصال داشته باشه

واسه مثال: کاربر هویت هستش (دارای شناسه یکتا در سیستم)، مشتری و پاسخ گیرنده موجودیت وابسته به کاربر هستند که شماره تماس، آدرس و ... دارند

موضوع بعدی SAGA:
انجام یکسری عملیات های رکوردی در یک درخواست، یعنی شما یک درخواست میگیرید و چندین جدول مختلف رو باهاش تاچ و کامیت میکنید (یک الگوی سخت)

مورد بعدی aggregation:
دریافت یک درخواست و جمع آوری اطلاعات در یک نقطه خاص

این سه مورد موضوعاتی هستند که داخل BFF حضور دارن یعنی دامنه اصلی و شاید پشتیبان در رویکرد DDD و اینجا جایی هستش که بهش میگیم شروع business logic و فاز توسعه میکروسرویس شروع میشه و امسدوارم فاز پایه خوبی رو اجرا کرده باشین وگرنه شروع نشده با شکست روبرو هستید

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

نوع داده و درخواست:
اگه درخواست از نوع sync باشه از gRPC استفاده میکنید
اگه نوع درخواست async/event driven باشه از rabbitmq

در یک زبان ساده بگم بهتون، grpc میاد وسط سرویس‌هاتون قرار میگیره و rabbitmq میاد در کنار سرویس‌هاتون قرار میگیره و در صورت نیاز در جاهای خاصی میاد بین سرویس‌ها نقش ایفا میکنه (جایی که هزاران درخواست میان جهت کامیت در دیتابیس)

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

مرزبندی سرویس‌ها رو جدی بگیرید، این یک روند بر اساس تجربه و دانش هستش، و با DTO مرز بین سرویس‌هاتون رو داخل کدهاتون مشخص کنید

درخواست در مرحله اول میرسه به view و داخل اون ابتدا serializable اجرا میشه (درستی نوع تایپ مدنظر)، در مرحله بعد وارد سرویس میشه و داخل سرویس ابتدا value object (یک مفهوم دیگه از DDD) صدا زده میشه جهت ولیدیشن و اعتبار سنجی و بعد منطق تجاری روش اجرا میشه و در نهایت به DTO تبدیل میشه و ویو جهت ریسپانس برگردونده میشه

request => view - response

view => serialization (type data) - service - return DTO

service => value objects (validation) - logic (data layer and ...) - DTO


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


@code_crafters

چند نکته جالب بهتون بگم

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

#File tox.ini

[tox]
envlist = py39, py310

[testenv]
deps = -rrequirements.txt

commands = pytest

علاوه بر این شما میتونید داخل تست‌هاتون از دیباگر داخل پایتون (pdb) استفاده کنید، در نقاط مدنظرتون مقدار breakpoint() رو قرار بدید و بعد از اجرا با pytest دیباگرتون رو با دستورات
c ادامه برنامه
n رفتن به خط بعد
l نمایش خطوط اطراف
q بستن دیباگر

مدیریت کنید


در نهایت یکی از موضوعات جالب pytest داشتن پلاگین‌های بی شمار آن است
pytest-cov
pytest-django
pytest-timeout
pytest-async
pytest-repeat
pytest-bdd
pytest-xdist

و کلی پلاگین دیگه که داخل داکیومنت رسمی pytest

Refrence guides -> pytest plugin list

مشاهده کنید


و یک کتاب خوب هم جهت خوندن بهتون معرفی کنم
python testing with pytest
هستش

#test

@code_crafters

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

کار ریموت خوبه؟؟؟

اگه عادت کنی که روزای تعطیل هم کار کنی آره

اونم تا قبل خواب😐😐😐😐