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

بخش ۲، فلوی شکل‌گیری ایده تا رسیدن به محصول و محیط عملیاتی در بخش اول دیدیم که ریشه‌ی تنش بین مدیر محصول و مهندس، بیشتر از اینکه یه موضوع فردی باشه، یک مشکل ساختاریه. ابهام در مالکیت، اشتباه گرفتن Product Manager با Project Manager، و موندن توی مدل Feature Team، باعث می‌شه سیستم به سمت … ادامه

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

بخش اول: ریشه‌شناسی یک تنش ساختاری مقدمه: دعوای ظاهری، مشکل ساختاری این گفت‌وگو تکراری، بین مدیرمحصول و مهندس نرم‌افزار رو توی خیلی از تیم‌های نرم‌افزاری می‌بینیم:– مدیر محصول یه فیچر رو تعریف می‌کنه+ مهندس نرم‌افزار: «این‌‌جوری نمی‌شه»– مدیر محصول: «چرا نمی‌شه؟»+ مهندس: «چون پیچیده ست»و همین‌جاست که یک رابطه‌ی کاری شروع به فرسایش می‌کنه. اما … ادامه

فرهنگ و ساختار نسخه‌دهی در تیم‌های نرم‌افزاری (بخش دوم)

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

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

مقدمه:فرهنگ و ساختار نسخه‌دهی توی تیم‌های نرم‌افزاری، با اینکه پیشینه طولانی داره و نسل اولش به دهه‌های ۶۰ و ۷۰ و میلادی برمی‌گرده و حتی ابزارهای مدرن‌ترش مثل git توی بیست‌سالگی‌شون به سر می‌برن؛ ولی کماکان موضوعی مهم و اثرگذار روی تیم‌هاست. و البته کم نیستن تیم‌هایی که با انتخاب روش اشتباه یا نپرداختن به … ادامه

سال ۲۰۲۶، فرصت‌ها و تهدیدهای اکوسیستم نرم‌افزار ایران…

امروز آخرین روز سال ۲۰۲۵ است؛ و می‌دونم این روزها سخته؛ برای همه‌مون. اما همین روزهای سخته که تصمیم‌های امروز ما رو معنی می‌ده. در حالی که برای خیلی‌ها، ذهنشون نه آرومه، نه مطمئن، نه حتی امیدوار؛ این متن رو برای دلداری یا موعظه نمی‌نویسم. می‌خوام صادقانه درباره چند واقعیت حرف بزنم و چند اقدام … ادامه

ترمینولوژی تست نرم‌افزار – ویراست ۰.۵

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

نمونه دنیای واقعی: کلودفلر چجوری به مستندات فنی نگاه می‌کنه؟

مستندنویسی فنی یکی از مغفول‌ترین بخش‌های توسعه نرم‌افزار، خصوصا در ایرانه! همه می‌گن خیلی واجبه و ما خیلی ارج می‌نهیم به مستندات، ولی آخرش همون همه، مشمول ترک واجبات و ارج ننهادن می‌شن! حتی technical write پوزیشن گمنامیه توی لیست مشاغل. حالا اینکه چطور کلودفلر، به عنوان شرکتی که توی ۱۹٪ اینترنت رد پاش دیده … ادامه

در باب OpenTelemetry

مقدمهحتماً اسم OpenTelemetry (یا همون OTel) رو حول و حوش موضوعات مانیتورینگ و لاگینگ، شنیدین. هرچقدر تنوع کامپوننت‌ها، سرویس‌ها، اپلیکیشن‌ها بیشتر بیشتر بشه؛ یا به زبون ساده سیستم توزیع بشه، لزوم استفاده از یک استاندارد یا مکانیزم فراگیر، اهمیتش بیشتر می‌شه. فکر کنید لاگ رو با یه فرمتی که مختص دات‌نت باشه بنویسیم، یا اندازه‌گیری … ادامه

انواع استراتژی‌های تاب‌آوری نرم‌افزار (Resiliency Strategy)

مفهوم Resiliency یا تاب‌آوری، به توانایی یک سیستم برای بازیابی شرایط پایدار در صورت بروز خطا گفته می‌شه. حالا این بازیابی می‌تونی تلاش برای بازیابی باشه، یا انتخاب راه جایگزین. مثل اینکه شما ۲ بار تلاش می‌کنی از API آب‌وهوا مقدار دمای فعلی یک منطقه رو بگیری، هر بار با فاصله زمانی ۵ ثانیه API … ادامه

مقدمه‌ای بر GraphQL

اصلا GraphQL چیه؟ به زبان ساده، GraphQL مکانیزمیه تا بتونیم با یک استاندارد مشخص، کوئری‌مون رو به «یک» API ارسال کنیم و داده‌ها رو دریافت. یعنی بابت هر داده‌ای که نیاز داریم دریافت کنیم سراغ یک REST API جداگانه نریم. بلکه فارغ از اینکه داده‌هامون یک جا هستن یا از منابع مختلفی تأمین می‌شن، صرفا … ادامه