کانال سوئز و باگ سرور لایو

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

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

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

1- هیچ اهمیتی نداره اگه نرم افزار، سرویس یا وب سایت شما در طی 150 سال گذشته بدون مشکل کار کرده، اینو بدونید که همیشه یک باگ وجود داره. پس همیشه چیزی برای بهتر کردن هست.

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

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

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

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

5- هیچ وقت باگ رو دست کم نگیرید.

معمولا برنامه نویس ها، فیچر ها رو بر اساس پیچیدگیشون اولویت بندی میکنن ولی کاربر ها بر اساس نیازشون که اینها لزوما منطبق بر هم نیستند. پس اهمیتی نداره باگ چیه و کجاست، ساده است یا پیچیده. همه تلاش خودتون رو بکنید، به کاربر های خودتون متعهد باشید حتی اگه فقط چند کاربر دارید. ممکنه در کمتر از 150 سال، یک روز بعد از ظهر 369 کشتی منتظر این باشن که شما باگ سیستم تون رو رفع کنید فقط چون شما اونو جدی نگرفتید. این رو بدونید لحظه ای که شما فکر میکنید کسی از این فیچر برنامه استفاده نمیکنه، همون لحظه یه باگ سرور لایو به وجود میارید.

نسخه اصلی متن
https://karvan-jafi.medium.com/suez-canal-softwares-production-server-bugs-1525ac8b336b