توسعه‌ی کارایی‌گرا (Performance Driven Development)

مقدمه

فرایندهای متنوعی برای توسعه‌ی نرم‌افزار موجود است. بعضی‌ را احتمالا بیشتر شنیده‌ایم مثل توسعه‌ی آزمون‌گرا (Test Driven Development)، بعضی‌ را کمتر مثل توسعه‌ی ویژگی‌گرا (Feature Driven Development). توسعه‌ی کارایی‌گرا نیز یک فرایند برای توسعه‌ی نرم‌افزارهایی است که کارایی (Performance) در آن‌ها اولویت اول است. پس اگر در تیم توسعه‌ی یک پیام‌رسان، یک هسته‌ی بانکی با تراکنش بالا یا هر نرم‌افزار دیگری هستید که کارایی در آن مهم‌ترین گلوگاه موفقیت محصول است، حتما مخاطب این نوشته هستید. برای شناخت این فرایند، ابتدا ترجمه‌ی قسمتی از کتاب آموزنده‌ی هنر آزمون کارایی اپلیکیشن (The Art of Application Performance Testing)، نوشته‌ی یان مالینو را آورده‌ام و سپس نکاتی را که مفید می‌دانستم، افزوده‌ام.

شما از نظر بلوغ آزمون کارایی در چه سطحی هستید؟

مالینو در فصل اول کتاب از مفهوم «بلوغ آزمون کارایی» و تاثیر آن در کیفیت عملکرد نرم‌افزار سخن به میان می‌آورد. او با استناد به تحقیقی که در سال ۲۰۰۶ توسط فارستر انجام شده است به این مساله می‌پردازد. در این مطالعه از ملاک عددی «درصد مشکلات کارایی که در محیط پروداکشن نمایان می‌شوند نسبت به تعداد کل مشکلات کارایی» برای سنجش کیفیت استفاده شده است. همچنین سه سطح در آزمون کارایی تعریف می‌شود: آتش‌نشانی، صحت‌سنجی کارایی و توسعه کارایی‌گرا.

سطح اول: آتش‌نشانی

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

سطح دوم: صحت‌سنجی کارایی

سطح دوم، صحت‌سنجی کارایی شرکت‌هایی را شامل می‌شود که برای آزمون کارایی وقت کنار می‌گذارند اما نه تا آخرین مراحل چرخه‌ی عمر اپلیکیشن؛ بنابراین، همچنان تعداد قابل توجهی از مشکلات در پروداکشن رخ می‌دهد. این رویکرد در حال حاضر رایج‌ترین رویکرد سازمان‌هاست. اگر در تیم شما هم قبل از یک استقرار مهم که شامل تغییرات زیادی در سیستم می‌شود، محیط پروداکشن را شبیه‌سازی نموده و برای اطمینان از اوضاع یک آزمون کارایی اجرا می‌کنید، در سطح دوم بلوغ آزمون کارایی قرار دارید. خبر خوش آنکه احتمالا از ۷۰٪ مشکلات کارایی قبل از استقرار اطلاع می‌یابید اما همچنان ۳۰٪ مشکلات کارایی شما را در پروداکشن غافل‌گیر خواهد کرد.

سطح سوم: کارایی‌گرا

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

توسعه‌ی کارایی‌گرا

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

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

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

به عنوان جمع‌بندی اگر چالش‌های کارایی برای نرم‌افزاری که در حال توسعه‌ی آن هستید حیاتی است، یعنی چالش‌هایی از این جنس:

آیا سیستم می‌تواند به صد هزار درخواست در ثانیه پاسخ دهد؟ (Throughput)
آیا می‌تواند تضمین کند ۹۹٪ درخواست‌ها در کمتر از ۱ ثانیه پاسخ می‌گیرند؟ (Latency)
آیا با افزایش کاربران می‌تواند مقیاس یابد؟ (Scalability)
و هر سوال دیگری که با کارایی سر و کار دارد.

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

در پایان به تعدادی از چالش‌های این فرایند اشاره می‌کنم تا فرصتی باشد برای جستجوها، مطالعه‌ها و شاید نوشته‌های بعدی.

• سنجه‌های اصلی کارایی سیستم ما چیست؟ گذردهی برای ما مهم‌تر است یا تاخیر؟
• چطور این سنجه‌ها را اندازه‌گیری کنیم و از دقت اندازه‌گیری خود مطمئن شویم؟
• چطور آزمون کارایی را در خط لوله‌ی یک‌پارچه‌سازی (CI Pipeline) خودکار سازی کنیم؟
• چطور نتایج آزمون را به نحوی ذخیره‌سازی کنیم تا با آزمون‌های قبلی قابل مقایسه باشد؟
• کدام رویکرد آزمون کارایی مناسب نیاز ماست؟ Load Test یا Stress Test یا رویکردهای دیگر؟

پی‌نوشت

برای ترجمه‌ی Performance Driven Development به «توسعه‌ی کارایی‌گرا» گزینه‌های دیگری هم مطرح بود. مثلا در ویکیپدیا از عبارت «توسعه‌ی آزمون‌محور» برای Test Driven Development استفاده شده است که به نظر من مناسب نیست، عبارت «محور» چون «دوران حول یک محور» را تداعی می‌کند اندکی رهزن است؛ در این صورت «کیفیت» و «ارزش» محور است و نه روش. «کارایی‌گرا» را ترجیح دادم؛ کوتاه است و ساده. اما همچنان پذیرای پیشنهادهای بهتر هستم چرا که به نظرم فرایند ترجمه، مستلزم حوصله و دقت است و به مرور بهینه‌ می‌شود؛ مثل صیقل خوردن سنگ‌های رودخانه!