یکی از خطرناک‌ترین اتفاقاتی که می‌تواند برای یک تیم فنی بیفتد، این نیست که اشتباه کند.این است که دیگر اشتباهاتش را نبیند.

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

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

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

بچه ها بیاید با هم یک چالش بذاریم تا آخر سال بلکه یه نظمی در یادگیری پیدا کنیم.
من هر پنجشنبه ساعت 09:00 یک تاپیک رو معرفی میکنم با یکسری منبع، اگر منابع رو خوندید و موضوع رو یاد گرفتید پستش رو لایک کنید.

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

@thisisnabi_dev

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

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

🎯 سوالات مصاحبه برای Microservices

اگر برای مصاحبه‌های معماری نرم‌افزار، Senior Backend یا Solution Architect آماده می‌شوید، این‌ها از مهم‌ترین سوالاتی هستند که باید بتوانید به آن‌ها پاسخ دهید. 🚀

1️⃣ چگونه مرزهای سرویس‌ها را با استفاده از Domain-Driven Design (DDD) تعریف می‌کنید؟

2️⃣ چه معیارهایی تعیین می‌کنند که یک سرویس را جدا کنید یا آن را به‌صورت مشترک نگه دارید؟

3️⃣ چگونه یک «Distributed Monolith» را شناسایی و از آن جلوگیری می‌کنید؟

4️⃣ مزایا و معایب Orchestration و Choreography چیست؟

5️⃣ چگونه از الگوی Strangler Fig برای مهاجرت سیستم‌های Legacy استفاده می‌کنید؟

6️⃣ چه زمانی یک Shared Library بهتر از الگوی Sidecar است؟

7️⃣ چه زمانی برای ارتباطات داخلی gRPC را به REST ترجیح می‌دهید؟

8️⃣ چگونه الگوی Circuit Breaker را برای جلوگیری از Cascading Failure پیاده‌سازی می‌کنید؟

9️⃣ چگونه مشکل Thundering Herd را زمانی که یک سرویس دوباره آنلاین می‌شود مدیریت می‌کنید؟

🔟 استراتژی شما برای Retry با Exponential Backoff چیست؟

1️⃣1️⃣ چگونه هنگام تکامل Schema، سازگاری عقب‌رو (Backward Compatibility) API را حفظ می‌کنید؟

2️⃣1️⃣ چگونه Idempotency را در Message Consumerها طراحی می‌کنید؟

3️⃣1️⃣ چگونه بین Sagaهای مبتنی بر Choreography و Sagaهای مبتنی بر Orchestration انتخاب می‌کنید؟

4️⃣1️⃣ چگونه Joinهای بین سرویس‌ها را برای گزارش‌گیری‌های پیچیده مدیریت می‌کنید؟

5️⃣1️⃣ مزایا و معایب Database-per-Service در مقابل Database-Schema-per-Service چیست؟

6️⃣1️⃣ چگونه تراکنش‌های توزیع‌شده را بدون Two-Phase Commit (2PC) مدیریت می‌کنید؟

7️⃣1️⃣ چگونه مشکل Dual Write را هنگام به‌روزرسانی پایگاه داده و انتشار Eventها حل می‌کنید؟

8️⃣1️⃣ چه استراتژی‌هایی برای Eventual Consistency استفاده می‌کنید؟

9️⃣1️⃣ چگونه Distributed Tracing را بین چندین سرویس پیاده‌سازی می‌کنید؟

0️⃣2️⃣ چگونه Drift شدن Configuration را بین محیط‌های مختلف مدیریت می‌کنید؟

1️⃣2️⃣ استراتژی شما برای Dead Letter Queue (DLQ) و بازپخش پیام‌ها (Message Replay) چیست؟

2️⃣2️⃣ چگونه ارتباطات Service-to-Service را ایمن می‌کنید؟

3️⃣2️⃣ چگونه تفاوت بین تأخیر شبکه (Network Latency) و کندی خود برنامه (Application Slowness) را تشخیص می‌دهید؟

4️⃣2️⃣ چگونه یک Microservice را به‌صورت ایزوله تست می‌کنید بدون اینکه کل مجموعه سرویس‌ها را Mock کنید؟

💡 بسیاری از این سوالات مستقیماً به مفاهیمی مانند:
✅ Domain-Driven Design (DDD)
✅ Event-Driven Architecture
✅ Saga Pattern
✅ Outbox & Inbox Pattern
✅ CQRS
✅ Eventual Consistency
✅ Distributed Tracing
✅ Resiliency Patterns
✅ RabbitMQ / Kafka
✅ Kubernetes & Cloud-Native Architecture
مرتبط هستند و در مصاحبه‌های سطح Senior و Architect بسیار رایج‌اند. 🚀🔥

هشتگ‌ها:
#Microservices #SoftwareArchitecture #BackendDevelopment #EventDrivenArchitecture #TechInterview

یکی از جالب‌ترین چیزهایی که در مصاحبه‌های فنی یاد گرفتم این بود که همیشه بهترین پاسخ‌ها، درست‌ترین پاسخ‌ها نیستند.
بارها پیش آمده از یک نفر پرسیده‌ام:
«برای حل این مسئله چه راهکاری پیشنهاد می‌کنی؟»
و او شروع کرده به توضیح دادن پیشرفته‌ترین معماری‌ها، Patternها و تکنولوژی‌هایی که می‌شناسد.
همه چیز از نظر تئوری درست بوده است.
اما یک سؤال همیشه در ذهنم شکل می‌گرفت:
«برای چه؟»
برای ۱۰۰ کاربر؟
برای ۱۰ میلیون کاربر؟
برای یک تیم ۳ نفره؟
یا یک تیم ۱۰۰ نفره؟
چون در مهندسی نرم‌افزار، هیچ راهکاری در خلأ خوب یا بد نیست.همه چیز به مسئله بستگی دارد.به محدودیت‌ها.به هزینه‌ها.و به Trade-offهایی که حاضر هستیم بپذیریم.
به مرور زمان متوجه شدم چیزی که در مصاحبه‌ها بیشتر از دانش فنی توجه مرا جلب می‌کند،نوع فکر کردن افراد است.
اینکه قبل از ارائه راه‌حل، چند سؤال می‌پرسند.
چقدر برای فهمیدن مسئله زمان می‌گذارند.
و چقدر حاضرند فرضیات خودشان را به چالش بکشند.
چون در دنیای واقعی،بیشتر وقت ما صرف حل مسئله نمی‌شود.صرف فهمیدن مسئله می‌شود.
و گاهی تفاوت یک توسعه‌دهنده خوب و یک مهندس نرم‌افزار خوب،در کیفیت پاسخ‌هایشان نیست.
در کیفیت سؤال‌هایشان است.

2. Data Partitioning

منابع پیشنهادی این چالش که برای من اینها جذاب بوده و هست.

A. Pro SQL Server Internals [book]
- Chapters 16 - required

B. MySql Docs
- site

@thisisnabi_dev

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

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

#مهندس_فکر_کن
قسمت:1️⃣
🎯 سوال مصاحبه مهندسی نرم‌افزار

فرض کنید یک سرویس ASP.NET Core دارید که پیام‌ها را از Kafka دریافت می‌کند.
پیام دریافت می‌شود.Business Logic اجرا می‌شود.
داده در Database ذخیره می‌شود.
اما درست قبل از Commit Offset سرویس Crash می‌کند.
پس از Restart شدن سرویس، همان پیام دوباره پردازش می‌شود.
سؤال:
چگونه از ثبت دوباره اطلاعات جلوگیری می‌کنید؟

چرا هر تیم نرم‌افزاری باید Runbook داشته باشه؟ سلام دوستان، تو دنیای امروز که سیستم‌ها ۲۴/۷ کار می‌کنن، Runbook دیگه لوکس نیست، یه ضرورت هست.Runbook چیه؟سند زنده‌ای که دقیقاً می‌گه:وقتی مشکلی پیش اومد چیکار کنیم؟ (Step-by-step)
وابستگی‌های سیستم چیا هستن؟
چک‌لیست‌های روزانه، هفتگی و ماهانه
راه‌حل‌های رایج خطاها و Incidentها
اطلاعات تماس افراد کلیدی و Escalation Path
حتی به تیم های مرتبط میگه endpoint هامون چین و ورودی خروجی های مورد انتظارش چیه


اهمیت Runbook برای تیم‌های نرم‌افزاری:کاهش چشمگیر زمان Downtime
وقتی Incident اتفاق می‌افته، دیگه کسی سردرگم نیست که "اول کجا رو چک کنیم؟" تیم تو کمتر از ۵ دقیقه وارد Action می‌شه.
کاهش وابستگی به افراد خاص
یکی از اعضای کلیدی تیم مرخصی باشه یا شرکت رو ترک کنه، دانش از دست نمی‌ره.
Onboarding خیلی سریع‌تر
developer یا SRE جدید تو همون هفته اول می‌تونه Incidentهای سطح متوسط رو هندل کنه.
Consistency در عملیات
همه اعضای تیم به یک روش استاندارد عمل می‌کنن، نه هر کسی به سلیقه خودش.
بهبود کیفیت و آرامش خاطر
وقتی بدونید همه چیز مستند شده، خواب راحت‌تری دارید!

تجربه واقعی:تیم‌هایی که Runbook خوب دارن، MTTR (Mean Time To Recovery) شون رو تا ۵۰-۷۰٪ کاهش دادن.پیشنهاد من:
همین امروز یه Runbook اولیه برای مهم‌ترین سرویس‌هاتون بسازید. حتی اگه ناقص باشه، بهتر از هیچی هست. بعد به مرور کاملش کنید.از ابزارهایی مثل Notion، Confluence، Markdown تو GitHub یا GitLab Wiki می‌تونید استفاده کنید.شما Runbook دارید؟
تو کامنت بگید تیم‌تون چقدر به مستندات عملیاتی اهمیت می‌ده؟ #DevOps #SRE #Runbook #SiteReliability #SoftwareEngineering #تیم_فنی

چند سال پیش از یکی از مدیران فنی سؤال کردم:
«چطور می‌فهمی یک تصمیم معماری خوب بوده یا نه؟»
فکر می‌کردم قرار است درباره Performance، Scalability یا Availability صحبت کند.
اما جوابش چیز دیگری بود.
گفت:
«ببین چند ماه بعد، تغییر دادن آن تصمیم چقدر درد دارد.»
آن زمان خیلی متوجه منظورش نشدم.
اما هرچه بیشتر روی سیستم‌های واقعی کار کردم، بیشتر به عمق این جمله پی بردم.
بیشتر تصمیم‌های معماری، روزی که گرفته می‌شوند عالی به نظر می‌رسند.
مشکل زمانی شروع می‌شود که نیازمندی‌ها تغییر می‌کنند.
کسب‌وکار مسیر جدیدی می‌رود.
تیم بزرگ‌تر می‌شود.
یا حجم کاربران چند برابر می‌شود.
اینجاست که کیفیت واقعی تصمیم‌ها مشخص می‌شود.
چون بعضی تصمیم‌ها فقط برای امروز بهینه هستند.
و بعضی دیگر، تغییرات آینده را هم در نظر گرفته‌اند.
جالب است که انعطاف‌پذیری یک سیستم را معمولاً از روی چیزهایی که می‌تواند انجام دهد نمی‌سنجند.
از روی چیزهایی می‌سنجند که می‌تواند تغییر دهد.
شاید به همین دلیل باشد که مهندسی نرم‌افزار کمتر درباره پیش‌بینی آینده است.
و بیشتر درباره آماده بودن برای آینده‌ای است که نمی‌توانی پیش‌بینی‌اش کنی.
در نهایت، ارزش یک طراحی خوب فقط در این نیست که امروز جواب می‌دهد.
در این است که فردا هم بتوانی با آن زندگی کنی.

#مهندس_فکر_کن
قسمت:2️⃣

🎯 مصاحبه‌کننده:
فرض کنید یک سیستم Microservice دارید.
سرویس A یک سفارش ثبت می‌کند.
سرویس B پرداخت را انجام می‌دهد.
سرویس C موجودی انبار را کم می‌کند.
سرویس D پیامک ارسال می‌کند.
در میانه کار، پرداخت موفق انجام می‌شود اما سرویس انبار از دسترس خارج می‌شود.

سؤال:
آیا باید یک Transaction سراسری تعریف کنیم تا اگر یکی از سرویس‌ها شکست خورد، همه چیز Rollback شود؟دلیل؟