چگونه اپلیکیشن خود را به چالش بکشیم تا از عملکردش اطمینان حاصل کنیم؟

زمانی که مقیاس یک پروژهٔ نرم‌افزاری بزرگ می‌شود، نگاه تیم توسعه به فرایند کدنویسی هم باید کاملاً متفاوت از شرایطی باشد که مثلاً قصد داریم یک اپ موبایل کوچک بنویسیم و در چنین شرایطی، دولوپرها باید اپلیکیشن خود را در شرایطی بی‌ثبات، نامطمئن و نامطلوب قرار دهند تا ببینند که آیا اپلیکیشن از پس چنین چالش‌هایی برخواهد آمد یا خیر.

ایجاد چالش برای سیستم
چند سال پیش Netflix مجموعه‌ای از ابزارهای مدیریت نرم‌ا‌فزار مبتنی بر کلود که برای آزمودن میزان تحمل سرویس AWS استفاده می‌شدند را با نام Chaos Monkey به صورت اپن‌سورس منتشر کرد که این وظیفه را دارا است تا برای جلوگیری از وقوع شرایط بحرانی در سیستم، از قبل چنین شرایطی را در مقیاس کوچک‌تر شبیه‌سازی کند بدین صورت که به شکل دوره‌ای تعدادی از ماشین‌های مجازی را خاموش می‌کند و آن‌ها را از ادامهٔ فعالیت باز می‌دارد. در واقع، به جای اینکه شرایط را همیشه خوب در نظر بگیرد، فرض را بر این بگذارید که بالاخره روزی هم ممکن است سیستم‌های شما با مشکل رو‌به‌رو شوند.

کار Chaos Monkey بر اساس این فرض است که بهترین راه جلوگیری از یک فاجعهٔ بزرگ این می‌باشد که قبلاً آن را در مقیاس کوچک‌تر تجربه کرده باشید تا دست‌‌کم در زمان روبه‌رو شدن با مشکلی که پیش‌بینی نشده است، آمادگی نسبی برای مقابله با آن را داشته باشید.

سنجش کدها به بهترین شکل
Jeff Atwood توسعه‌دهندهٔ نرم‌افزار و هم‌بنیان‌گذار استک اورفلو در پستی تحت عنوان Doing Terrible Things To Your Code در مورد روش‌هایی برای بهبود کدها به موردی مشابه بحث قبل اشاره می‌کند و پیشنهاد می‌دهد تا به قول معروف بدترین بلاها را بر سر کد خود بیاورید! در همین راستا وی معتقد است:

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

در عمل، این کار به معنای آن است که برنامه‌نویسان نیاز به آگاهی از حداقل اشتباهات رایجی دارند که معمولاً همهٔ برنامه‌نویسان مرتکب می‌شوند تا در نهایت بتوانند با آن خطاها مقابله کنند. این حرف به معنای آن است که شما به عنوان خالق یک اپلیکیشن باید بهترین تِستِر آن هم باشید و با دست‌کاری کدهای خود، تمام نواقص و خطاهای موجود و همچنین ریشهٔ آن‌ها را بیابید و اصلاح کنید (برای آشنایی بیشتر با Jeff Atwood، به مقالهٔ ارسال نامهٔ تشکرآمیز برای Jeff Atwood (هم‌بنیا‌گذار استک اورفلو) و دریافت پاسخ در کمال ناباوری! مراجعه نمایید.)

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

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

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