🎯 سوالات مصاحبه برای 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هایی که حاضر هستیم بپذیریم.
به مرور زمان متوجه شدم چیزی که در مصاحبهها بیشتر از دانش فنی توجه مرا جلب میکند،نوع فکر کردن افراد است.
اینکه قبل از ارائه راهحل، چند سؤال میپرسند.
چقدر برای فهمیدن مسئله زمان میگذارند.
و چقدر حاضرند فرضیات خودشان را به چالش بکشند.
چون در دنیای واقعی،بیشتر وقت ما صرف حل مسئله نمیشود.صرف فهمیدن مسئله میشود.
و گاهی تفاوت یک توسعهدهنده خوب و یک مهندس نرمافزار خوب،در کیفیت پاسخهایشان نیست.
در کیفیت سؤالهایشان است.
بارها پیش آمده از یک نفر پرسیدهام:
«برای حل این مسئله چه راهکاری پیشنهاد میکنی؟»
و او شروع کرده به توضیح دادن پیشرفتهترین معماریها، Patternها و تکنولوژیهایی که میشناسد.
همه چیز از نظر تئوری درست بوده است.
اما یک سؤال همیشه در ذهنم شکل میگرفت:
«برای چه؟»
برای ۱۰۰ کاربر؟
برای ۱۰ میلیون کاربر؟
برای یک تیم ۳ نفره؟
یا یک تیم ۱۰۰ نفره؟
چون در مهندسی نرمافزار، هیچ راهکاری در خلأ خوب یا بد نیست.همه چیز به مسئله بستگی دارد.به محدودیتها.به هزینهها.و به Trade-offهایی که حاضر هستیم بپذیریم.
به مرور زمان متوجه شدم چیزی که در مصاحبهها بیشتر از دانش فنی توجه مرا جلب میکند،نوع فکر کردن افراد است.
اینکه قبل از ارائه راهحل، چند سؤال میپرسند.
چقدر برای فهمیدن مسئله زمان میگذارند.
و چقدر حاضرند فرضیات خودشان را به چالش بکشند.
چون در دنیای واقعی،بیشتر وقت ما صرف حل مسئله نمیشود.صرف فهمیدن مسئله میشود.
و گاهی تفاوت یک توسعهدهنده خوب و یک مهندس نرمافزار خوب،در کیفیت پاسخهایشان نیست.
در کیفیت سؤالهایشان است.
Forwarded from thisisnabi.dev [Farsi]
2. Data Partitioning
منابع پیشنهادی این چالش که برای من اینها جذاب بوده و هست.
A. Pro SQL Server Internals [book]
- Chapters 16 - required
B. MySql Docs
- site
@thisisnabi_dev
منابع پیشنهادی این چالش که برای من اینها جذاب بوده و هست.
A. Pro SQL Server Internals [book]
- Chapters 16 - required
B. MySql Docs
- site
@thisisnabi_dev
چند وقت پیش داشتم یک مستند درباره پلهای قدیمی دنیا میدیدم.
یکی از مهندسها جمله جالبی گفت:
«بیشتر پلها به خاطر چیزی که نمیدانیم خراب نمیشوند. به خاطر چیزی خراب میشوند که فکر میکنیم میدانیم.»
این جمله عجیب در ذهنم ماند.
چون هرچه بیشتر در توسعه نرمافزار کار میکنم، بیشتر نمونههایش را میبینم.
خیلی از بحرانهای فنی از جایی شروع نمیشوند که دانش نداریم.
از جایی شروع میشوند که بیش از حد مطمئن هستیم.
مطمئنیم این Feature هیچوقت تغییر نمیکند.
مطمئنیم تعداد کاربران از این بیشتر نمیشود.
مطمئنیم این سرویس همیشه در دسترس خواهد بود.
مطمئنیم این Dependency مشکلی ایجاد نمیکند.
و دقیقاً همین اطمینانها هستند که بعدها ما را غافلگیر میکنند.
جالب است که در مهندسی نرمافزار، ندانستن معمولاً خطرناک نیست.
وقتی چیزی را نمیدانی، سؤال میپرسی.
تحقیق میکنی.
آزمایش میکنی.
اما وقتی فکر میکنی میدانی،اغلب هیچکدام از این کارها را انجام نمیدهی.
شاید به همین دلیل باشد که با افزایش تجربه، اعتمادبهنفس واقعی شبیه اطمینان مطلق نیست.
بیشتر شبیه احتیاط است.
شبیه این است که بدانی ممکن است چیزی را نبینی.
چون بسیاری از مشکلات بزرگ نرمافزار،از کمبود دانش به وجود نمیآیند.
از قطعیتهای اشتباه به وجود میآیند.
یکی از مهندسها جمله جالبی گفت:
«بیشتر پلها به خاطر چیزی که نمیدانیم خراب نمیشوند. به خاطر چیزی خراب میشوند که فکر میکنیم میدانیم.»
این جمله عجیب در ذهنم ماند.
چون هرچه بیشتر در توسعه نرمافزار کار میکنم، بیشتر نمونههایش را میبینم.
خیلی از بحرانهای فنی از جایی شروع نمیشوند که دانش نداریم.
از جایی شروع میشوند که بیش از حد مطمئن هستیم.
مطمئنیم این Feature هیچوقت تغییر نمیکند.
مطمئنیم تعداد کاربران از این بیشتر نمیشود.
مطمئنیم این سرویس همیشه در دسترس خواهد بود.
مطمئنیم این Dependency مشکلی ایجاد نمیکند.
و دقیقاً همین اطمینانها هستند که بعدها ما را غافلگیر میکنند.
جالب است که در مهندسی نرمافزار، ندانستن معمولاً خطرناک نیست.
وقتی چیزی را نمیدانی، سؤال میپرسی.
تحقیق میکنی.
آزمایش میکنی.
اما وقتی فکر میکنی میدانی،اغلب هیچکدام از این کارها را انجام نمیدهی.
شاید به همین دلیل باشد که با افزایش تجربه، اعتمادبهنفس واقعی شبیه اطمینان مطلق نیست.
بیشتر شبیه احتیاط است.
شبیه این است که بدانی ممکن است چیزی را نبینی.
چون بسیاری از مشکلات بزرگ نرمافزار،از کمبود دانش به وجود نمیآیند.
از قطعیتهای اشتباه به وجود میآیند.
Forwarded from tech-afternoon (Amin Mesbahi)
توی نظرسنجی آخر، گزینه Inbox/Outbox Pattern رأی دوم رو آورد، بالاخره امروز مطلب رو جمعجور کردم. با اینکه «مرور» است ولی از نظر حجم کمی بیشتر از مطالب رایج شد (چون اصل داستان سیستمهای توزیع شده، خیلی مبحث گستردهایه و مرور یک مفهوم رایج و دمدستیاش هم نیاز به توضیح بیشتری داشت.
پیشاپیش بابت اشتباهات نگارشی یا انشایی متن عذرخواهی میکنم، دلیلش هم اینه که طی دو هفته هر زمان فرصت کوتاهی پیدا میشد بخشیاش رو نوشتم و احتمالا اگر فرصت بازبینی و ویرایشش بود، متن روانتری به دست میومد؛ ولی خب، قرار نیست هر ورژن اولیهای بهترین باشه.
- مرور الگوی outbox/inbox
- مسئله اصلی: Dual Write Problem
- الگوی Outbox
- الگوی Inbox
- بررسی جزئیتر مفهوم Idempotency
- طراحی بهتر پیامها
- تفاوت Domain Event و Integration Event
- روشهای پیادهسازی Outbox Publisher
- ابزارها و فریمورکهای رایج برای پیادهسازی inbox/outbox
- مفاهیم مکمل: Poison Message، Retry و Dead Letter
- لزوم Observability و Monitoring
- کاربرد Ordering پیامها
- پاکسازی دادهها
- تفاوت Outbox با Event Sourcing
- نسبت Outbox و Inbox با Saga
- چه زمانی واقعا به Inbox و Outbox نیاز داریم؟
🔗 لینک مطلب
Please open Telegram to view this post
VIEW IN TELEGRAM
#مهندس_فکر_کن
قسمت:1️⃣
🎯 سوال مصاحبه مهندسی نرمافزار
فرض کنید یک سرویس ASP.NET Core دارید که پیامها را از Kafka دریافت میکند.
پیام دریافت میشود.Business Logic اجرا میشود.
داده در Database ذخیره میشود.
اما درست قبل از Commit Offset سرویس Crash میکند.
پس از Restart شدن سرویس، همان پیام دوباره پردازش میشود.
سؤال:
چگونه از ثبت دوباره اطلاعات جلوگیری میکنید؟
قسمت:1️⃣
🎯 سوال مصاحبه مهندسی نرمافزار
فرض کنید یک سرویس ASP.NET Core دارید که پیامها را از Kafka دریافت میکند.
پیام دریافت میشود.Business Logic اجرا میشود.
داده در Database ذخیره میشود.
اما درست قبل از Commit Offset سرویس Crash میکند.
پس از Restart شدن سرویس، همان پیام دوباره پردازش میشود.
سؤال:
چگونه از ثبت دوباره اطلاعات جلوگیری میکنید؟
Forwarded from مسعود بیگی (مسعود بیگی)
چرا هر تیم نرمافزاری باید 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 #تیم_فنی
وابستگیهای سیستم چیا هستن؟
چکلیستهای روزانه، هفتگی و ماهانه
راهحلهای رایج خطاها و 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 صحبت کند.
اما جوابش چیز دیگری بود.
گفت:
«ببین چند ماه بعد، تغییر دادن آن تصمیم چقدر درد دارد.»
آن زمان خیلی متوجه منظورش نشدم.
اما هرچه بیشتر روی سیستمهای واقعی کار کردم، بیشتر به عمق این جمله پی بردم.
بیشتر تصمیمهای معماری، روزی که گرفته میشوند عالی به نظر میرسند.
مشکل زمانی شروع میشود که نیازمندیها تغییر میکنند.
کسبوکار مسیر جدیدی میرود.
تیم بزرگتر میشود.
یا حجم کاربران چند برابر میشود.
اینجاست که کیفیت واقعی تصمیمها مشخص میشود.
چون بعضی تصمیمها فقط برای امروز بهینه هستند.
و بعضی دیگر، تغییرات آینده را هم در نظر گرفتهاند.
جالب است که انعطافپذیری یک سیستم را معمولاً از روی چیزهایی که میتواند انجام دهد نمیسنجند.
از روی چیزهایی میسنجند که میتواند تغییر دهد.
شاید به همین دلیل باشد که مهندسی نرمافزار کمتر درباره پیشبینی آینده است.
و بیشتر درباره آماده بودن برای آیندهای است که نمیتوانی پیشبینیاش کنی.
در نهایت، ارزش یک طراحی خوب فقط در این نیست که امروز جواب میدهد.
در این است که فردا هم بتوانی با آن زندگی کنی.
«چطور میفهمی یک تصمیم معماری خوب بوده یا نه؟»
فکر میکردم قرار است درباره Performance، Scalability یا Availability صحبت کند.
اما جوابش چیز دیگری بود.
گفت:
«ببین چند ماه بعد، تغییر دادن آن تصمیم چقدر درد دارد.»
آن زمان خیلی متوجه منظورش نشدم.
اما هرچه بیشتر روی سیستمهای واقعی کار کردم، بیشتر به عمق این جمله پی بردم.
بیشتر تصمیمهای معماری، روزی که گرفته میشوند عالی به نظر میرسند.
مشکل زمانی شروع میشود که نیازمندیها تغییر میکنند.
کسبوکار مسیر جدیدی میرود.
تیم بزرگتر میشود.
یا حجم کاربران چند برابر میشود.
اینجاست که کیفیت واقعی تصمیمها مشخص میشود.
چون بعضی تصمیمها فقط برای امروز بهینه هستند.
و بعضی دیگر، تغییرات آینده را هم در نظر گرفتهاند.
جالب است که انعطافپذیری یک سیستم را معمولاً از روی چیزهایی که میتواند انجام دهد نمیسنجند.
از روی چیزهایی میسنجند که میتواند تغییر دهد.
شاید به همین دلیل باشد که مهندسی نرمافزار کمتر درباره پیشبینی آینده است.
و بیشتر درباره آماده بودن برای آیندهای است که نمیتوانی پیشبینیاش کنی.
در نهایت، ارزش یک طراحی خوب فقط در این نیست که امروز جواب میدهد.
در این است که فردا هم بتوانی با آن زندگی کنی.
#مهندس_فکر_کن
قسمت:2️⃣
🎯 مصاحبهکننده:
فرض کنید یک سیستم Microservice دارید.
سرویس A یک سفارش ثبت میکند.
سرویس B پرداخت را انجام میدهد.
سرویس C موجودی انبار را کم میکند.
سرویس D پیامک ارسال میکند.
در میانه کار، پرداخت موفق انجام میشود اما سرویس انبار از دسترس خارج میشود.
سؤال:
آیا باید یک Transaction سراسری تعریف کنیم تا اگر یکی از سرویسها شکست خورد، همه چیز Rollback شود؟دلیل؟
قسمت:2️⃣
🎯 مصاحبهکننده:
فرض کنید یک سیستم Microservice دارید.
سرویس A یک سفارش ثبت میکند.
سرویس B پرداخت را انجام میدهد.
سرویس C موجودی انبار را کم میکند.
سرویس D پیامک ارسال میکند.
در میانه کار، پرداخت موفق انجام میشود اما سرویس انبار از دسترس خارج میشود.
سؤال:
آیا باید یک Transaction سراسری تعریف کنیم تا اگر یکی از سرویسها شکست خورد، همه چیز Rollback شود؟دلیل؟
Forwarded from .NET Internals
امروز تو شرکت داشتم با یکی از بچه ها درمورد نظریه پنجره شکسته صحبت میکردیم.
ChatGPT:
Broken Window Theory (نظریه پنجره شکسته)
در برنامهنویسی یعنی:
اگر یک مشکل کوچک، کد بد یا باگ جزئی را نادیده بگیریم، کمکم افراد بیشتری هم بینظمی را عادی میبینند و کیفیت کل پروژه افت میکند.
مثال:
* یک فایل پر از کامنتهای قدیمی و بیاستفاده است.
* یک تابع اسم نامناسبی دارد.
* چند خط کد تکراری وجود دارد.
اگر این موارد اصلاح نشوند، برنامهنویسهای بعدی هم با خیال راحت کدهای نامرتب بیشتری اضافه میکنند. بعد از مدتی پروژه پر از «بدهی فنی» (Technical Debt) میشود و نگهداری آن سخت خواهد شد.
🔹 اسم این نظریه از یک مثال شهری آمده: اگر پنجره یک ساختمان شکسته باشد و تعمیر نشود، افراد تصور میکنند کسی به آنجا اهمیت نمیدهد و خرابکاریهای بیشتری رخ میدهد.
پیام اصلی برای برنامهنویسها:
> مشکلات کوچک را زود برطرف کن؛ نگذار کد نامرتب و خراب به حالت عادی تبدیل شود.
به همین دلیل تیمهای حرفهای معمولاً:
* باگهای کوچک را سریع رفع میکنند.
* کد را مرتب و خوانا نگه میدارند.
* قبل از Merge شدن، Code Review انجام میدهند.
* تستها را خراب رها نمیکنند.
خلاصه: یک «پنجره شکسته» در کد، اگر تعمیر نشود، میتواند کل پروژه را بهتدریج به هم بریزد. 🚪🔧💻
---------------
کوتاهش اینه که باید حس مسولیت پذیری داشته باشید اگر میبینید کدی خرابه یا یه جایی درست نیست ازش رد نشید و بگید این کد رو من نزدم با لید خودتون درمیون بذارید و حلش کنید یا حداقل دلیلشو بپرسید.
ChatGPT:
Broken Window Theory (نظریه پنجره شکسته)
در برنامهنویسی یعنی:
اگر یک مشکل کوچک، کد بد یا باگ جزئی را نادیده بگیریم، کمکم افراد بیشتری هم بینظمی را عادی میبینند و کیفیت کل پروژه افت میکند.
مثال:
* یک فایل پر از کامنتهای قدیمی و بیاستفاده است.
* یک تابع اسم نامناسبی دارد.
* چند خط کد تکراری وجود دارد.
اگر این موارد اصلاح نشوند، برنامهنویسهای بعدی هم با خیال راحت کدهای نامرتب بیشتری اضافه میکنند. بعد از مدتی پروژه پر از «بدهی فنی» (Technical Debt) میشود و نگهداری آن سخت خواهد شد.
🔹 اسم این نظریه از یک مثال شهری آمده: اگر پنجره یک ساختمان شکسته باشد و تعمیر نشود، افراد تصور میکنند کسی به آنجا اهمیت نمیدهد و خرابکاریهای بیشتری رخ میدهد.
پیام اصلی برای برنامهنویسها:
> مشکلات کوچک را زود برطرف کن؛ نگذار کد نامرتب و خراب به حالت عادی تبدیل شود.
به همین دلیل تیمهای حرفهای معمولاً:
* باگهای کوچک را سریع رفع میکنند.
* کد را مرتب و خوانا نگه میدارند.
* قبل از Merge شدن، Code Review انجام میدهند.
* تستها را خراب رها نمیکنند.
خلاصه: یک «پنجره شکسته» در کد، اگر تعمیر نشود، میتواند کل پروژه را بهتدریج به هم بریزد. 🚪🔧💻
---------------
کوتاهش اینه که باید حس مسولیت پذیری داشته باشید اگر میبینید کدی خرابه یا یه جایی درست نیست ازش رد نشید و بگید این کد رو من نزدم با لید خودتون درمیون بذارید و حلش کنید یا حداقل دلیلشو بپرسید.
در یکی از پروژهها، یک توسعهدهنده جدید به تیم اضافه شده بود.
چند هفته بعد از شروع کارش، در یکی از جلسات گفت:
«چرا این بخش سیستم اینقدر پیچیده طراحی شده؟»
چند نفر از اعضای قدیمی تیم لبخند زدند.
یکی از آنها گفت:
«چون تو هنوز داستانش رو نمیدونی.»
و واقعاً همینطور بود.پشت آن طراحی عجیب، چند سال تصمیمگیری، محدودیت، شکست، تغییر نیازمندی و تجربه پنهان شده بود.
اتفاق جالبی که بارها در پروژهها دیدهام این است که ما معمولاً فقط نتیجه تصمیمها را میبینیم.
نه شرایطی که آن تصمیمها در آن گرفته شدهاند.
برای همین گاهی قضاوت کردن خیلی آسان به نظر میرسد.
«من بودم اینطوری طراحی نمیکردم.»
«این معماری اشتباهه.»
«این کد باید از اول نوشته بشه.»
اما حقیقت این است که بیشتر سیستمها در شرایط ایدهآل ساخته نمیشوند.
در محدودیت زمان ساخته میشوند.
در محدودیت بودجه.
در فشار کسبوکار.
در شرایطی که اطلاعات کامل در دسترس نیست.
و شاید یکی از نشانههای بلوغ حرفهای این باشد که قبل از قضاوت یک تصمیم، سعی کنیم زمینه شکلگیری آن را بفهمیم.
نه برای اینکه از هر تصمیمی دفاع کنیم.
برای اینکه بدانیم طراحی سیستمها را فقط با نگاه کردن به کد نمیشود ارزیابی کرد.
باید داستان پشت آن کد را هم فهمید.
چون خیلی وقتها چیزی که امروز اشتباه به نظر میرسد،
دیروز بهترین تصمیم ممکن بوده است.
چند هفته بعد از شروع کارش، در یکی از جلسات گفت:
«چرا این بخش سیستم اینقدر پیچیده طراحی شده؟»
چند نفر از اعضای قدیمی تیم لبخند زدند.
یکی از آنها گفت:
«چون تو هنوز داستانش رو نمیدونی.»
و واقعاً همینطور بود.پشت آن طراحی عجیب، چند سال تصمیمگیری، محدودیت، شکست، تغییر نیازمندی و تجربه پنهان شده بود.
اتفاق جالبی که بارها در پروژهها دیدهام این است که ما معمولاً فقط نتیجه تصمیمها را میبینیم.
نه شرایطی که آن تصمیمها در آن گرفته شدهاند.
برای همین گاهی قضاوت کردن خیلی آسان به نظر میرسد.
«من بودم اینطوری طراحی نمیکردم.»
«این معماری اشتباهه.»
«این کد باید از اول نوشته بشه.»
اما حقیقت این است که بیشتر سیستمها در شرایط ایدهآل ساخته نمیشوند.
در محدودیت زمان ساخته میشوند.
در محدودیت بودجه.
در فشار کسبوکار.
در شرایطی که اطلاعات کامل در دسترس نیست.
و شاید یکی از نشانههای بلوغ حرفهای این باشد که قبل از قضاوت یک تصمیم، سعی کنیم زمینه شکلگیری آن را بفهمیم.
نه برای اینکه از هر تصمیمی دفاع کنیم.
برای اینکه بدانیم طراحی سیستمها را فقط با نگاه کردن به کد نمیشود ارزیابی کرد.
باید داستان پشت آن کد را هم فهمید.
چون خیلی وقتها چیزی که امروز اشتباه به نظر میرسد،
دیروز بهترین تصمیم ممکن بوده است.
Forwarded from tech-afternoon (Amin Mesbahi)
کوییز:
توی سیستمهای توزیعشده، مخصوصا وقتی چند سرویس به واسطه پیامها، eventها یا APIها با هم sync میشن، Reconciliation Job بیشتر برای چه کاری استفاده میشه؟
توی سیستمهای توزیعشده، مخصوصا وقتی چند سرویس به واسطه پیامها، eventها یا APIها با هم sync میشن، Reconciliation Job بیشتر برای چه کاری استفاده میشه؟
Final Results
13%
جایگزین کردن Message Broker با یک batch job
22%
تضمین exactly-once delivery بین همه سرویسها
57%
مقایسه دورهای وضعیت چند سیستم و پیدا کردن یا اصلاح مغایرتها
5%
حذف نیاز به Outbox/Inbox Pattern
3%
افزایش سرعت response time در APIهای synchronous
Forwarded from .NET Fun
Media is too big
VIEW IN TELEGRAM
🚀 یک Junior Developer باید ۵ الگوی معماری را بداند
⚙️ یک Middle Developer باید ۸ الگوی معماری را بداند
🏗 یک Senior Developer باید ۲۰ الگوی معماری را بداند
در این مرحله، الگوها به شما کمک میکنند ساختار و جریان سیستم را درک کنید. 📚
1️⃣ Layered Architecture
🎨 UI → 🧠 Application → 📦 Domain → 🔧 Infrastructure
تفکیک شفاف مسئولیتها.
2️⃣ Client–Server
🌐 Frontend در مقابل Backend
🔌 APIها به عنوان قرارداد
📨 درخواستهای Stateless
3️⃣ Monolith
📦 یک واحد قابل استقرار
🛠 ساده برای توسعه، دیباگ و درک
✅ بهترین انتخاب پیشفرض
4️⃣ Basic CRUD Architecture
➕ Create
📖 Read
✏️ Update
❌ Delete
پایه و اساس اکثر سیستمهای کسبوکار.
5️⃣ Synchronous Request–Response
🔄 ارتباط ساده مبتنی بر HTTP
🔍 ردیابی و دیباگ آسان
درک کنید که سیستمها چگونه ساختاربندی و به یکدیگر متصل میشوند. 🏗
1️⃣ Modular Monolith
📦 مرزبندی شفاف درون یک Deployable
🧩 ماژولهای مستقل بدون پیچیدگی سیستمهای توزیعشده
2️⃣ API Gateway
🚪 نقطه ورود واحد برای کلاینتها
🔀 Routing
🔐 Authentication
⏱️ Rate Limiting
📊 Aggregation
3️⃣ CQRS (Command Query Responsibility Segregation)
✍️ جداسازی مدلهای خواندن و نوشتن
📈 بهبود Performance و Scalability در صورت نیاز واقعی
4️⃣ Event-Driven Architecture
📨 ارتباط ناهمگام (Asynchronous)
🔗 ءCoupling کمتر بین اجزا
5️⃣ Publish / Subscribe
📢 تولیدکنندهها مصرفکنندهها را نمیشناسند
📡 مناسب برای سناریوهای Fan-Out
6️⃣ Point-to-Point Async Integration
📬 صفها بین سرویسها
✅ تحویل قابل اعتماد پیامها
7️⃣ Outbox Pattern
📦 تضمین ارسال پیام همراه با سازگاری پایگاه داده
🚫 جلوگیری از مشکل Dual-Write
8️⃣ Replication Pattern
📖 ءRead Replica برای مقیاسپذیری خواندن
🟢 افزایش Availability
در این سطح، سیستمهایی طراحی میکنید که در مقیاس بزرگ و تحت بار واقعی دوام بیاورند. 🚀
در اینجا معماری دیگر فقط درباره Patternها نیست؛
بلکه درباره Trade-offها و پیامدهای هر تصمیم است. ⚖️
1️⃣ Saga Pattern
🔄 مدیریت تراکنشهای توزیعشده
🩹 جبران خطا (Compensation) به جای Rollback
2️⃣ Anti-Corruption Layer (ACL)
🛡 محافظت از Domain در برابر سیستمهای خارجی
🚫 جلوگیری از آلودگی مدل دامنه
3️⃣ Strangler Fig Pattern
🌱 مدرنسازی تدریجی
🔄 جایگزینی امن سیستمهای Legacy
4️⃣ Sidecar Pattern
📦 مدیریت Cross-Cutting Concernها خارج از Business Logic
📈 Observability
🔐 Security
🛡 Resilience
5️⃣ Service Discovery Pattern
📍 کشف پویا محل سرویسها
⚙️ ضروری در مقیاس بزرگ
6️⃣ Sharding Pattern
🗂 تقسیم دادهها برای افزایش مقیاسپذیری نوشتن
⚠️ پیچیده اما قدرتمند
7️⃣ Replication + Sharding Trade-offs
⚖️ Consistency در برابر Availability
⚡️ Latency در برابر Correctness
8️⃣ چه زمانی نباید از یک Pattern استفاده کرد؟
❌ Microservices خیلی زود
❌ CQRS بدون نیاز واقعی
❌ Eventها بدون Observability
9️⃣ مسیر تکامل سیستمها
📦 Monolith
➡️ Modular Monolith
➡️ Microservices
🚀 تغییرات تدریجی، نه بازنویسیهای بزرگ
💡 دانستن Patternها شما را Senior نمیکند.
ءSenior بودن یعنی بدانید:
✅ چه زمانی از یک Pattern استفاده کنید.
✅ چه زمانی از آن استفاده نکنید.
✅ و هزینه هر تصمیم معماری را قبل از پرداختن آن بشناسید.
⚙️ یک Middle Developer باید ۸ الگوی معماری را بداند
🏗 یک Senior Developer باید ۲۰ الگوی معماری را بداند
👉 Junior Developer 👨💻
در این مرحله، الگوها به شما کمک میکنند ساختار و جریان سیستم را درک کنید. 📚
1️⃣ Layered Architecture
🎨 UI → 🧠 Application → 📦 Domain → 🔧 Infrastructure
تفکیک شفاف مسئولیتها.
2️⃣ Client–Server
🌐 Frontend در مقابل Backend
🔌 APIها به عنوان قرارداد
📨 درخواستهای Stateless
3️⃣ Monolith
📦 یک واحد قابل استقرار
🛠 ساده برای توسعه، دیباگ و درک
✅ بهترین انتخاب پیشفرض
4️⃣ Basic CRUD Architecture
➕ Create
📖 Read
✏️ Update
❌ Delete
پایه و اساس اکثر سیستمهای کسبوکار.
5️⃣ Synchronous Request–Response
🔄 ارتباط ساده مبتنی بر HTTP
🔍 ردیابی و دیباگ آسان
👉 Middle Developer 👨💻
درک کنید که سیستمها چگونه ساختاربندی و به یکدیگر متصل میشوند. 🏗
1️⃣ Modular Monolith
📦 مرزبندی شفاف درون یک Deployable
🧩 ماژولهای مستقل بدون پیچیدگی سیستمهای توزیعشده
2️⃣ API Gateway
🚪 نقطه ورود واحد برای کلاینتها
🔀 Routing
🔐 Authentication
⏱️ Rate Limiting
📊 Aggregation
3️⃣ CQRS (Command Query Responsibility Segregation)
✍️ جداسازی مدلهای خواندن و نوشتن
📈 بهبود Performance و Scalability در صورت نیاز واقعی
4️⃣ Event-Driven Architecture
📨 ارتباط ناهمگام (Asynchronous)
🔗 ءCoupling کمتر بین اجزا
5️⃣ Publish / Subscribe
📢 تولیدکنندهها مصرفکنندهها را نمیشناسند
📡 مناسب برای سناریوهای Fan-Out
6️⃣ Point-to-Point Async Integration
📬 صفها بین سرویسها
✅ تحویل قابل اعتماد پیامها
7️⃣ Outbox Pattern
📦 تضمین ارسال پیام همراه با سازگاری پایگاه داده
🚫 جلوگیری از مشکل Dual-Write
8️⃣ Replication Pattern
📖 ءRead Replica برای مقیاسپذیری خواندن
🟢 افزایش Availability
👉 Senior Developer 👨💻
در این سطح، سیستمهایی طراحی میکنید که در مقیاس بزرگ و تحت بار واقعی دوام بیاورند. 🚀
در اینجا معماری دیگر فقط درباره Patternها نیست؛
بلکه درباره Trade-offها و پیامدهای هر تصمیم است. ⚖️
1️⃣ Saga Pattern
🔄 مدیریت تراکنشهای توزیعشده
🩹 جبران خطا (Compensation) به جای Rollback
2️⃣ Anti-Corruption Layer (ACL)
🛡 محافظت از Domain در برابر سیستمهای خارجی
🚫 جلوگیری از آلودگی مدل دامنه
3️⃣ Strangler Fig Pattern
🌱 مدرنسازی تدریجی
🔄 جایگزینی امن سیستمهای Legacy
4️⃣ Sidecar Pattern
📦 مدیریت Cross-Cutting Concernها خارج از Business Logic
📈 Observability
🔐 Security
🛡 Resilience
5️⃣ Service Discovery Pattern
📍 کشف پویا محل سرویسها
⚙️ ضروری در مقیاس بزرگ
6️⃣ Sharding Pattern
🗂 تقسیم دادهها برای افزایش مقیاسپذیری نوشتن
⚠️ پیچیده اما قدرتمند
7️⃣ Replication + Sharding Trade-offs
⚖️ Consistency در برابر Availability
⚡️ Latency در برابر Correctness
8️⃣ چه زمانی نباید از یک Pattern استفاده کرد؟
❌ Microservices خیلی زود
❌ CQRS بدون نیاز واقعی
❌ Eventها بدون Observability
9️⃣ مسیر تکامل سیستمها
📦 Monolith
➡️ Modular Monolith
➡️ Microservices
🚀 تغییرات تدریجی، نه بازنویسیهای بزرگ
💡 دانستن Patternها شما را Senior نمیکند.
ءSenior بودن یعنی بدانید:
✅ چه زمانی از یک Pattern استفاده کنید.
✅ چه زمانی از آن استفاده نکنید.
✅ و هزینه هر تصمیم معماری را قبل از پرداختن آن بشناسید.