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

🎯 تحلیل پویای برنامه یا 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(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 است که اجازه نده کدی که قوانین رو معیارهای کیفی رو پاس نکرده وارد برنچ پروداکشن یا استیج بشه.

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

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