حدس نزنید، اندازه بگیرید

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

قدم بعدی استفاده از پروفایلری (profiler) بود که کنت بک نوشته بود تا بتوانیم کارایی و سرعت سیستم را بررسی کنیم. بعد از اجرای پروفایلر، با کمال تعجب فهمیدیم که هیچ یک از حدس‌های ما دلیل کندی سیستم نبود. جالب‌تر این که متوجه شدیم که نصف زمان اجرای سیستم صرف ایجاد متغیری از نوع تاریخ می‌شود. موضوع عجیب‌تر این بود که تمام این متغیرها مقدار ثابت و یکسانی داشتند. … وقتی این مشکل را به کمک یک متغیر استاتیک حل کردیم سرعت سیستم دو برابر شد.

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

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

درسی که باید بیاموزیم این است:‌حتی اگر می‌دانید واقعا در سیستم شما چه اتفاقی می‌افتد، کارایی و سرعت سیستم را اندازه بگیرد و از حدس و گمانه‌زنی پرهیز کنید. با این کار، شما چیزهای جدیدی از سیستم می‌فهمید و ۹۰ درصد مواقع چیزی که می‌فهمید این است که حدس شما اشتباه بوده.

نویسنده: ران جفری (Ron Jeffries)

مرجع: Refactoring, 2nd Edition, by Martin Fowler.

گزیده:
سادگی شرط لازم برای اعتمادپذیری است. (Simplicity is prerequisite for reliability.)
ادگر دایکسترا