CodeCrafters

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

چرا 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

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

چرا 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 برای محیط تست و اوتومیشن نکنید بهتون امکان مارک‌گذاری رو‌میده یک سیستم شبیه به برچسب دهی یا تگ گذاری کردن برای تست‌هاتون (skip, fail , ...) یک قسمت محبوب برای توسعه دهنده‌ها parametrize هستش، در یک سناریوی ویو شما status های مختلف دارید 200, 400, 500 دارید لازم نیست چندتا تست بنویسید یا assert های مختلف برای هر بخش با این ویژگی می‌تونید یکبار یک تست جامع برای ویوتون بنویسید تو هر بخش اضافه شدن جدید بهش فقط parameterize رو بروز می‌کنید (یک مثال کاربردی تر ویویی که params میگیره) یا ویویی که با permission‌های مختلف کار میکنه هستش و جالبترین قسمتش آرگومان‌های داخلی خودش برای cli هستش که میتونید یک حالت مانیتور مانند کامل برای تست‌هاتون داشته باشید -v -s --tb -ra -m -k --fixtures --maxfail --duration --markers #test @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 و به همون اندازه معماری درست توسعه دامنه محور چندتا سوال از خودتون بپرسید آیا منطق تجاری داخل سیستم مهمتر هستش و انتهای پروژه بازتره؟؟؟ پس برید از نوشتن تست سرویس و پاس کردن اون شروع کنین آیا تراکنش در سیستم مهمتره و انتهای پروژه مشخص‌تر؟؟؟ پس برید از نوشتن تست ویو و پاس کردنش شروع کنید در نهایت وظیفه توسعه دهنده نوشتن تست واحد و تجمیع و اطمینان از عملکرد منطقی کد هستش و تستر اطمینان از صحت سرویس و رفتار سرویس #rest #tdd #ddd #bdd @code_crafters

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

📌 یادگیری کتابخانه Playwright واقعاً ارزشمنده چه برای خزش وب (Web Crawling) و چه برای تست سامانه‌ها، Playwright یکی از ابزارهای بسیار قدرتمنده دست شما رو کاملاً باز می‌ذاره و تقریباً هر چیزی که برای کار حرفه‌ای نیاز دارید رو فراهم کرده. یکی از قابلیت‌های جذابش حالت Headless هست: * اگر headless=false باشه، کد دقیقاً روی دسکتاپ اجرا می‌شه و توسعه و دیباگ رو خیلی راحت می‌کنه * اگر headless=true باشه، آماده‌ی اجرا روی سرور می‌شه (ایده‌آل برای استفاده داخل CI/CD) 🧠 مفهوم Context رو به‌خوبی پیاده‌سازی کرده (تصور کنید یک پروفایل جدید در مرورگر باز می‌کنید که می‌تونه چندین تب همزمان داشته باشه) 📸 امکان Screenshot و حتی Record کردن ویدیو از صفحه رو می‌ده چه در حالت headless و چه غیر headless (خیلی کاربردی برای مستندسازی، داکیومنت فنی و آموزش کار با سامانه‌ها) 🔌 کار با API رو هم به‌صورت native در اختیارتون می‌ذاره مدیریت کوکی، سشن و احراز هویت در طول اجرای تست‌ها رو خودش کاملاً هندل می‌کنه 📦 با انواع فرمت‌های داده سازگاره و خیلی راحت می‌تونید با داده‌های مختلف کار کنید 🔥 اما یه نکته‌ی خیلی جذاب در تست سامانه‌ها: فرض کنید طبق سیاست‌نامه‌ی سازمان، یک صفحه باید حداکثر تا ۵ ثانیه اندپوینت‌هاش پاسخ بدن. تستر می‌تونه به اون بخش از صفحه timeout پنج‌ثانیه‌ای بده و خروجی رو بررسی کنه بدون درگیری مستقیم با لاگ‌ها یا کدهای پیچیده. هرچی بیشتر درباره Playwright می‌خونم، بیشتر به این نتیجه می‌رسم که این کتابخونه حاصل تجربه‌ی واقعی در دنیای مهندسی نرم‌افزاره، نه صرفاً یک ابزار تئوریک. @code_crafters

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

تاریخ ثابت کرده وقتی پولدارا معترض باشن کشورشون رو عوض میکنن وفتی فقرا معترض باشن دولتشون رو

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

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

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

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

Technical Debt (بدهی فنی)

البته بدهی فنی فقط باگ نیست و می‌تواند شامل: * طراحی غیر بهینه * تصمیم‌های کوتاه‌مدت معماری * تست‌نویسی ناکافی * پیچیدگی‌های انباشته‌شده‌ی سیستم باشد. اما بخشی از بدهی فنی می‌تواند خودش را به‌صورت باگ یا Issue نشان دهد. بدهی فنی تا سطح متوسط: باعث افزایش دانسته‌ی سازمانی (افزایش دانش فنی) می‌شود تجربه‌ی تیم را بالا می‌برد و یکی از نشانه‌های بلوغ فنی سازمان محسوب می‌شود (این مفهوم به‌صورت انتزاعی با شاخص‌هایی مثل TRL / TRA هم‌راستاست) حد قابل‌قبول بدهی فنی چگونه سنجیده می‌شود؟ به‌صورت تجربی و مدیریتی (نه الزاماً آکادمیک)، می‌توان از این معیار استفاده کرد:

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

حالا خروجی بالا؛ کمتر از ۱۵ درصد موجب دانسته (افزایش دانش فنی) میشه تا ۳۰ درصد یعنی پروژه در لبه بحران هستش و بیشتر از ۳۰ درصد نیاز به بازنگری جدی در فرآیند توسعه (اسکرام یا معادل آن) و تصمیم مدیریتی وجود دارد (ادامه با هزینه، یا توقف/بازطراحی پروژه) نشانه‌ی مدیر و سرپرست فنی بالغ در رویکردهای نوین مدیریت فنی: تمرکز مدیر خوب روی «پر کردن زمان نیروی بیکار» نیست تمرکز او روی تسک‌های ناتمام، گلوگاه‌ها و پیچیدگی‌های حل‌نشده است نیرویی که بیش‌ از حد بیکار است، معمولاً یکی از این شرایط را دارد: هنوز مهارت ورود به پیچیدگی را پیدا نکرده واقعاً کارش تمام شده یا در جایگاه مناسب خودش قرار نگرفته (اینم اضافه کنم نیروی بیش از حد شلوغ هم ضد معیار TRA/TRL هستش یعنی سازمان یک ایرادی داره) چطور می‌توان تولید باگ را کاهش داد؟ برخلاف تصور رایج

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

اکثر باگ‌ها ناشی از: - نبود تصویر ذهنی شفاف - مشخص نبودن مسیرها و حالت‌ها - بی‌دقتی در سناریوها هستند + نه کمبود دانش فنی قبل از کدنویسی: - فلوچارت بکشید - سناریوها را مرور کنید - و Design Review انجام دهید +سپس کدنویسی و تست را شروع کنید با تشکر از هوش مصنوعی که متنم رو‌ مرتب کرد (باورکنید فقط مرتبش کرد) @code_crafters

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