#️⃣ در ستایش اعداد...
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هایی که مدت زیادی باز می‌مونن بدون فعالیت. این موارد معمولاً نشان‌دهنده مشکلات در اولویت‌بندی، درگیری منابع، یا ابهام در نیازمندی‌هاست.

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

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