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

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

خب بیایید اول ببینید انتظارتو از پاسخ (reaponse) چیا هستش

این رو کامل لیست کنید چه در حالت خطا و چه در حالت درست

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

برنامه wiremock رو نصب و راه اندازی کنید، یک اندپوینت براش بسازید که اون json فایل رو بهتون برگردونه، به همین راحتی سناریوی واقعی رو پیاده سازی میکنید باهاش

@code_crafters

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

نظرتون رو راجب گیت‌هابم میخواستم

از سرکار برگشت
غذا درست کرد
رفت باشگاه
برگشت خونه
روتین پوستی انجام داد
غذاش رو با شکر گذاری خورد


من خونه محل کار دومم بود که حین کار شامم رو هم میخوردم، مشکل تایم خواب هم در نصف بیشتر هفته دارم (چون باید کارم رو برسونم)، من رو با این مقایسه میکنید؟؟؟؟

من همینکه دچار فروپاشی روانی نمیشم جای شکر داره بازم

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


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

تا فردا که مدیر یه جواب نهایی بهم بده

الان باشگاه بازه برم عضله بسازم؟؟؟؟

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


بعنوان مسئول تست و بررسی سازمان
وظیفه شما فقط گزارش درست و دقیق باگ هستش

ولی شما بعنوان تستر اگه سابقه مهندس نرم افزار داشته باشید میتونید برید تو نقش SDET یعنی لبه توسعه و تست بعنوان مهندس توسعه نرم افزار در تست

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

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

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

عنوان استخدام نیروی بکند
حقوق ۴۰ تا ۵۰ میلیون (مناسب سطح میدلول با تجربه)

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


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

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


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

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

سالها منظره اتاق من

تو چنین تایم‌های جلو پنجره باز شده چاییم میخوردم

اینبار بدون من

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

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

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

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