🔓🔓 مرور ۱۰ ریسک مهم امنیتی API طبق OWASP 2023 (بخش دوم)

» در ادامه بخش اول

6️⃣تهدید API6: Unrestricted Access to Sensitive Business Flows
دسترسی بدون کنترل به فرآیندهای حیاتی

زمانی که API بدون احراز هویت یا محدودیت خاصی به عملیات مهم مثل ثبت‌نام، پرداخت یا بازیابی رمز عبور اجازه می‌ده.

مثال:
بات‌ها بتونن میلیون‌ها ثبت‌نام جعلی انجام بدن، یا فراموشی رمز عبور رو بارها صدا بزنن.

روش‌های جلوگیری:
- نرخ‌گذاری (rate limiting) و CAPTCHA.
- احراز هویت برای عملیات حساس.
- مانیتور کردن رفتارهای غیرعادی.

7️⃣تهدید API7: Server Side Request Forgery (SSRF)
جعل درخواست از سمت سرور

زمانی که کاربر مجاز است تا URLهایی رو به API بفرسته تا در نهایت سرور آن‌ها را بخواند (مثلاً برای preview یا دانلود)، اینجاست که ممکنه مهاجم از این امکان سوءاستفاده کنه.

مثال:

POST /api/fetch?url=http://internal.service.local/admin

روش‌های جلوگیری:

- اعتبارسنجی URLهای ورودی و لیست سیاه / سفید کردن مقصدها.
- جلوگیری از دسترسی به IPهای داخلی (مثلاً 127.0.0.1).
- محدود کردن دامنه‌ی درخواست‌های سرور.

8️⃣تهدید API8: Security Misconfiguration
پیکربندی امنیتی اشتباه

تنظیمات اشتباه مثل فعال بودن دیباگ، خطایاب‌ها، یا endpointهای داخلی در محیط تولید، باعث آسیب‌پذیری می‌شه.

مثال:
- فعال بودن Swagger UI یا StackTrace در محیط production.

روش‌های جلوگیری:
- استفاده از DevSecOps و اسکن مداوم پیکربندی‌ها.
- حذف یا غیرفعال کردن endpointهای غیرضروری در production.
- اعمال هدرهای امنیتی.

9️⃣تهدید API9: Improper Inventory Management
مدیریت نادرست موجودی API

نبود فهرست دقیق از APIها، نسخه‌ها، محیط‌ها و وضعیت‌های هر endpoint ممکن است باعث شه تا برخی از APIهای قدیمی یا ناامن در دسترس باقی بمونن.

مثال:
- وجود API نسخه‌ی v1 که هنوز فعالن ولی دیگه نگهداری و تو توسعه و نظارت ندارن.

روش‌های جلوگیری:
- مستندسازی و نسخه‌بندی دقیق APIها.
- استفاده از ابزارهایی برای کشف خودکار APIها مثل API gateways.
- اسکن دوره‌ای برای یافتن APIهای ناشناخته.

0️⃣1️⃣تهدید API10: Unsafe Consumption of APIs
مصرف ناامن APIهای خارجی

استفاده از APIهای خارجی بدون اعتبارسنجی پاسخ‌ها یا اعتماد بی‌جا ممکنه باعث وارد شدن داده‌های جعلی یا مخرب بشه.

مثال:
- اتکا به داده‌ی مالی از API خارجی بدون بررسی امضا یا صحت داده.

روش‌های جلوگیری:
- بررسی دقیق پاسخ API خارجی قبل از استفاده.
- محدود کردن منابع مورد اعتماد.
- قرار دادن تایم‌اوت و بررسی JSON schema.

💬 نظر؟ سوال؟ تجربه؟

اگر تمایل داشتید بیشتر در مورد مفاهیم تولید امن نرم‌افزار، و نرم‌افزار امن بدونید، این دو قسمت پادکست رو قبلا ضبط کردم:

بخش اول:
- معرفی SSDLC
- معرفی SDL
- مفهوم Shift-left testing
- مدلس‌ازی تهدیدات امنیتی (Threat Modeling) با استفاده از STRIDE

بخش دوم:
- معرفی Static Application Security Testing (SAST)
- معرفی Dynamic Application Security Testing (DAST)
- معرفی Interactive Application Security Testing (IAST)
- معرفی Runtime Application Self-Protection (RASP)
- معرفی Software Composition Analysis (SCA)
- مفهوم Safe Codingو Security by Design و Secure Coding
- مفهوم Defensive Programming, Defensive Design, Offensive Programming
- سرفصل‌های دوره CSSLP

🍰🚀 معماری Vertical Slice

مقدمه
طراحی معماری نرم­‌افزار همیشه تلاشی بوده برای اینکه پیچیدگی‌ها رو مهار، تغییرات رو ساده، و تیم رو چابک نگه داره. چندین ساله که در گفتگوها Clean Architecture رو زیاد می‌شنویم و گویی که لازمه داشتن یک معماری خوب اینه که اول clean رو پیاده کنیم، بعد به سایر جنبه‌ها فکر کنیم!! طی «حداقل» این پست، مقایسه‌ای خواهیم داشت بین معماری vertical slice و clean، و بعد تفاوت‌ها و شباهت‌ها، مزایا و معایب، و در نهایت سناریوهای انتخاب رو مرور خواهیم کرد.


فبل از شروع دو تا مفهوم رو مرور کنیم:
- وابستگی یا Coupling:
میزان وابستگی بخش‌های مختلف سیستم به همدیگه. tight coupling یعنی تغییر یک بخش، می‌تونه بخش دیگه‌ای رو خراب کنه. loose coupling اجازه می‌ده بخش‌های مختلف سیستم، مستقلا تکامل و تغییر داشته باشن
.
- همبستگی یا Cohesion:
تناسب و یکدستی عناصر داخل یک ماژول. high cohesion یعنی همهٔ اجزای ماژول یک هدف روشن دارند و چون یک هدف رو دنبال می‌کنن درکشون ساده‌تره؛ low cohesion یعنی کدهای بی‌ربط کنار هم‌ قرار گرفتن.

خلاصه‌ اینکه Coupling → «چقدر به هم وابسته‌ایم؟»
و Cohesion → «چقدر به هم متعلقیم؟»

ایده اصلی clean architecture رو uncle bob معروف سال ۲۰۱۲ طرح کرد، اونم با هدف اینکه جهت وابستگی باید همیشه به سمت «درون» باشه و درونی‌ترین لایه هم که domain است، ولی این صورت ماجراست، هدف اصلی‌ کاهش وابستگی‌ها (control/loose coupling) بود. گاهی (که بعدن توضیح می‌دم کجا) پَرش بین پوشه‌ها و کدهای مختلف زیاد و دشوار می‌شه؛ چرا؟ چون تقسیم‌بندی و جداسازی کدها براساس ماهیت تکنیکال اون‌ها انجام شده، مثلا همه سرویس‌ها زیر پوشه سرویس‌ها، همه کامندها زیر پوشه کامندها و...

حالا vertical slice تقسیم‌بندی رو بر اساس use caseها یا featureها انجام می‌ده، یعنی همه مفاهیم تکنیکال مرتبط با یک feature (قابلیت) کنار هم قرار خواهند گرفت. اینجوری cohison بالاتر و complexity کمتر خواهد شد و مدیریت راحت‌تر خواهد بود. مثل یک قطعه از کیک که تمام لایه‌ها رو با هم داره 🍰
معماری Vertical Slice رو Jimmy Bogard سال ۲۰۱۸ در کنفرانس NDC سیدنی معرفی رسمی کرد با اینکه ایده اولیه‌اش رو از ۲۰۱۵ مطرح می‌کرد. شاید بد نباشه بدونید Jimmy Bogard خالق AutoMapper, MediatR و Respawn است.

مقایسه ساختاری:

Clean Architecture Sample:

┬ src
├── Domain
│   └── Entities/
├── Application
│   └── UseCases/
├── Infrastructure
│   └── Persistence/
└── WebApi
    └── Controllers/

Vertical Slice Architecture Sample:

┬ src
├── Orders
│   ├── Create
│   │   ├── Command.cs
│   │   ├── Handler.cs
│   │   ├── Validator.cs
│   │   └── Tests/
│   └── Cancel/...
└── Shared/...

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

💬 نظر و تجربه شما چیه؟ دوست دارید روی این موضوع عمیق‌تر شیم؟

🗺🚀 روایت ۳۰ تا ۴۰ سالگی – استراتژی‌ها و تغییرات مسیر (بخش اول)

این مطلب دنباله‌ی روایت ۲۰ تا ۳۰ سالگی است که پیش‌تر در دو بخش نوشتم، بخش اول و بخش دوم
⚠️ این سری مطالب، نه وحی هستند نه نسخه‌ی جهان‌شمول موفقیت! فقط روایتی از بلند فکر کردن؛ و امیدوارانه، یادآوری یا پیشنهاد برخی نکات. هر کس نسخه‌ی خودش رو داره و بهتره تا راه خودش رو پیدا کنه...

اگر دههٔ ۲۰ تا ۳۰ سالگی رو «مرحلهٔ کاشت» قلمداد کنیم، دههٔ ۳۰ تا ۴۰ سالگی، زمانِ مراقبت و هَرسِ هوشمندانه است. حالا دیگه صرفاً «جونیور مشتاق» نیستیم؛ احتمالاً عنوان‌های Senior Engineer، Tech Lead یا حتی Engineering Manager رو تجربه می‌کنیم. مسئولیت‌ها (مثل خانواده، وام، سلامت) احتمالا بیشتر شده و زمان آزاد، کمتر؛ بنابراین باید عمیق‌تر اما هوشمندانه‌تر سرمایه‌گذاری کنیم. از طرفی برای برخی افراد حتی این دهه، زمان تغییر مسیر، و شروع جدیدیه، و اگرچه دشوارتر از دهه ۲۰ است ولی هنوز هم می‌شه در صورت سخت‌کوشی و تصمیم هوشمندانه، جبران کرد.
دههٔ ۳۰ زندگی؛ دوره‌ایه که نشانه‌های پختگی کم‌کم خودشون رو نشون می‌دن. در این سال‌ها احتمالا مسیر شغلی‌تون شکل مشخص‌تری گرفته، مهارت‌هاتون عمیق‌تر شده و البته زندگی شخصی‌تون پررنگ‌تر از قبل شده. دههٔ ۳۰ یک دوران گذار مهمه: از جوانی جسورانهٔ ۲۰ سالگی به سمت میانسالی مسئولانه. مخاطب اصلی این نوشته همچنان دوستان نرم‌افزاری هستن، هرچند بسیاری از نکات می‌تونه برای عموم هم مفید باشه.

⏳ حالا چرا دههٔ ۳۰ سرنوشت‌سازه؟

🔤 انباشت تجربه: خروجیِ یک ساعت کار شما حالا ضرب در ۱۰ سال تجربه می‌شود؛ پس کیفیت تصمیم‌ها بسیار مهم‌تره.
🔤 ناحیهٔ آرامش (Comfort Zone) بزرگ می‌شه؛ وسوسهٔ درجا زدن و «عنوان‌بازی» خیلی جدّیه.
🔤 فشارهای موازی: رشد شغلی، رشد خانواده، ثبات مالی و سلامت رو باید هم‌زمان مدیریت کنید.

🛠 استراتژی‌های فنی و شغلی

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

➕ تخصص عمیق + دید وسیع
🔤یک حوزه رو «گوش‌تا‌گوش» بلد باشید (مثلاً Cloud‑Native Scalability یا Data‑Engineering).
🔤سالی یک تکنولوژی مجاور با تخصصتون رو در سطحِ Production یاد بگیرید؛ (در این‌باره بعدتر گپ‌ می‌زنیم).

➕ معماری سیستم‌ها
🔤الگوهای پیشرفته‌تر (مثل سیستم‌های موازی یا توزیع‌شده یا موارد متناسب با تخصصتون) رو نه در تئوری، بلکه در عمل یاد بگیرید و تمرین کنید.
🔤برای هر تصمیم، Trade‑off Diary بسازید: هر تصمیم معماری و دلیلش رو مستند کنید؛ بعداً ارزشش رو خواهید دونست.

➕ رهبری فنی و Mentorship
🔤کدریویوِ هدفمند و عمیق رو یاد بگیرید؛ تمرکز بر فهم و کیفیت‌آزمایی، نه مچ‌گیری.
🔤از نظر فنی و انتقال دانش، زیر بال‌وپر هر همکار و دوستی رو که می‌گیرید، خودتون دو برابر یاد می‌گیرید.

➕ زبان کسب‌وکار
🔤خروجی فنی رو به ROI ترجمه کنید؛ تصمیم‌گیران به هزینه/سود حساس‌اند، از یه سنی به بعد از شما انتظاری فراتر از نوشتن کد باکیفیت می‌ره، باید نتیجه و اثر کار فنی توجیه و هدف داشته باشه.
🔤مفاهیم Product، KPI، و استراتژی بازار رو در حد مکالمهٔ حرفه‌ای بلد باشید.

➕ شبکه‌سازی استراتژیک
🔤 توی ایونت‌ها و کنفرانس‌ها کمتر دنبال سلفی گرفتن و گیفت جمع کردن و خالی‌بستن برای افراد باشید؛ بیشتر دنبال بحث عمیق بگردید.
🔤 حداقل دو «Peer Group» ثابت برای تبادل چالش‌های معماری بسازید.


💡 سرمایه‌گذاری روی خودتون
🔤 به‌صورت دوره‌ای System Design Interviews رو نه برای مصاحبه، بلکه برای ارتقای تفکر ساختارمند تمرین کنید.
🔤 نوشتن و صحبت: بلاگ فنی، پادکست، وبینار یا ورکشاپ؛ بخشی از برندسازی فردیه که توی دهه ۳۰ پررنگ‌تر می‌شه، ولی نسخه‌ی همه نیست. از طرفی انتظار می‌ره حداقل در حد ارائه مطلب توی تیم خودتون یا نوشتن مستندات فنی عمیق برای تیم و شرکتتون توانایی لازم رو کسب کنید.
🔤 خوندن موضوعات مدیریت تکنولوژی یا استراتژیک یا حتی دورهٔ «Product for Engineers» می‌تونه برای نیمه دوم دهه ۳۰ مفید باشه (نه برای همه، بلکه برای افرادی که حوزه نرم‌افزارهای LOB کار می‌کنن، یعنی بخش اعظمی از نرم‌افزارها)

📌 بخش دوم روایت ۳۰ تا ۴۰ سالگی، شامل تعادل زندگی-کار، امنیت مالی، و دام‌های رایج دهه‌ی ۳۰ خواهد بود 😊
💬 خوشحال می‌شم تا نظرتون رو بشنوم...

🗺🚀 🚀 روایت ۳۰ تا ۴۰ سالگی – استراتژی‌ها و تغییرات مسیر (بخش دوم)

در قسمت اول این پست نوشتم که دههٔ ۳۰ تا ۴۰ سالگی زندگی فقط به رشد فنی خلاصه نمی‌شه. و بخش قابل توجهی از چالش‌ها و تغییرات این دوره، معطوف به موضوعاتی مثل تعادل بین زندگی و کار، امنیت مالی، سلامت روان و جسم، و حتی نوع رابطه‌مون با خودمون و دیگرانه. در این قسمت به این نکات دقیق‌تر نگاه می‌کنیم:

🌱 تعادل زندگی و کار: توهم یا ضرورت؟

بعضی وقتا «Work‑Life Balance» بیشتر شبیه یه شعار قشنگه تا واقعیت. اما معنیش این نیست که نمی‌شه براش تلاش کرد. باید به بازتعریف موفقیت فکر کرد! در ۲۰ سالگی شاید تعریف موفقیت براتون بیشتر معطوف به کار و دستاوردهای شغلی بود، اما در این دهه احتمالاً ارزش بیشتری برای سایر جنبه‌های زندگی قائل می‌شید. ممکنه تشکیل خانواده داده باشین، یا مسئولیت مراقبت از والدین به دوشتون باشه، یا حتی علایق شخصی جدیدی کشف کرده باشین. لذا خوبه تا تعریف موفقیت، تعریف شادی و زندگی رو دوباره و بدون سوگیری نسبت به باورهای قبلی مرور کنین...

🕒 مدیریت زمانِ چندلایه
چارچوب ۵۰–۳۰–۲۰: ۵۰٪ کار اصلی، ۳۰٪ بهبود فرآیند و یادگیری تیمی، ۲۰٪ R&D شخصی شاید برای شما هم خوب باشه.
«نه» گفتن به پروژه‌های کم‌ارزش، مهارتی حیاتیه.

💪 سلامت جسم و ذهن
تمرین قدرتی برای پیشگیری از صدمات اسکلتی در دهه‌های بعد.
دیجیتال دیتاکس گاه‌به‌گاه: هر از گاهی، شاید حتی ۶ ماهی یک‌بار، یک روز بدون لپ‌تاپ و موبایل؛ رو به «فکر کردن و مرور گذشته و بررسی آینده» تخصیص بدید.

💰 امنیت مالی
پس‌انداز Emergency Fund معادل ۶ ماه هزینهٔ زندگی.
سرمایه‌گذاری به جای صرفا پس‌انداز کردن.
مشارکت در سهام شرکتی یا طرح‌های ESPP/ESOP یا ETF/CFD اگر قابل‌دسترس یا مقدور است.

🕸 دام‌های رایج دههٔ ۳۰ تا ۴۰

✖️ عنوان‌زدگی: مثل «Architect» شدن روی کاغذ، بدون تجربهٔ تولیدی واقعی.

✖️ شوآف‌های و عدم تعمیق و تمرکز: مثل سراغ هر فریم‌ورک و زبون و فیلان جدید رفتن، صرفاً برای فرار از عمیق شدن، تنوع و شوآف!

✖️ فرسودگی (Burnout): کار ۶۰+ ساعت در هفته به‌قیمت فروپاشی زندگی؛ نشونه‌ی مدیریت زمان بده، نه تعهد؛ مگر اینکه کار واقعی ارزش‌آفرین و عمیق فنی باشه.

✖️ پایین نگه‌داشتن دستمزد: از مذاکرهٔ حقوق نترسید؛ «ارزش» رو به «اعداد» ترجمه کنید، در عین حال از توهم ارزش فراری باشید (روی فولکس‌قورباغه برچسب قیمت رولزرویس نچسبونید! روی رولزرویس خیالی یا فقط روی کاغذ هم همین‌طور!)

🔻 دام مقایسه‌گری: شبکه‌های اجتماعی و لینکدین باعث می‌شن دائم حس کنیم عقبیم. یادمون بره که هر کسی داستان خودش رو داره؛ بعضی‌ها هم فقط ویترین این شبکه‌ها هستن و پشتشون خالیه!

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

🔻 دام تکنولوژی‌زدگی: خودتون رو فقط با ابزار و فریم‌ورک تعریف نکنید. درک مفاهیم بنیادی، تفکر سیستمی، و مهارت‌های نرم، سرمایه‌های پایدارتری هستن.


🖼 آینهٔ درونی: بازنگری، نه سرزنش

دههٔ ۳۰ فرصتیه برای بازتعریف اهداف، مرور ارزش‌ها، و اصلاح مسیر. نه برای سرزنش خودتون، بلکه برای ساختن نسخهٔ بهتر و متعادل‌تر از خودتون. روی خود قبلی‌تون تعصب نداشته باشین!

🔹 هر شش ماه یک‌بار، یه بازنگری ساده: «کجا بودم؟ الان کجام؟ کجا می‌خوام برم؟»
🔹 برای بعضی‌ها، نگه‌داشتن یه دفترچه شخصی یا گفت‌وگو با یک مربی/منتور، بسیار اثربخش بوده.

📌 جمع‌بندی
دههٔ ۳۰ ترکیبی از فرصت‌های درخشان و دام‌های پنهانه. نه باید با غرور دهه‌ی ۲۰ ادامه بدیم، نه با ترس از ۴۰ دست و پامون رو ببندیم. «هُشیار و متعادل بودن» شاید ساده‌ترین اما عمیق‌ترین توصیه‌ برای این دوران باشه.

💬 ممنون که همراه این روایت بودید. مشتاقم بدونم برای شما، مهم‌ترین تغییر یا درس دههٔ ۳۰ چیه؟

اگر و اگر این سری پست‌ها رو مفید دونستید، گفتن این نکته لازمه که محدودیت‌های مدیوم تلگرام دلیل خلاصه‌سازی زیاد چنین پست‌هاییه و جای بحث زیاده...

🎯 تحلیل پویای برنامه یا Dynamic Program Analysis (DPA) چیه و چه کمکی می‌کنه؟

روال معمول اینه که ما قبل از اجرای برنامه، کدمون رو بررسی می‌کنیم؛ خطاهای کامپایل رو برطرف می‌کنیم و اگر دقیق‌تر باشیم هشدارهای IDE نتایج ابزارهایی مثل sonar که به static code analyzer می‌شناسیم رو هم چک می‌کنیم. برخی شرکت‌ها هم قوانین static analysis خودشون رو دارن تا کدهاشون یک‌دست باشه. برخی هم architecture validation رو هم اضافه می‌کنن که به صورت خودکار کنترل بشه که از چارچوب‌های معماری کسی تخطی نکرده باشه.

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

برای چنین مواردیه که تحلیل پویا (Dynamic Program Analysis) وارد میشه.

📌 تحلیل پویای برنامه یعنی چی؟ یعنی بررسی و تحلیل رفتار واقعی برنامه در زمان اجرا.
این ابزارها به ما کمک می‌کنن تا بدونیم:

✅ آیا حافظه درست آزاد می‌شه؟
✅ چه توابعی بیشتر از بقیه CPU مصرف می‌کنن؟
✅ کجا گلوگاه عملکرد داریم؟
✅ چه مسیرهایی از کد اصلاً اجرا نشدن؟ (برای تست‌نویسی مهمه!)
✅ آیا در حالت مالتی‌ترد، مشکل Race داریم؟
✅ و حتی مموری‌لیک یا مصرف غیرعادی منابع داریم یا نه؟

فرض کنیم نرم‌افزار کند شده، اما نمی‌دونیم چرا. با چشم هم نمی‌تونیم بفهمیم چون کد به ظاهر درست کار می‌کنه.
یا مثلاً متوجه می‌شیم با هر بار اجرای یه اکشن ساده، حافظه مصرفی داره زیاد و زیادتر می‌شه!
یا نمی‌دونیم واقعاْ چه میزان از کدهایی که نوشتیم با تست‌ پوشش داده شده

برای دونستن پاسخ این پرسش‌ها ابزارهای تحلیل پویا کمک می‌کنن.

💡 مثال:

فرض کنین یه برنامه ساده داریم برای گرفتن اطلاعات کارکنان از API و ذخیره در دیتابیس:

public async Task ProcessEmployeesAsync()
{
    var employees = await _employeeApi.GetAllAsync();

    foreach (var emp in employees)
    {
        var dbEmp = _mapper.Map<EmployeeEntity>(emp);
        await _dbContext.Employees.AddAsync(dbEmp);
    }

    await _dbContext.SaveChangesAsync();
}

همه چی در ظاهر درسته. ولی با ابزارهای تحلیل پویا مثل dotTrace یا Visual Studio Profiler می‌شه فهمید:

🕵🏻‍♂️متد AddAsync در هر حلقه باعث افزایش latency شده (باید به جای AddAsync از AddRange استفاده کنیم)

🕵🏻‍♀️زمان زیادی صرف Map کردن شده، که نشون می‌ده AutoMapper بهینه نیست برای حجم بالا

🕵️‍♀️حافظه بعد از اجرای متد خالی نمی‌شه => مموری‌لیک محتمله

🛠 ابزارهای معروف دات‌نتی

🔨 Visual Studio Diagnostic
Profiler و Memory analyzer داخلی

🔨 JetBrains dotTrace / dotMemory
Memory and Performance Analysis دقیق و با جزيیات

🔨 Coverlet
Code coverage analysis

🔨 BenchmarkDotNet
Detailed performance analysis

تحلیل پویای برنامه یه ابزار لوکس نیست، یه ضرورته وقتی:

🔤با کدهای حساس به performance سر و کار داریم
🔤دنبال مشکلات حافظه، CPU، async و... می‌گردیم
🔤می‌خوایم مطمئن شیم تست‌هامون واقعاً کد رو پوشش دادن
🔤برنامه‌مون قراره تو محیط واقعی و سنگین اجرا شه

حالا ابزارهایی مثل خانواده محصولات JetBrains و ابزارهای درونی Visual Studio مرتبا تلاش می‌کنن تا به سمت تحلیل «زنده»تر برن، و تحلیل‌های عمیق‌تری بدن.
نداشتن ضابطه‌ی تحلیل پویا توی تیم، خیلی جاها ضعف محسوب می‌شه؛ مثل نداشتن یونیت‌تست، یا e2e تست و... یکی از نشونه‌های بلوغ محصول و تیم، داشتن DPA به عنوان بخشی از مراحل CI/CD است که اجازه نده کدی که قوانین رو معیارهای کیفی رو پاس نکرده وارد برنچ پروداکشن یا استیج بشه.

شاید از دید برخی تیم‌ها و شرکت‌ها فانتزی باشه، ولی هرچقدر که به فانتزی بودنش فکر کنن همون‌قدر از پاسخ اینکه «چرا اینقدر محصولاتمون بی‌کیفیت و غیراستاندارد است» دور می‌شن...

💬 نظر و تجربه شما چیه؟ فانتزیه؟ مانع استفاده ازش (یا هر مفهوم کیفی مشابه) چیه؟

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

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

جلسات یک‌به‌یک (One-on-One یا 1:1) یکی از ابزارهای پایه‌ای لیدرشیپ محسوب می‌شن که فرصت مناسبی رو برای ایجاد ارتباط عمیق‌تر و هدفمند بین عضو تیم و رهبر تیم فراهم می‌کنن. این جلسات از جلسات معمول کاری متمایز هستن و به‌جای تمرکز روی وظایف روزمره، بر توسعه فردی، بهبود روابط کاری، و رشد متقابل تأکید دارن.

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

دلیل اینکه گاهی جلسات یک‌به‌یک تبدیل می‌شن به جلسات بیهوده، ادایی یا حتی گاها بازجویی و ممیزی، فقدان یا ضعف مهارت‌ها و خصوصیاتی که ذکر کردم در لیدر است. لیدری که خودش صلاحیت و پختگی هدایت و راهنمایی رو نداره؛ مهارت دقیق شنیدن و درک کُنج‌های رفتاری رو نداره، نمی‌تونه جلسات خوبی رو برگزار کنه.

🎯 اهداف استراتژیک جلسات یک‌به‌یک

- دریافت بازخورد عملکردی: شناسایی نقاط قوت و فرصت‌های بهبود
- مطرح کردن چالش‌های کاری: حل مسائل عملیاتی و رفع موانع
- برنامه‌ریزی مسیر رشد: تعیین اهداف توسعه فردی و شغلی
- بهبود دینامیک تیم: ارائه ایده‌ها برای بهبود فرآیندها و همکاری
- درخواست منابع و حمایت: تأمین ابزار و آموزش‌های مورد نیاز

اهداف ثانویه:
- تقویت اعتماد متقابل
- افزایش انگیزه و تعلق سازمانی
- پیشگیری از فرسودگی شغلی
- ایجاد فرهنگ یادگیری مستمر

📆 تناوب و زمان‌بندی علمی

هر ۲ تا ۴ هفته یک‌بار - این بازه بر اساس تحقیقات رفتار سازمانی و تجربیات شرکت‌های پیشرو تعیین شده. زمانش هم ۳۰ تا ۴۵ دقیقه برای جلسات معمول و ۶۰ دقیقه برای جلسات فصلی یا سالانه.

چرا این تناوب؟
- کوتاه‌تر از ۲ هفته: ممکنه به سطحی‌سازی منجر بشه
- بیشتر از ۴ هفته: باعث ضعیف شدن ارتباط و انباشت مسائل می‌شه
- انعطاف‌پذیری: در دوره‌های پروژه‌های حساس یا تغییرات سازمانی می‌شه تناوب رو افزایش داد

🛠 آمادگی برای جلسه

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

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

🤔 آماده‌سازی مثال‌های عینی:
- مثال‌های موفق: پروژه‌/کاری که خوب انجام دادین
- چالش‌های خاص: مشکلی که نیاز به راهنمایی دارین
- اهداف رشد: مهارت یا موقعیتی که می‌خواهید کسب کنین

🧘‍♀️ آماده‌سازی ذهنی:
- ذهن باز و پذیرا داشته باشین
- انتظارات واقع‌بینانه‌ای رو تعریف کنین
- فضای امن برای صحبت آماده کنین

🗣 هنر گفت‌وگوی مؤثر در جلسه

صداقت سازنده:
- شفافیت: مسائل رو بدون پرده‌پوشی بیان کنین
- سازندگی: همراه با مشکل، راه‌حل پیشنهاد بدید (نقد بدون پیشنهاد راهکار عموما نِق زدن تلقی می‌شه)
- احترام: از زبان محترمانه و حرفه‌ای استفاده کنین

رویکرد راه‌حل‌محور:
- توصیفی نه قضاوتی: رفتارها و نتایج رو توصیف کنین، نه شخصیت افراد رو
- تأثیر‌محور: درباره تأثیر مسائل روی کار و تیم صحبت کنین
- آینده‌نگر: روی راه‌حل‌ها و بهبود آینده تمرکز کنین

💬 نظر و تجربه‌تون رو حتمن بگید، خوشحال می‌شم بشنوم. در ضمن در صورت استقبال بخش بعد به مثال‌هایی از گفتگو سازنده و غیرسازنده + ساختار پیشنهادی خواهم پرداخت و باز هم در صورت استقبال، مطلب بعدترش، از منظر تیم‌لیدر...

📌 چطور جلسات یک‌به‌یک سازنده و مفید داشته باشیم؟ بخش دوم، از منظر لیدر

توی قسمت اول در مورد جلسه یک‌به‌یک و چجوری برگزار کردنش از منظر عضو تیم نوشتم. این قسمت می‌شنیم اون سمت میز و از نگاه تیم‌لید به موضوع نگاه می‌کنیم. فرق یه تیم سالم و تیمی که داره از درون می‌پاشه، خیلی وقت‌ها توی همین نیم‌ساعت‌های یک‌به‌یک مشخص می‌شه. اما فقط "داشتن" جلسه یک‌به‌یک کافی نیست؛ باید "بلد بود" که چجوری اون رو به یک گفت‌وگوی رشدآفرین تبدیل کرد و «تعهد» به رشد و توسعه اعضاء تیم رو ثابت کرد.

🧰 ویژگی‌های تیم‌لید آماده برای جلسه ۱:۱

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

📝 آمادگی قبل از جلسه برای مدیر

🔤 باید نگاهی به فعالیت‌های فرد بندازه (PRها، مشارکت‌ها، صحبت‌ها)
🔤نوت‌های جلسه قبل رو مرور کنه و ببین قول‌هایی که داده انجام شده یا نه
🔤اگر بازخورد داره، با مثال و دقت آماده می‌کنه (نه کلی‌گویی)
🔤یک فضای امن و بی‌تنش فراهم می‌کنه

💡 نکات کلیدی و رویکرد ذهنی مناسب

➖ سؤال بپرس، سخنرانی نکن: از جنس «چه چیزی می‌تونم بهتر انجام بدم؟»
➖ ایجاد تعهد به جای اجبار: فرد باید احساس کنه بخشی از راه‌حل‌هاست
➖ بازخورد دوطرفه باشه: خودت هم مشتاق شنیدن بازخورد باش
➖ نقش کوچ داشته باش نه مدیر پروژه: این جلسه جای ابلاغ وظایف نیست

❓ آیا هر کسی می‌تونه ۱:۱ خوب برگزار کنه؟

«نه». برگزاری جلسه یک‌به‌یک موثر، نیازمند بلوغ حرفه‌ای، مهارت شنیدن، و نگرش انسانی به تیم؛ در کنار تجربه و دانش است. بدون یاد گرفتن و تمرین کردن این مهارت‌ها نتیجه‌ی مطلوب محاله!

#️⃣ اگر دوست داشتید کلیدواژه یا سرنخ برای بیشتر خوندن داشته باشید، پیشنهادم:

Active Listening
Coaching/Growth Mindset
GROW model (coaching framework)
Psychological Safety
Radical Candor
Co-Active Coaching
Mindset Shift

💬 نظر و تجربه شما به عنوان لیدر یا عضو تیم از ۱:۱ چیه؟

#️⃣ در ستایش اعداد...
1️⃣ قسمت اول: کُدمتریکس

وقتی به جای «حس» و معیارهای کیفی، بریم سراغ معیار «کمی» و خصوصا «اعداد»، خیلی از مشکلات رو می‌شه زودتر شناسایی کرد، راهکارهای بهتری براشون پیدا کرد؛ و حتی توی گفت‌و‌گوها از جدل دور شد. در این پست و شاید پست‌های احتمالی بعدی، در معرفی و ستایش اعدادی می‌نویسم که به ما کمک می‌کنن تا بهتر کار کنیم و کار بهتر کنیم... مثل اعدادی که می‌شه از کُد بیرون کشید، اعدادی که می‌شه از دل جیرا (یا هر ابزار مدیریت تسک دیگه) بیرون کشید، اعدادی که می‌شه از API یا زیرساخت بیرون کشید...

❓ ابزارهایی مثل Code Metrics با اندازه‌گیری کمی کیفیت کد، نقاط ضعف رو شناسایی و فرصتی برای بازبینی فراهم می‌کنن.
شروع رو به معرفی metricهای رایج می‌پردازم، و بعد به صورت مفصل‌تر روی Cyclomatic Complexity صحبت می‌کنیم که یکی از پرکاربردترین معیارهای تخمین پیچیدگی و تعداد مسیرهای اجرایی بسته‌شده توی تابع یا کلاسه.

📈 انواع رایج Code Metrics

➖متریک Cyclomatic Complexity (CC): این شاخص، پیچیدگی منطقی کد رو بر اساس تعداد مسیرهای مستقل اجرا در یک تابع یا متد اندازه‌گیری می‌کنه. هر عبارت شرطی، حلقه یا انشعاب جدید، این عدد رو افزایش می‌ده. پیچیدگی بالا نشون‌دهنده‌ی کد دشوارتر برای درک، تست، و نگهداریه. معمولاً پیچیدگی کمتر از ۱۰ مطلوب، بین ۱۰ تا ۲۰ قابل قبول و بالاتر از ۲۰ نیازمند بازطراحیه.

➖متریک Lines of Code (LOC): این شاخص، تعداد خطوط کد موجود در یک پروژه یا ماژول رو اندازه‌گیری می‌کنه. معمولاً به دو صورت SLOC (Source Lines of Code) که شامل خطوط حاوی کد اجراییه و KLOC (Kilo Lines of Code) که هر هزار خط کد رو نشون می‌دن، ارائه می‌شه. این متریک اگرچه ساده است اما می‌تونه شاخص تقریبی از پیچیدگی و حجم پروژه باشه، هرچند نمی‌تونه به تنهایی کیفیت کد رو تعیین کنه.

➖متریک Maintainability Index (MI): این شاخص ترکیبیه که کیفیت نگهداری کد رو بر اساس عوامل مختلف از جمله پیچیدگی، حجم کد، تکرار و مستندات محاسبه می‌کنه. مقدارش بین ۰ تا ۱۰۰ است که عدد بالاتر نشون‌دهنده کد قابل نگهداری‌تره. این متریک به توسعه‌دهنده‌ها کمک می‌کنه تا قسمت‌های کد که نیاز به بهبود داره رو شناسایی کنیم.

➖متریک Cognitive Complexity: یکی از متریک‌های مدرن و پیشرفته‌تر برای اندازه‌گیری پیچیدگی کده که برخلاف Cyclomatic Complexity که صرفاً تعداد مسیرهای اجرا رو می‌شماره، تمرکز اصلیش روی میزان دشواری درک کد از دیدگاه ذهن انسانه. هدف اصلیش پیش‌بینی میزان تلاش ذهنی مورد نیاز برای خوندن، درک و اصلاح کده.

➖ متریک Depth of Inheritance: یکی از متریک‌های مهم در برنامه‌نویسی شی‌گرا است که عمق سلسله مراتب وراثت در یک کلاس رو اندازه‌گیری می‌کنه. این متریک تعداد کلاس‌های والد (ancestor classes) که یک کلاس خاص ازشون ارث‌بری می‌کنه رو می‌شماره. این متریک اهمیت زیادی در ارزیابی پیچیدگی طراحی داره چون عمق وراثت بالا که بعضا هنر و سواد بالای طراحی برنامه‌نویس تصور/تخیل می‌شه، مشکلات متعددی ایجاد می‌کنه.

➖ متریک Coupling and Cohesion: میزان وابستگی بین ماژول‌ها و کلاس‌های مختلف رو اندازه‌گیری می‌کنه که کمتر بودنش مطلوبه. Cohesion هم درجه‌ایه که اجزای یک ماژول با هم مرتبط هستن، که بالا بودنش بهتره. این دو متریک کیفیت طراحی و معماری نرم‌افزار رو نشون می‌دن و کد با Coupling پایین و Cohesion بالا قابلیت نگهداری و توسعه بهتری داره.

➖متریک Code Duplication: این شاخص درصد کدی رو که در پروژه تکرار شده رو اندازه‌گیری می‌کنه. کد تکراری مشکلات زیادی ایجاد می‌کنه از جمله افزایش حجم کد، دشواری در نگهداری و احتمال بالای باگ. ابزارهای مختلف می‌تونن این تکرارها رو شناسایی کنن و پیشنهاداتی برای حذف یا اجماع اون‌ها ارائه بدن. معمولاً کمتر از 3% تکرار قابل قبول در نظر گرفته می‌شه. در ضمن منظور از تکرار، کپی نعل‌به‌نعل نیست، گاهی الگوی یکسان باعث مشابهت می‌شن ولو اینکه اسامی متفاوت باشه.

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

💬 چقدر به این متریک‌ها یا به صورت کلی‌تر، به اعداد اهمیت می‌دید؟ در مورد اعداد دیگه صحبت کنیم؟

#️⃣ در ستایش اعداد...
2️⃣ قسمت دوم: متریک‌های عملکرد تیم توسعه

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

توی قسمت دوم، چند متریک مرتبط با تحلیل رفتار تیم در طول اسپرینت‌ها و بازخوردهایی که از طریق Jira، GitHub/GitLab، و یا سایر سیستم‌های دخیل در چرخه توسعه نرم‌افزار رو مرور می‌کنیم.

📈 متریک‌های تحلیلی تیم در اسپرینت‌ها

➖ معیار Capacity: ظرفیت تیم و تک‌تک افراد برای انجام کار که با عدد story point سنجیده می‌شه، قبل از شروع اسپرینت باید مرخصی و... رو لحاظ کرد، و به صورت دوره‌ای هم بررسی capacity در کنار velocity و burn down و... باید برای تخمین بهتر و تدقیق اعداد لحاظ بشه.

➖ معیار Velocity: نرخ تحویل تیم در هر اسپرینت، معمولاً بر حسب story points یا تعداد آیتم‌های کامل‌شده اندازه‌گیری می‌شه. اگرچه این عدد در بلندمدت معنا پیدا می‌کنه، اما کاهش یا نوسان زیادش ممکنه نشونه‌ی مشکلاتی در planning، تمرکز تیم یا دخالت‌های خارج از برنامه باشه.

➖ معیار Capacity Utilization: این متریک نشون می‌ده که چه درصدی از ظرفیت اعلام‌شده‌ی تیم واقعاً صرف تحویل کار شده. تطابق نداشتن capacity و velocity می‌تونه نشونه‌ای از کارهای ad-hoc، باگ‌های اضطراری، یا estimation ضعیف باشه. اگر همیشه ۱۰۰٪ باشه، احتمالاً تیم over-committed هست و خطر burnout بالاست. اگر مدام کمتر از ۷۰٪باشه، ممکنه مشکل در تخمین‌گذاری یا تعریف کارها باشه. بهینه معمولاً بین ۷۵-۸۵٪ در نظر گرفته می‌شه.

➖ معیار Commitment Reliability (Planned vs Delivered): مقایسه بین storyها و وظایفی که در ابتدای اسپرینت برنامه‌ریزی شدن با اون‌هایی که واقعاً کامل شدن. عدد پایین معمولاً نشونه‌ی overcommitment یا تغییر اولویت‌ها در طول اسپرینت هست.

➖ معیار Bug Trend per Sprint: تحلیل تعداد باگ‌های گزارش‌شده، اولویت‌هاشون، و نسبت اون‌ها به featureهای جدید می‌تونه نشون‌دهنده‌ی کیفیت تحویل، فشار کاری بیش از حد، یا ناکارآمدی در QA باشه.

➖ معیار Sprint Goal Achievement Rate: درصد اسپرینت‌هایی که هدف اصلی‌شون رو به طور کامل محقق می‌کنن. این متریک مهم‌تر از velocity خامه، چون نشون می‌ده تیم چقدر روی اهداف تجاری متمرکزه. نرخ کمتر از ۷۰٪ نشانه مشکل در برنامه‌ریزی یا اولویت‌بندیه.

ادامه دارد...

عددها همیشه حرف آخر رو نمی‌زنن، اما خیلی وقت‌ها شروع بهتری برای گفت‌وگو و تصمیم‌های جمعی هستن. ترکیب داده‌های Jira، Git، CI/CD، و ابزارهای متنوع موجود یا استفاده از API پلتفرم‌ها برای استخراج و بعدش آنالیز اعداد، می‌تونه دید بسیار روشنی از سلامت فرآیند توسعه و رفتار تیم به ما بده و این جزوی از وظایف engineering managerها یا team leadهاست که نسبت به اعداد بی‌تفاوت نباشن و به صورت روشمند تحلیل کنن...

💬 چقدر عدد توی تیمتون مهمه و چه متریک‌هایی رو دنبال می‌کنید؟ داده‌های کمی چقدر توی تصمیم‌گیری‌ها دخیلن؟

#️⃣ در ستایش اعداد...
3️⃣ قسمت سوم: متریک‌های همکاری تیمی و کیفیت تحویل در مخازن کد

در قسمت‌های قبل در مورد متریک‌های کد و متریک‌های برنامه‌ریزی نوشتم؛ این قسمت برخی از متریک‌های مخزن‌کد رو مرور می‌کنیم...

*️⃣معیار Lead Time for Changes:
زمان بین باز شدن یک pull request تا merge نهایی، یکی از شاخص‌های کلیدی DevOps برای سنجش تحویل سریع و با کیفیته. افزایش Lead Time معمولاً به دلیل منتظر موندن برای review، test failure، یا فقدان reviewer فعاله.

*️⃣معیار Time to First Response: فاصله زمانی بین باز شدن PR و اولین بازخورد (review یا comment). زمان بالا نشونه‌ی کمبود تعامل، فقدان مسئولیت‌پذیری یا توزیع نامتوازن کارها توی تیمه.

*️⃣معیار Code Review Coverage:
نسبت PRهایی که حداقل یک بررسی‌کننده‌ی انسانی (non-author) داشتن. پوشش پایین می‌تونه امنیت، کیفیت و حتی حس تعلق تیمی رو تحت تاثیر قرار بده. اینکه ۱ نفر مرورکننده رو هم حذف یا جزو مستحبات حساب کنیم نتایج خوبی نداره؛ برخی شرکت‌های بزرگ تا ۱۲ نفر (به جز AI داخلی) هر PR رو مرور می‌کنن برای سنجش کیفیت و امنیت کد.

*️⃣معیار Pull Request Size:
اندازه‌ی PRها از نظر تعداد خطوط تغییر یافته. PRهای بزرگ‌تر باعث کاهش کیفیت review، فرسایش توجه reviewerها، و احتمال بیشتر برای بروز باگ می‌شن. عدد مناسب معمولاً زیر ۴۰۰ خطه (البته خودش شمارش خطوط کد بحث مفصلیه که انواع خط کد چیه؟ یا چجوری باید شمرد...)

*️⃣معیار Merge Frequency:
چند بار در روز یا هفته PR merge می‌شه؟ این عدد نشون می‌ده که آیا تیم به صورت پیوسته و در بازه‌های کوچک تحویل انجام می‌ده یا تحویل به صورت big-bang و آخر اسپرینت صورت می‌گیره. بازه‌های کوچک‌تر = ریسک کمتر = feedback سریع‌تر. البته به استراتژی و سیاست‌های توسعه نرم‌افزار شرکت خیلی وابسته است.

*️⃣معیار Pull Request Cycle Time:
زمان از باز کردن PR تا merge شدنش. این متریک شامل چند مرحله‌ست: Time to First Review، Review Duration، و Time to Merge. PR های که بیش از ۴۸ ساعت طول می‌کشن، معمولاً کیفیت کد و روحیه تیم رو تحت تأثیر منفی قرار می‌دن.

*️⃣معیار Rework Rate:
درصد تغییراتی که پس از merge، نیاز به اصلاح یا revert پیدا می‌کنن. عدد بالا می‌تونه نشونه‌ی ضعف در review یا تست ناکافی باشه.

*️⃣معیار Defect Escape Rate:
تعداد باگ‌هایی که بعد از merge به محیط‌های بالاتر (Staging یا Production) منتقل می‌شن. این عدد برای سنجش کیفیت تحویل و اثربخشی فرآیند تست قبل از ادغام حیاتیه.

*️⃣معیار Review Participation Rate:
نسبت اعضای تیم که در بازه‌ای مشخص، در reviewهای دیگران شرکت می‌کنن. مشارکت کم می‌تونه باعث ایجاد bottleneck یا کاهش کیفیت کد بشه.

*️⃣معیار Stale PRs
PRهایی که مدت زیادی باز می‌مونن بدون فعالیت. این موارد معمولاً نشان‌دهنده مشکلات در اولویت‌بندی، درگیری منابع، یا ابهام در نیازمندی‌هاست.

📌 جمع‌بندی:
اندازه‌گیری این متریک‌ها به خودی خود هدف نیست؛ هدف اصلی، ایجاد گفت‌وگو در تیم برای پیدا کردن گلوگاه‌ها، بهبود تعاملات، و کاهش زمان و هزینه تحویل با حفظ کیفیته. اعداد، آینه‌ای برای دیدن واقعیت کار تیمی ما هستند. بدون سوگیری، بدون توجیه! این متریک‌ها هم یهویی و یک‌شبه قابل حصول نیستن، اول باید تصمیم بگیریم به سمت «قابل‌اندازه‌گیری شدن» حرکت کنیم؛ بعدتر اگر درست پیش بریم، متریک خواهیم داشت.

💡 «هیچ» بهبودی یهویی نخواهد بود...
و در عین حال بدون شروع ولو با گام‌های کوچیک هم چیزی محقق نمی‌شه!

🚀 «مدل عملیاتی محصول» برای تیم‌های نرم‌افزاری
چجوری از «تحویل فیچر» به «تحویل ارزش» تغییر مسیر بدیم؟

وقتی ساختار تیم‌ها (وظایف و تخصص افراد و ماموریت خود تیم) درست چیده نشه، خیلی راحت به دام «لیست وظایف» میوفتن، یعنی اینکه مرتبا تیم از خودش می‌پرسه: تسک بعدی چیه؟ فیچر بعدی کی باید ریلیز بشه؟

مدل عملیاتی محصول (Product Operating Model یا POM) می‌گه محور رو از «پروژه و خروجی» بچرخونیم به «محصول» و نتیجه (Outcome). این یعنی تیم رو حولِ ارزش واقعی برای کاربر و بیزنس سازماندهی کنیم، و از ایده تا اجرا و بهبود پیوسته، همه چیز رو یکجا متمرکز کنیم.

🎯 اصلا POM یعنی چه؟

یک چارچوب سازمانی که محصول رو در مرکز قرار می‌ده و تیم‌های چندتخصصه (مدیریت محصول، مهندسی، طراحی، دیتا، و...) به‌صورت مداوم، و حول یک «چشم‌انداز روشن» با هم کار می‌کنن؛ نه اینکه پروژه‌های مقطعی داشته باشیم و تیم توسعه نرم‌افزار، فیچر رو تولید کنه، بعد تیم دیتا بدون اینکه سر تا ته داستان چی بوده فقط وظیفه داشته باشه مثلا کارهای data engineering رو انجام بده و بگه «انجام شد و تامام» و بره برای تیم بعدی و بعدی و بعدیش...

بلکه چرخه‌ی عمر پیوسته‌ی محصول، با بازخوردها و بهبودهای مکرر یکجا رقم می‌خوره.
نتیجه؟ پاسخ‌گویی سریع‌تر به نیاز بازار و یادگیری دائمی تیم ← Domain knowledge (تخصص دامنه) توی تیم رسوب می‌کنه!

🧩 چه تغییری برای مهندسی ایجاد می‌شه؟

➖تیم‌های چندتخصصه و پایدار
مهندس‌ها در تیم‌های محصولِ ثابت کار می‌کنند، مالکیت «سر تا سری» از طراحی تا نگه‌داری دارن، و روی تجربهٔ کاربر و اثر بیزنسی حساسند.

➖از پروژه به محصول
صورت‌مسئله از «تحویل فیچر» به «حل مسئله با Outcome مشخص» تغییر می‌کنه.

➖اختیار و خودمختاری
تیم محصول (ازجمله مهندسی) درباره‌ی «چگونه حل کردن مسئله» تصمیم می‌گیره؛ با اسپرینت‌های کوتاه، CI/CD و بازخورد پیوسته؛ و نه انجام خواسته یا وظیفه‌ای که بهش محول شده.

➖اندازه‌گیری بر پایه‌ی نتیجه
موفقیت یعنی «ارزش تحویلی و یادگیری»، نه صرفاً اتمام تسک.

➖همکاری مداوم
محصول، طراحی، مهندسی و بیزنس با داده‌ی واقعی و ریسرچ کاربر تصمیم می‌گیرن.

🏗 ساختار تیم‌ها خیلی مهم هستن و بحث مفصلیه (اگر دوست داشتید مطلب Team Topologies رو بخونید یا ۱۰ دقیقه از این ویدیو رو از ۰۰:۵۷:۳۵ تا ۱:۰۸:۰۵ ببینید ) ولی هدف کلی اینه که کاهش بار شناختی (Cognitive Load) و تسهیل تحویل خودمختار محصول محقق بشن.

📊 مزایای عملی POM

برای سازمان:
- سرعت بازار: Time-to-market کمتر
- انعطاف: پاسخ سریع‌تر به تغییرات
- کیفیت: کاهش باگ و مشکلات فنی
- نوآوری: فضای بیشتر برای آزمایش و یادگیری

برای تیم‌ها:
- مالکیت: احساس مسئولیت بالاتر نسبت به محصول
- انگیزه: دیدن تأثیر مستقیم کار روی کاربران
- یادگیری: رشد مهارت‌های چندتخصصه
- خودمختاری: آزادی عمل در روش‌ها

برای مهندسان:
- کمتر شدن Context switching
- درک عمیق‌تر از domain
- همکاری نزدیک‌تر با نقش‌های دیگه
- تمرکز بر کیفیت کد و architecture

🚧 چالش‌های پیاده‌سازی

مقاومت فرهنگی
نیازهای فنی
مهارت‌های جدید

💡 نکات کلیدی
- تغییر تدریجی: یکباره همه چیز رو عوض نکنید. الکی هم زور نزنید چون نمی‌شه!!
- اندازه‌گیری: بدون metric، نمی‌تونید بهبود رو ببینید؛ لطفا به حستون اعتماد نکنید، اعداد دقیق‌تر از حس شما هستن.
- صبر: فرهنگ‌سازی زمان می‌بره، عجله نکنید.
- یادگیری: از شکست‌ها هم می‌شه یاد گرفت. خواهشا درگیر cognitive dissonance نشید!
- تطبیق: هر سازمان منحصربه‌فرده، کپی‌کاری نکنید!

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

💡 آیا مایکروسرویس و DDD برای تیم‌های کوچک مناسبه؟

از اونجایی که تعداد تیم‌هایی که تلاش کردن/می‌کنن تا DDD رو پیاده‌سازی کنن و یا محصول مبتنی بر معماری مایکروسرویس توسعه بدن، ولی در میانه‌ی راه متوجه دشواری‌ها، مشکلات و یا اشتباهات متعدد طراحی و پیاده‌سازی می‌شن، کم نیست؛ خوبه تا پرسش رو مرور کنیم، تا اگر موضوع مورد اقبالی بود بیشتر در موردش گپ بزنیم.

❓ ریشه و خواستگاه این طراحی و معماری کجاست؟
تا حالا به خواستگاه و پیشینه‌ی خالقین DDD یا Microservice توجه داشتید؟ منظورم «خواستگاه نیازهایی» است که به خاطر برطرف شدن اون نیازها، افرادی با «پیشینه و تجربه‌ی مشخص در تعامل با نوع خاصی از مسائل و سازمان‌ها» شروع به طراحی راهکار یا پاسخ برای اون نیازها در اون سازمان‌ها کردن؛ و بعدتر این راهکارها در سازمان‌هایی با چه مختصات و ابعادی، توسط چه افرادی توسعه و تکامل پیدا کرد تا امروز به انضمام این تعداد کتاب و مقاله و ویدیو و کنفرانس، در اختیار ما باشه؟!

بیاید با هم چند تا سوال کاریکاتوریزه رو مرور کنیم:

۱: از نظر امکانات در دسترس: آیا یک پزشک حاذق که تمام عمرش در پیشرفته‌ترین بیمارستان‌های ژاپن یا سوییس تحصیل و کسب‌تجربه کرده؛ به صورت مستقیم (و طبیعتا بدون تغییر و سازگارپذیری) می‌تونه بره در یکی از مناطق محروم اتیوپی شروع به درمان کنه؟

۲: از نظر مقیاس‌ها: آیا مرسومه که از ابزارآلات تعمیر ماشین‌های معدن در کارگاه ساعت‌سازی استفاده کنن یا برعکس؟

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

🔑 چاره کار چیه؟
» اگر دنبال یک مسیر قابل تعمیم به عام باشیم، راه رو به خطا رفتیم؛ عملا عیار یک architect یا software engineer سنیور یا بالاتر (بسته به سایز سازمان و محصول) در میزان موفقیت و ظرافت‌های طراحی مسیر، راهکار و معماری مشخص می‌شه. قرار هم نبوده و نیست، همه یک میزان موفقیت کسب کنن. خیلی‌ها هم شکست میخورن یا پیروزی‌نمایی می‌کنن.

➖اگر دوست داشتید این بحث ادامه پیدا کنه لطفا با ⚙️ اعلام کنید تا در اگر به حدنصاب رسید ادامه بدیم..
(موضوعاتی مثل Strategic DDD یا Modular Monolith/Modulith، شناسایی پیش‌نیازها، فازبندی تغییرات و پیاده‌سازی، امکان‌پذیری transformation و... می‌تونن محور این سری از مطالب باشن)


🗽 سخن بزرگان:

👨🏼‍🦳 مارتین فالر: توی مقاله معروف "Microservice Prerequisites" سه تا پیش‌نیاز اساسی رو مطرح می‌کند:

قابلیت Rapid provisioning: قابلیت راه‌اندازی سریع infrastructure
قابلیت Basic monitoring: نظارت و observability
قابلیت Rapid application deployment: استقرار سریع نرم‌افزار
«در صورت ادامه بحث، چند مورد دیگه رو هم من بنا به تجربه اضافه خواهم کرد»

👨🏼‍🦳 کریس ریچاردسون توی کتاب "Microservices Patterns" بحث pattern-based approach رو ارائه می‌کنه وبارها تأکید داره مایکروسرویس «نسخه‌ی واحد برای همه» نیست و باید دید کِی و چرا سراغش بریم؛ حتی «دلایل نادرست برای پذیرش مایکروسرویس» رو هم مستند کرده.

👨🏼‍🦳 استفان تیلکوف توی مقاله «Don’t start with a monolith» می‌گه وقتی هدف نهایی شما معماریِ مایکروسرویس باشه (به‌ویژه برای سیستم‌های بزرگ)، «شروع با مونولیت» غالباً انتخاب درستی نیست و باید از اول به مرزبندی‌های سخت‌گیرانه و سیستم‌های مستقل فکر کرد. بعدتر تیلکوف الگوی Self-Contained Systems (SCS) رو هم به‌عنوان رویکرد هم‌خانواده و کم‌اصطکاک‌تر معرفی می‌کنه. ۴ سال بعدش، سم نیومن میاد روی روش‌ها و الگوهای تکاملی برای شکستن مونولیت تمرکز می‌کنه (نه نفی یا اثبات مطلق هر کدوم)، و راهکارهای عملی برای مهاجرت تدریجی ارائه می‌ده. کتاب معروف نیومن یعنی "Monolith to Microservices" عملاً پاسخ عملیِ «چگونه از مونولیت به مایکروسرویس برسیم؟» حساب می‌شه (اینو گفتم که بگم بین علما و بزرگان هم تفاوت نظر وجود داره 😁 خصوصا در مورد فالر و ریچاردسون؛ چون فالر استراتژی «اول مونولیت» برای شروع کارهای جدید رو طرح می‌کنه و می‌گه با این نکته که حتی اگه بعداً احتمالاً به مایکروسرویس برسید! این دیدگاه روبه‌روی موضع تیلکوف قرار می‌گیره و نشون می‌ده اختلاف‌نظر معنادار بین علما جدیه! )

قسمت اول سری «مایکروسرویس و DDD برای تیم‌های کوچیک؟»
✅ خواستگاه‌ و قصه‌ی شکل‌گیری

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

🎂 الف: DDD از کجا و از دل چه نیازی بیرون اومد؟

خالق: اریک ایوانز (Eric Evans)
سال انتشار: ۲۰۰۴
محیط پیدایش: شرکت‌های بزرگ مشاوره‌ای و enterprise.

اریک ایوانز از اوایل دهه ۹۰ میلادی روی پروژه‌های متعدد نرم‌افزاری و عموما مرتبط با شرکتهای «large enterprise» کار می‌کرده، و وقتی کتاب معروف "Domain-Driven Design: Tackling Complexity in the Heart of Software" رو در سال ۲۰۰۴ منتشر می‌کنه، عملا ماحصل یک دهه تجربه‌ی کار روی سیستم‌های پیچیده enterprise رو در قالب یک روش ساختاریافته معرفی کرد. سابقه‌‌ی کار توی شرکت‌هایی که مسائل پیچیده بیزنسی دارن و نیازمند درک عمیق domain دارن رو کسب کرده بوده؛ و با تیم‌های بزرگ (معمولاً +۲۰ نفر) که روی پروژه‌های چندساله کار می‌کردن رو داشته (خصوصیت مشترک چنین سازمان‌هایی).
توی این تیپ سازمان‌ها هر domain، فرد یا افراد متخصص خودش رو داره که باید زیر و بم دامنه رو بدونن؛ و ارتباط بین دامنه‌ای از طریق اون افراد ضروریه. اغلب هم Legacy systems دارن و باید با اونا integration انجام بشه.

مسئله‌ی اصلی: پیچیدگی دامنه‌های کسب‌وکار (قوانین متغیر، اصطلاحات تخصصی، استثناهای ریز و درشت، چندین ساب‌دامین با رفتارهای متفاوت).

پاسخِ DDD: نزدیک‌کردن مدل نرم‌افزار به زبان و منطق دامنه؛ با مفاهیمی مثل:

مفهوم Ubiquitous Language: یعنی اینکه تیم فنی و بیزنس، و به تبعش توی محصول و مستندات، برای یک مفهوم خاص، فقط یک ترم مشترک استفاده بشه. توی سیستم‌های بزرگ و پیچیده، صدها و گاها چند هزار عبارت و مخفف استفاده می‌شه که اگر به سمت زبان مشترک نریم، توسعه‌دهنده یه جا یه مخفف رو می‌شنوه، یه جا ترم کامل، و یه جا یک کلمه از ترم رو؛ تا اینجا باعث گیج شدنش می‌شه، ولی مشکل بزرگ‌تر وقتیه که ترم‌های مشابه وجود داره و هر دامنه به فراخور میزان کاربرد، منظورش از یه ترم متفاوته و به یه چیز خاص اشاره می‌کنه. مثلا تعریفش از «هزینه» یه چیزیه که توسعه دهنده دامنه دیگه به یه چیز دیگه می‌گه «هزینه» (انواع مختلفی از هزینه مثل ثابت، متغیر، نیمه متغیر، مستقیم، توزیع و... بسته وجود داره)؛ و این عدم استفاده از یک زبان مشترک توی سازمان‌های بزرگ، می‌تونه منجر به سردرگمی و اشتباهات محاسباتی و... بشه.

مفهوم Bounded Context می‌گه باید مرزبندی شفاف برای مدل‌ها و معانی داشت؛ هر کانتکست فرهنگ خودش رو داره و باید دقیقا مشخص باشه کدوم قابلیت مربوط به کدوم دامنه می‌شه. توی سیستم‌های خیلی بزرگ، خیلی وقت‌ها باید چند جلسه با متخصصین دو تا دامنه بشینیم که بتونیم تصمیم بگیریم آیا این قابلیت توی کدوم دامنه قرار بگیره بهتره. (با نگاه پیاده‌سازی و همچنین آینده محصول).
بارها پیش میاد که توی سازمان بزرگ باید بگردی توی مستندات یا از افراد مختلف، که متخصص فلان دامنه کیه، چون حتی نمی‌شناسیش!

مفهوم Context Mapping، یعنی نقشه‌ی ارتباط بین bounded contextsها، که ارتباط بین کانتکست‌ها رو هم از منظر روابط تیم‌ها تبیین می‌کنه هم از نظر الگوهای ارتباطی. به بیان ساده، این‌قدر داستان بزرگ و پیچیده هست که نیازه تا برای ارتباط بین تیم‌های متعدد، که گاها به چند ده، یا حتی چند صد تیم می‌رسه، بیان بگن انواع ارتباطات بین کانتکست‌ها و تیم‌ها در چه قالب‌هایی می‌گنجه.

این‌ها توصیف مختصری از خواستگاه و بافتار پیدایشی DDD بود که توسط برخی از جواگره حتی گاها با domain-centric جابجا بیان می‌شه!

حالا کجا این مفاهیم شکوفا شده؟ پاسخ: سازمان‌های عمدتا بزرگ و بعدتر متوسط (در مقیاس جهانی)، چرا تعریف مقیاس و سایز مهمه؟ چون گاهی ما به یه شرکت ۳۰۰ نفره میگیم بزرگ!! که واقعا بزرگ محسوب نمی‌شه. یا گاهی یک سازمان ۱۱ هزار نفره رو بزرگ می‌دونیم، درحایلکه ساختارش از نظر بلوغ، شبیه یک شرکت ۵۰ نفره است (مثال و تجربه عینی توی ذهنمه 😁). در چنین فضاهایی، DDD هزینه‌ی هماهنگی رو کم، و سرعت تغییرِ درست رو زیاد می‌کنه خصوصا که چرخه‌ی عمر بلند‌مدت دارن. ولی وقتی سعی می‌کنیم قبای بزرگ‌تر از قامتمون تن کنیم، تبدیل به یه شوخی پرهزینه خواهیم شد.

اگر دوست داشتید قسمت بعد رو با همین رویه در مورد مایکروسرویس گپ بزنیم: ⚙️
و اگر دوست داشتید تمایز DDD و domain-centric: 🤪

قسمت دوم سری «مایکروسرویس و DDD برای تیم‌های کوچیک؟»
✅ خواستگاه‌ و قصه‌ی شکل‌گیری مایکروسرویس (بخش ۱)

مثل دو قسمت قبل، هدفم اینه که خواستگاه مایکروسرویس رو مرور کنم، تا بدونیم آیا «مسئله‌ی مشترک» باهاش داریم یا نه!

خلق و ترویج مایکروسرویس رو نمی‌شه به یک نفر خاص نسبت داد، بلکه یه «جریان صنعتی» بود که با ایده‌ها و نوشته‌های فالر و جیمز لوئیس پررنگ شد، بعدتر با تجربه‌های نتفلیکس و آمازون عملی شد، و سم نیومن اون رو با «راهنمای مهاجرت» همراه کرد. حوالی ۲۰۱۳–۲۰۱۶، هم‌زمان با بلوغ DevOps، کانتینرها و CI/CD تبدیل به تب داغ صنعت شد و خواستگاهش هم عمدتا شرکت‌های بزرگی بود که پلتفرم دیجیتال‌ بومی‌ای داشتن که توسط تیم‌های چندمهارته توسعه داده می‌شد و نیاز به تغییرات مداوم، مقیاس‌پذیری و تاب‌آوری بالا هم بینشون خصیصه مشترک بود.

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

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

به بیان ساده‌تر، مسئله‌ی اصلی، تنگناهای معماری Monolith در مقیاس بزرگ؛ یعنی کندی توسعه، سختی در اعمال تکنولوژی‌های جدید، ریسک بالای Deployment و مشکلات مقیاس‌پذیری (Scalability) بود.

💡 پاسخ مایکروسرویس چی بود؟ شکستن اپلیکیشن یکپارچه به مجموعه‌ای از سرویس‌های کوچیک، مستقل، و با ارتباطات سبک؛ با مفاهیمی مثل:

➖استقلال در استقرار: هر سرویس یک واحد مستقل محسوب می‌شه که می‌تونه بدون نیاز به هماهنگی با سایر سرویس‌ها، توسعه داده بشه، تست و نهایتا منتشر بشه. این ویزگی برای سازمانی با ده‌ها یا صدها تیم که هرکدوم می‌خوان با سرعت حرکت کنن، نعمته. دیگر لازم نیست تیم «پرداخت» منتظر تیم «انبارداری» بمونه تا با هم محصول رو منتشر کنن.

➖سازماندهی حول قابلیت‌های کسب‌وکار: این خیلی شبیه به مفهوم Bounded Context در DDD است که توی پست قبل اشاره کردم. هر سرویس مسئول یک قابلیت کامل بیزنسیه (مثلا مدیریت کاربرها، سیستم پیشنهاددهی، یا پردازش پرداخت). این یعنی تیم‌ها مالکیت کامل یک بخش از بیزنس رو عهده می‌گیرن.

➖حاکمیت و داده‌های غیرمتمرکز: هر تیم می‌تونه تکنولوژی (زبان برنامه‌نویسی، دیتابیس و...) مناسب برای سرویس خودش رو انتخاب کنه. سرویس «جستجو» می‌تونه از Elasticsearch استفاده کنه در حالی که سرویس «مالی» از PostgreSQL استفاده کنه. این انعطاف، به تیم‌ها اجازه می‌ده بهترین ابزار رو برای حل مسئله‌‌شون به کار بگیرن، اما در عین حال پیچیدگی نگهداری و هماهنگی رو «به شدت» بالا می‌بره.

➖اتوماسیون زیرساخت: مایکروسرویس بدون فرهنگ DevOps و ابزارهای CI/CD تقریبا غیرممکنه. وقتی به جای یک اپلیکیشن، ده‌ها یا صدها سرویس برای مدیریت، مانیتورینگ و استقرار دارید، تنها راه نجات، اتوماسیون کامل فرآیندهاست.

🔤 «یک سرویس = یک قابلیتِ واضح + تیمِ مالک + داده/قراردادِ مستقل + چرخه‌ی انتشارِ مستقل»

♻️ پیش‌فرض‌های محیطی (زمین بازی)
مایکروسرویس نه صرفاً معماریِ کُد، که طراحی سازمانیه (قانون کانوی). بدون این پیش‌فرض‌ها، نتیجه معمولاً «مونولیتِ توزیع‌شده» است:
*️⃣زیرساختِ خودکار: IaC، محیط‌های چندگانه، انتشار بی‌درد (Blue/Green, Canary).
*️⃣پایپ‌لاین‌های CI/CD بالغ: تست خودکار، کیفیت پایدار، Rollback ساده.
*️⃣قابلیت Observability: لاگ همبسته، تریس توزیع‌شده، متریک، آلارم.
*️⃣قراردادهای پایدار: نسخه‌بندی API/اسکیما، سازگاری تدریجی، Consumer-Driven Contracts.
*️⃣مالکیت داده: تا حد امکان دیتابیسِ اختصاصی/طرح تجمیع رویدادها؛ پرهیز از «Shared DB».
*️⃣نضباط توزیعی: مدیریت شکست شبکه، Retry/Timeout/Idempotency، Backpressure.
*️⃣فرهنگ تیمی: تیم‌های کوچکِ end-to-end با ریشه‌ی DevOps.

ادامه دارد...

قسمت سوم سری «مایکروسرویس و DDD برای تیم‌های کوچیک؟»
✅ خواستگاه‌ و قصه‌ی شکل‌گیری مایکروسرویس (بخش ۲)

🤦🏻‍♂️ سوءبرداشت‌های پرتکرار
🔤برای سرعت، حتماً مایکروسرویس!: اگر مشکل دارید؛ شاید پاسخ مشکلتون چیز دیگه‌ای یا از جای دیگه‌ای باشه. سربارِ ارتباطات مضاعف شبکه‌ای و بین سرویسی رو در نظر بگیرید که از چاله به چاه نیوفتید. شاید Modular Monolith/Modulith با مرزبندی درست، سریع‌تر و کم‌ریسک‌تر باشه.

🔤هر جدول = یک سرویس: واحد تقسیم و شکستن سرویس‌ها «قابلیت یا کانتکست» است، نه جدول.

🔤مایکروسرویس = کوبرنتیز: کوبرنتیز ابزاره، نه توجیه. کاش وقت شه روزی خواستگاه کوبرنتیز رو هم بنویسم تا با ۳ تا سرور فیزیکی فاز «مقیاس‌پیذیری» بر نداریم! swarm و k3s و... هم هستن!

🔤سرویس کوچیک‌تر ⇒ بهتر: ریزدانه‌گیِ افراطی، انفجار هماهنگی به بار میاره!

🔤می‌خواهیم تراکنش توزیع‌شده‌ی سراسری داشته باشیم: نشونه‌ی تقسیم و شکست غلطه؛ به event-driven و... فکر کنید.

🗑بوی بدی (Smells) که نشون می‌ده راه رو کج رفتیم
- انتشار هم‌زمان چند سرویس برای یک تغییر کوچیک (Coupling پنهان).
- استفاده از Shared Database/Schema بین سرویس‌ها.
- آشفتگی ارتباطات (چند ده Call برای یک درخواست کاربر).
- استفاده سراسری از Two-Phase Commit (2PC)، بدون پذیرش event-driven/Outbox/....
- کتابخونه‌های Shared سنگین که نسخه‌بندی رو قفل می‌کنن (به‌جای قرارداد سبک).

💀 چه زمانی سراغش نرویم؟
- یک یا دو تیم کوچیک دارید و بیشترین درد شما کیفیت تست/اتوماسیون/استقراره؛ نه مرزهای دامنه.
- تغییرات کم‌بسامده و پیچیدگی دامنه متوسط.
- هنوز Observability، CI/CD، IaC در سطح پایه‌ای هم آماده نیست.
- «مالکیتِ end-to-end» برای هیچ سرویس/تیمی تعریف نشده.

در این حالت‌ها، Modulith با مرزبندی DDD (Bounded Context) «پله‌ی اول» بهتریه. هم بدهی معماری تولید نمی‌کنید، هم راهِ جداسازی آینده رو باز می‌گذارید.

🌱 نشونه‌های آمادگی :
- می‌تونید برای یک قابلیت، تیمِ مالک، بک‌لاگ، KPI و انتشار مستقل تعریف کنید.
- مولفه‌های Trace/Log/Metric شما پاسخ‌گوست: «اگر چیزی خراب شد، می‌دونید دقیقاً کجا و چرا؟»
- قراردادهایتان نسخه‌پذیره و Breaking Change رو تدریجی عرضه می‌کنید.
- داده‌ها مالک مشخص دارن و اشتراکِ مستقیمِ Schema ندارید.
- در لایه‌ی ارتباطات Fail-Fast/Retry/Timeout/Idempotency، «پروتکل تیم» است نه لطفِ داوطلبانه‌ی دولوپرها.

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

✍️ پی‌نوشت: اگر تا اینجا این چند پست رو دنبال کردید، امیدوارم مفید بوده باشه. اعداد نشون می‌ده که خوبه که این بحث رو اینجا متوقف کنیم. لذا پست‌های بعدی احتمالا به موضوعات دیگه‌ای اختصاص خواهد داشت.

🧠 🚀هوش مصنوعی در تیم توسعه‌: ابزار روزمره به جای تقلب!

با رایج شدن مدل‌های هوش مصنوعی توی محیط‌های توسعه؛ مسیر تعامل برنامه‌نویس با مدل، از حالت پرسش ‌و پاسخ یا Ask، به توانمندی ویرایش یا Edit رسید و بعدتر به حالت Agent. در طول این مسیر، نیاز به سر و سامون دادن به رفتار مدل و اعمال تنظیمات دلخواه، ضرورتش بیشتر و بیشتر شد. حالا این تنظیمات می‌تونه پرامپت‌های از پیش ذخیره شده باشه برای صرفه‌جویی در زمان، یا مثلا دستورالعمل‌هایی مثل ساختار نامگذاری متغیرها یا اینکه همیشه لاگ‌ها رو به شیوه خاص بنویسه یا... برای همین فایل‌هایی مثل AGENTS.md یا .github/copilot-instructions.md یا .instructions.md به وجود اومدن.
توی این پست، اول این فایل‌ها رو با مثال مرور می‌کنم، بعدتر به اهمیت توجه به یکسان‌سازی/استانداردسازی اون‌ها در تیم‌های توسعه توسط platform engineering خواهم نوشت. این ابزارها خیلی سریع دارن توی ریپازیتوری‌های حرفه‌ای و شرکت‌ها، جا می‌افتن و مهمه که بدونیم دقیقاً چی‌ان؟ چرا مهم‌ان؟ و اصلاً چطور می‌تونن به تیم ما کمک کنن؟

✅ این فایل‌ها چی هستن؟

اگه بخوام ساده بگم، این فایل‌ها نقش «دستورالعمل استفاده از هوش مصنوعی» رو دارن برای توسعه‌دهنده‌ها و ابزارهای هوشمند مثل GitHub Copilot، Cody، یا حتی agentهای داخلی تیم‌ها.
به کمک این فایل‌ها، می‌تونیم به ابزار AI یاد بدیم که:

- چه سبکی از کدنویسی رو تو پروژه‌مون ترجیح می‌دیم
- از چه کتابخونه‌ها یا معماری‌هایی استفاده می‌کنیم
- چه چیزهایی ممنوعه یا نیاز به تایید دارن
- حتی چه تسک‌هایی رو می‌تونه خودش انجام بده یا نیمه‌کاره پیش‌نویس بزنه

🔧 مثال‌های کاربردی:

👨‍💻فایل copilot-instructions.md:
فایل ساده‌ایه که توش توضیح می‌دیم Copilot تو این ریپو چطوری باید رفتار کنه. مثلاً:

- از Flurl.Http استفاده کن، نه HttpClient
- وقتی اسم متد با Get شروع شد، حتماً یه تست یونیت بساز
- همیشه Exceptionهای گلوبال با ProblemDetails هندل می‌شن

 .github/copilot-instructions.md
# Shared Platform Coding Standards

- Use `async/await`, not callbacks.
- Follow project’s naming conventions.
- Include dependency vulnerability tagging in comments.
- Provide default error handling structure.
- Always include logging statements.

🤖 فایل AGENTS.md:
اگه تو تیم‌مون agent داریم (مثلاً برای اینکه PR می‌زنه یا کد جنریت می‌کنه؛ یا از منابع کانفلوئنس شرکت اطلاعات می‌خونه یا به جیرا دسترسی داره یا...)، این فایل نقش پروفایل اون agent رو داره.
توش توضیح می‌دیم که این agent قراره چی کار کنه، چه داده‌ای داره، چه دامنۀ تصمیم‌گیری‌ای داره و کی باید بررسی کنه خروجیاشو.

AGENTS.md
# AGENTS.md — Developer Platform Guide for AI Agents

## Environment Setup
- `make setup` to install dependencies.
- `make test` for running full test suite.
- `docker compose up` to launch local services.

## Code Style
- Pre-commit: `black`, `isort`, `eslint`.
- Linting: `./tools/lint`.
- Tests: coverage must exceed 85%.

## Development Workflow
- Branch naming: `feat/*`, `fix/*`.
- PR guidelines: include ticket link, test coverage, and denoscription.

## Platform Behavior
- Always run `make build` before tests.
- Platform maintains shared Docker images, secrets, and env configurations.

📘 فایل .instructions.md:
یه فایل کلی‌تر برای راهنمایی خود ابزارها یا هم‌تیمی‌ها. توش ممکنه توضیح بدیم تو این پروژه چه Naming Convention داریم، چطوری باید migration ساخت، یا اینکه اصلاً ساختار پوشه‌ها چطوریه.

backend.instructions.md
---
applyTo: "backend/**/*.py"
---
# Backend Python Guidelines

- Format using Black (line length 88).
- Use Pydantic for input validation.
- Comment public functions with docstrings.
- Follow platform’s API client patterns.

ادامه در پست بعدی...