💡 مفهوم، اصول و مزایای Pair Programming چیه؟

برنامه‌نویسی دونفره/جفت (معادل فارسی مناسبی برای سراغ ندارم) یعنی دو نفر توسعه‌دهنده، به‌صورت همزمان روی یک تسک یا تیکت با هم کار کنند — معمولاً هم با استفاده از یک صفحه نمایش مشترک (حضوری یا با اشتراک‌گذاری صفحه، یا با امکانات جدیدتر مثل live sharing).

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

🎯 چرا از Pair Programming استفاده کنیم؟

- آموزش، آنبورد سریع‌تر نیروهای جدید
- انتقال مستمر دانش در تیم (در زمینه‌های متنوع و کدبیس‌های مختلف)
- افزایش کیفیت کد (کاهش باگ، نام‌گذاری بهتر، منطق تمیزتر)
مالکیت مشترک کد — بیش از یک نفر در جریان کد هست
- یادگیری ابزارها، الگوها و تکنیک‌ها در عمل
- شکستن سیلوها و افزایش هماهنگی در تیم (دانش یک بخش از کد در یک نفر متمرکز نمیشه و افراد می‌تونن همدیگه رو پوشش بدن)

✅ کجا از Pair Programming استفاده کنیم؟

- حل باگ‌های پیچیده
- کار روی کد ناآشنا
- آشنایی نیروهای جدید با یک فیچر
- تغییرات حساس یا حیاتی
- طراحی ساختار داده یا الگوریتم
- توسعه با رویکرد TDD یا بهینه‌سازی عملکرد


❌ کجا مفید و مناسب نیست (معمولا)؟

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

🧑‍💻 نقش‌ها در Pair Programming
- نقش Driver (راننده): کدنویسی می‌کنه، تمرکزش روی منطق فوری و نگارش است.
- نقش Navigator (ناوبر): هم‌زمان کد رو مرور می‌کنه، به ساختار، تست‌ها و موارد خاص فکر می‌کنه.
نکته مهم: نقش‌ها رو هر ۲۰ تا ۳۰ دقیقه جابه‌جا کنید تا ذهن هر دو نفر فعال بمونه، و ناوبر تبدیل به تماشاچی نشه!

🧭 چجوری Pair Programming مؤثری داشته باشیم؟

- هدف مشترک جلسه رو قبل از شروع مشخص کنید: دقیقاً دنبال چی هستید؟
- فرمت همکاری رو مشخص کنید: Driver/Navigator یا نوبتی؟
- مدت جلسه رو محدود کنید: مثلاً ۹۰ دقیقه با استراحت در میانه
- نقش‌ها رو به‌صورت منظم عوض کنید
- حین کار بلند فکر کنید، توضیح بدی، سوال بپرسید، پیشنهاد بدهید
- در پایان یک مرور کنید: چی یاد گرفتیم؟ قدم بعدی چیه؟

🧠 ملاحظات مربوط به ظرفیت تیم

درسته که دو نفر روی یک تیکت کار می‌کنن، ولی این به معنی نصف شدن بهره‌وری نیست. در بسیاری از مواقع، Pair Programming باعث:
- تحویل سریع‌تر در storyهای پیچیده
- راه‌حل‌های با کیفیت‌تر و قابل نگهداری‌تر
- کاهش اصطکاک در بازبینی و افزایش درک مشترک

💡 نکته: اگه قراره چندین تیکت به صورت Pair انجام بشن، ظرفیت تیم رو تنظیم کنید — مثلاً ۱۵–۲۰٪ استوری‌پوینت کمتر در نظر بگیر، یا تیکت‌های دونفره رو جداگانه پیگیری کنید.

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

✅ نکات و بهترین روش‌ها

- پارتنر مناسب انتخاب کنید: تعادل در تجربه، دامنه دانش، یا تکنولوژی
- صبور باشید: هدف، سرعت نیست — کیفیت و یادگیری مهمه
- بیش از حد کیبورد رو از دست نفر مقابل نگیرید — بگذارید هر دو فعال باشند
- سوال «چرا؟» رو تشویق کنید — یادگیری بخش اصلی کاره
- حتماً استراحت بدید — خستگی ذهنی طبیعی و تأثیرگذاره
- اگه بعد از ۳۰–۴۰ دقیقه حس کردید که کار پیش نمی‌ره، یه قدم عقب برید و برنامه‌ریزی رو بازنگری کنید

💬 تجربه یا نظر شما چیه؟

نیم‌نگاهی به Data-Oriented Programming

مفهوم برنامه‌نویسی داده‌گرا (DOP) الگوییه داده رو محور قرار می‌ده و اولویت اصلیش سازماندهی کارآمد داده‌ها است. درسته که ریشه‌هاش به LISP (1958) برمی‌گرده، اما در دهه ۲۰۱۰ با ساختارهای داده مدرن، پایدار و کارآمد، مورد توجه قرار گرفت. برخلاف برنامه‌نویسی شی‌گرا (OOP) که داده‌ها و رفتار رو درون اشیاء محصور می‌کنه، «DOP کد رو از داده‌ها جدا می‌کنه» و از ساختارهای داده عمومی و تغییرناپذیر استفاده می‌کنه.

مفهوم DOP اولین‌بار در جوامع خاصی مثل توسعه‌دهنده‌های بازی‌های ویدیویی (game devs) و سیستم‌های real-time مطرح شد. توی این حوزه‌ها، ساختار داده و نحوه‌ی دسترسی به حافظه (memory layout) نقش مهمی در عملکرد و کارایی داره. بعدها این تفکر توسط توسعه‌دهنده‌هایی مثل Yehonathan Sharvit در حوزه‌ی طراحی سیستم‌های تجاری (business systems) مطرح و ترویج شد.

کتاب “Data-Oriented Programming” (از انتشارات Manning)، یکی از منابع مرجع برای معرفی و آموزش این پارادایمه که توسط Yehonathan نوشته شده.

🔑 اصول کلیدی برنامه‌نویسی داده‌محور (DOP)

۱: داده رو از رفتار جدا کنید
در OOP، داده‌ها و متدها در کنار هم درون کلاس‌ها قرار می‌گیرن ولی در DOP، داده‌ها معمولاً به صورت ساختارهای ساده مثل JSON یا map/record تعریف می‌شون و توابع (behavior) جداگانه بر روی این داده‌ها عمل می‌شن.

۲: استفاده از داده‌های ساده (plain data)
داده‌ها باید قابل عبور بین سرویس‌ها، قابل سریال‌سازی، قابل لاگ‌کردن و قابل ذخیره باشند. این یعنی نباید شامل توابع، متدها، یا ویژگی‌هایی مثل اینترفیس‌های پیچیده باشن.

۳: عدم اعتماد به وضعیت پنهان (hidden state)
اشیای OOP ممکنه stateهای مخفی داشته باشن که باعث ایجاد باگ و رفتار غیرمنتظره بشه. در DOP، داده‌ها باید شفاف و قابل مشاهده باشن.

۴: تبدیل داده به داده
در DOP، توابع از نوع Data → Data هستند. مثل JSON in → JSON out. این باعث تست‌پذیری بسیار بالا می‌شه.

۵: همیشه داده‌ها را جداگانه بررسی کن
هیچ چیزی نباید داخل یک ساختار داده مخفی یا رمزگذاری‌شده باقی بمونه. هرچیزی که می‌خواهید بفهمید، باید با نگاه کردن به داده قابل مشاهده باشه.

⚖️ مقایسه با برنامه‌نویسی تابعی (FP)
در نگاه اول، DOP شباهت زیادی به FP داره:
- هر دو داده رو immutable در نظر می‌گیرن.
- توابع pure رو ترجیح می‌دن.

اما تفاوت مهمی وجود دارد:
- در FP تمرکز روی توابع و محاسبات ریاضی است. در حالی که توی DOP تمرکز اصلی روی ساختار داده و سادگیه.
- توی FP گاهی تمایل به انتزاع‌های سنگین مثل monad و functor است. ولی DOP از این انتزاع‌ها دوری می‌کنه و مدل خودش رو تا حد ممکن ساده و نزدیک به JSON نگه می‌داره.

⚖️ فرقش با Go و سبک داده‌محور
زبان Go خودش یک زبان شی‌گرا نیست و کلاس نداره، به همین دلیل خیلی از برنامه‌نویس‌های Go به طور ضمنی به سبک داده‌محور نزدیک هستن:

- داده‌ها struct هستند و بدون منطق پیچیده درون آن‌ها.
- تابع‌ها به صورت مستقل تعریف می‌شن و گاهی روی struct گیرنده دارن (methods) ولی معمولاً ساده‌ان.
- سریال‌سازی (JSON, protobuf) بسیار رایجه.

با این حال، Go هنوز هم اجازه‌ی مدل‌های ترکیبی می‌ده، و استفاده‌ی بیش از حد از interfaceها ممکنه باعث پنهان شدن رفتار بشه!

💪 مزیای عملی DOP
- قابلیت لاگ‌گیری بهتر: چون داده‌ها ساده‌ان، می‌شه بدون نگرانی در لاگ ثبتشون کرد.
- سازگاری بهتر با پایگاه‌داده و APIها
- تست‌پذیری بالا: توابعی که ورودی و خروجی ساده دارن، راحت‌تر تست می‌شن.
- توسعه‌پذیری توی تیم‌های بزرگ: توسعه‌دهنده‌ها بدون درگیری با کلاس‌ها و رفتارهای پیچیده می‌تونن داده رو بررسی و اصلاح کنن.

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

💬 نظر؟ سوال؟ گپ؟

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

مقدمه: OWASP چیه؟
اختصار Open Worldwide Application Security Project، یه پروژه‌ی بازمتنه که از سال ۲۰۰۱ تا امروز به صورت مداوم، در حوزه ارتقاء امنیت نرم‌افزارها فعاله. این پروژه با فراهم کردن منابع، ابزارها و استانداردهایی مثل OWASP Top 10 به توسعه‌دهنده‌ها، معماران و امنیت‌کارها کمک می‌کنه تا ریسک‌های امنیتی را بهتر بشناسن و کاهش بدن.

طی سال‌های اخیر، با افزایش وابستگی به APIها، OWASP نسخه‌ی تخصصی‌تر از Top 10 رو برای امنیت APIها منتشر کرده که آخرین نسخه‌اش مربوط به سال ۲۰۲۳ است.

1️⃣ تهدید API1: Broken Object Level Authorization
مجوزدهی ناقص در سطح آبجکت

اگر API به درستی بررسی نکنه که آیا کاربر مجاز به دسترسی به یک آبجکت خاص (مثل userId یا accountId) هست یا نه، مهاجم می‌تونه به داده‌های دیگران دسترسی پیدا کنه.

مثال:

GET /api/users/12345/profile  

شاید کاربر توی UI فقط پروفایل خودش رو ببینه، ولی اگر از طریق API شناسه کاربر دیگه‌ای رو درخواست بده می‌تونه پروفایل اون کاربر رو هم ببینه. کافیه تا سیستم چک نکنه که آیا اجازه داره پروفایل کاربر 12345 رو ببینه یا نه، اطلاعات افشا می‌شه.

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

- بررسی دقیق سطح دسترسی در لایه‌ی بک‌اند برای هر درخواست.
- استفاده از tokenهایی که به صورت داخلی با دسترسی محدود مدیریت می‌شن.
- عدم اعتماد به اطلاعات ارسال‌شده از سمت کلاینت.


2️⃣تهدید API2: Broken Authentication
احراز هویت ناقص

سیستم‌هایی که از احراز هویت ناامن یا ناقص استفاده می‌کنن ممکنه اجازه‌ی دسترسی غیرمجاز رو محیا کنن.

مثال:

- استفاده از توکن‌های قابل پیش‌بینی یا بدون انقضا.
- ارسال اطلاعات ورود در متن ساده (plaintext).

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

- استفاده از استانداردهای امن مثل OAuth 2.0 و OpenID Connect.
- توکن‌های کوتاه‌مدت با امکان ابطال (revocation).
- فعال کردن MFA (احراز هویت چندمرحله‌ای).

3️⃣تهدید API3: Broken Object Property Level Authorization
مجوزدهی ناقص در سطح ویژگی آبجکت‌ها

حتی اگر کاربر مجاز به دسترسی به یک آبجکت باشه، ممکنه مجاز به دسترسی یا تغییر همه‌ی ویژگی‌های اون آبجکت نباشه (مثلاً تاریخ ایجاد اون آبجکت یا تغییر مقدار حقوق خودش یا نقش کاربری‌اش).

مثال:
یک کاربر معمولی بتونه فیلدی مثل isAdmin=true را در payload قرار بده و نقش ادمین بگیره.

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

- اعتبارسنجی دقیق ورودی‌ها و فیلتر کردن فیلدهای حساس.
- استفاده از DTOها (Data Transfer Object) برای کنترل فیلدهایی که کاربر می‌تونه ببینه یا تغییر بده.

4️⃣تهدید API4: Unrestricted Resource Consumption
مصرف بدون محدودیت از منابع

اگر API اجازه‌ی مصرف نامحدود منابع رو فراهم کنه (مثل حافظه، CPU یا اتصالات)، ممکنه با حملاتی مثل DoS مواجه بشه.

مثال:

GET /api/messages?limit=1000000

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

- محدود کردن تعداد درخواست‌ها (Rate limiting).
- اعمال محدودیت روی پارامترهایی مثل limit, offset.
- احراز هویت برای دسترسی به عملیات سنگین.

5️⃣تهدید API5: Broken Function Level Authorization
مجوزدهی ناقص در سطح عملکرد

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

مثال:
یک کاربر معمولی بتونه از API ادمین استفاده کنه:

DELETE /api/users/12345

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

- تعیین سطح دسترسی دقیق برای هر endpoint و method.
- استفاده از Role-Based Access Control (RBAC).
- عدم اعتماد به نقش ارسال‌شده از سمت کلاینت.


💬 نظر؟ سوال؟ مفید بود؟

🔓🔓 مرور ۱۰ ریسک مهم امنیتی 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" عملاً پاسخ عملیِ «چگونه از مونولیت به مایکروسرویس برسیم؟» حساب می‌شه (اینو گفتم که بگم بین علما و بزرگان هم تفاوت نظر وجود داره 😁 خصوصا در مورد فالر و ریچاردسون؛ چون فالر استراتژی «اول مونولیت» برای شروع کارهای جدید رو طرح می‌کنه و می‌گه با این نکته که حتی اگه بعداً احتمالاً به مایکروسرویس برسید! این دیدگاه روبه‌روی موضع تیلکوف قرار می‌گیره و نشون می‌ده اختلاف‌نظر معنادار بین علما جدیه! )