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

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

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

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

ایجاد چالش برای سیستم
چند سال پیش Netflix -شرکت آمریکایی ارائه دهندهٔ خدمات آنلاین رسانه‌ای- مجموعه‌ای از ابزارهای مدیریت نرم‌ا‌فزار مبتنی بر کلود را که برای آزمودن میزان تحمل سرویس AWS آمازون استفاده می‌شوند با نام Chaos Monkey به صورت اپن‌سورس منتشر کرد.

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

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

سنجش کدها به بهترین شکل
Jeff Atwood توسعه‌دهندهٔ نرم‌افزار و هم‌بنیان‌گذار استک اورفلو در یکی از پست‌های وبلاگ معروف خود Coding Horror در مورد روش‌هایی برای بهبود کدها به موردی مشابه بحث قبل اشاره می‌کند و پیشنهاد می‌دهد تا به قول معروف، بدترین بلاها را بر سر کد خود بیاورید! در همین راستا وی می‌نویسد:

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

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

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

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

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

آنطور که مشهود است تا زمانی که همهٔ دولوپرها مقید به پرداخت بدهی فنی (Technical Debt) خود نباشند، یعنی به جای آنکه کدهای خود را تمیز و با دقت و حوصله بنویسند به دنبال انجام یک کار سریع و بی‌دقت باشند، کار چندانی نمی‌توان برای بهبود این شرایط انجام داد.

منبع