تفاوت برنامه‌نویسی در دنیای واقعی و آکادمیک، با نگاهی به پروژه مهاجرت سپه

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

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

مانورهای مهاجرتی

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

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

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

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

وقتی قرار است بانکی به قدمت ۹۰ سال را مهاجرت دهیم، لازم است پیش از مهاجرت مانورهای متعددی داشته باشیم تا با تمام عوامل محیطی و فنی آشنایی کافی به‌دست بیاوریم.

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

مهاجرت بانکی

مهاجرت داده‌های یک بانک مثل اطلاعات مشتریان، سپرده، حساب و ...، یکی از حساس‌ترین و چالش‌برانگیزترین کارهایی است که به عنوان یک برنامه‌نویس حوزه بانکداری می‌توانید انجام دهید، اما از نظر من، این کار بیش از آنکه محصول زبان‌های برنامه‌نویسی باشد، محصول ذهن‌های تحلیلگری است که می‌توانند در شرایط خاص، مسائل را به شیوه‌های مختلف حل کنند و اصطلاحا، در این شرایط بتوانند out of box فکر کنند.

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

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

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

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

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

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

من با یکی از همکاران خبره در زمینه دیتابیس مشورت کردم. ماحصل مشورت ما تبدیل شد به یک کوئری دیتابیس که می‌توان آن را PL نامید و به کمک آن، ۱۴ ساعت را به ۲۰ دقیقه کاهش دادیم. می‌بینید؟ اینجا لازم نبود از دانش جاوایی خود استفاده کنم، بلکه لازم بود از فرد درستی مشورت بگیرم و سراغ ابزار صحیحی بروم، نه لزوما ابزاری که کار با آن را بلدم.

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

مغز من هنگام تصمیم‌گیری همواره سراغ تکنولوژی‌هایی می‌رود که با آن‌ها آشناست، به همین دلیل است که شما باید Full stack باشید. لازم است حتی UI/UX بدانید تا بتوانید در زمان نیاز، به سراغ متخصص آن حوزه بروید یا حتی به کمک سرچ در گوگل، نیازهای خود را برطرف کنید.

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

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

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

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

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

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

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