اشکال زدایی اردکی

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

افراد راه حل‌های مختلفی برای این طور مواقع دارند. مثلاً بعضی‌ها به پیاده روی می‌روند، بعضی‌ها کار را تعطیل می‌کنند و به منزل بر می‌گردند، بعضی‌ها دوش می‌گیرند و… اما یک راه حل جالب دیگر وجود دارد: اشکال زدایی اردکی.

در این روش برنامه‌نویس یک اردک پلاستیکی (اسباب بازی) را روی میز گذاشته و تک تک خطوط برنامه را برایش توضیح می‌دهد. به این ترتیب امکان پیدا کردن خطا خیلی بالاتر می‌رود. تجربه نشان داده که توضیح دادن کامل برنامه به یک نفر دیگر می‌توان در پیدا کردن زودتر باگ موثر باشد. نام دیگر این روش «بلند فکر کردن» است.

پیغام خطای کشنده

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

به تازگی یکی از این پیغام خطاهای کشنده برای من اتفاق افتاد. زمانی که در حال فعال‌سازی Caching سطح دوم برای یک برنامه‌ی مبتنی بر Castle ActiveRecord بودم دچار خطای زیر شدم:

Unable to cast object of type ‘NHibernate.Caches.SysCache.SysCacheProvider’ to type ‘NHibernate.Cache.ICacheProvider’.

NHibernate.Caches.SysCache نام اسمبلی است که قابلیت Second Level Cache را به NHibernate و Castle Active Record اضافه می‌کند. ظاهر امر نشان می‌داد که بین اسمبلی‌ها مورد استفاده ناهمخوانی نسخه‌ای وجود دارد. مثلا NHibernate من نسخه 2.1 است ولی SysCache مورد استفاده نسخه 3.0 است. به همین دلیل بارها و بارها نسخه‌های متفاوت NHibernate و Castle و SysCache را از SourceForge دریافت کردم ولی مشکل حل نشد. سعی کردم به جای SysCache از دیگر Cache Providerها استفاده کنم ولی آن هم نشد. در ادامه این سعی و تلاش‌ها چندین بار تنظیمات Caching مورد استفاده را در web.config و mappingها چک کردم، سورس‌های Castle و SysCache را خودم کامپایل کردم و حتی به فکر افتادم خودم یک Cache Provider ساده بنویسم اما مشکل حل نشد که نشد.

خلاصه این که در اوج ناامیدی بودم که در یکی از آن «لحظات طلایی» متوجه علت خطا شدم. چون تعداد Assemblyهای مورد استفاده در ارتباط با NHibernate و Castle زیاد بود، یکی از دوستان آنها را با هم merge کرده بود تا یک اسمبلی واحد تشکیل گردد. من هم اسمبلی NHibernate.Caches.SysCache را در کنار اسمبلی فوق‌الذکر گذاشته بودم و در تنظیم cache.provider_class نام اسمبلی NHibernate.Caches.SysCache را ذکر کرده بودم، در حالی که باید اسمبلی NHibernate.Caches.SysCache را با مجموعه قبلی merge (با استفاده از ilmerge.exe) کرده و در cache.provider_class نام اسمبلی حاصل از merge را ذکر می‌کردم!

‫شرکت‌های bug دوست

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

متاسفانه خیلی از تیم‌ها کارشان را طوری انجام می‌دهند که مدام به باگ و خطا بر می‌خورند بدون آن که مدیریت خیلی به آنها حساس شود. لابد شما هم دیده‌اید افرادی را که همیشه ویژوال استودیو را در حالت debug اجرا می‌کنند چون هر لحظه ممکن است به یک باگ جدید برخورد نمایند. در این طور تیم‌ها معمولاً یک نفر هم تمام وقت سرگرم سر و کله زدن با مشتری و دریافت پیغام خطاهای آنهاست. اصولاً بعضی از این طور شرکت‌ها عادت کرده‌اند توسعه نرم‌افزار را به صورت باگ محور پیش ببرند. یعنی کلیاتی از کار را به صورت سطحی و درهم و برهم انجام داده و سپس عمده‌ی وقتشان را اختصاص می‌دهند به debug آن برنامه. یادم می‌آید در شرکتی کار می‌کردم که برای پیشبرد کار از اصطلاح «زخمی کردن» استفاده می‌کردند. به این معنی که یک نفر که از همه قدیمی‌تر بود یک ساختار و طراحی ضعیف برای پروژه ایجاد کرده و بخشی از کدهای آن را با عجله و بدون هیچ گونه تستی نوشته و به قول خودش کار را «زخمی می‌کرد». سپس دیگر افراد آن «بنای کج» را از طریق پیدا کردن باگ‌های متعدد جلو می‌بردند. جالب آن جا بود که روند پیدا شدن باگ‌ها حتی وقتی هم که نرم‌افزار دست مشتری بود همچنان ادامه داشت.

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