#️⃣ در ستایش اعداد...

#️⃣ در ستایش اعداد...

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 و جلوگیری خودکار از ورود کد فاقد متریک‌های قابل قبول به محیط‌های استیج و پروداکشن است.

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