«Програмувати, враховуючи найгірший сценарій»: як розробнику не боятися багів та що для цього робити

Усім привіт, мене звати Костянтин Різник, я Delivery Director в компанії Luxoft. У цій статті хочу поговорити про те, що раніше чи пізніше спіткає на професійному шляху кожного з нас. Про помилки.

Усі ми припускаємося помилок, й іноді вони можуть мати велику ціну у буквальному розумінні. До прикладу, у 2021 році в компанії «Tesla» стався збій у програмному забезпеченні автопілота, в результаті якого їхні акції впали на 3%, а це близько $20 млрд. Ця сума перевищує ВВП маленької держави.

За статистикою, щорічно збої програмного забезпечення обходяться ринку корпоративного ПЗ приблизно в $61 млрд, а понад 620 млн годин на рік розробники витрачають на усунення таких неполадок. Тож дрібні помилки — не такі вже й безгрішні, коли йдеться про суми й наслідки.

Сфера банкінгу — одна з тих, де ці ризики також існують, бо «незначний баг» може призвести до розорення компанії, а зайвий нуль у написаному коді — втрати роботи тисяч працівників.

Далі говоритиму про те, як вберегтися від багів, що робити, якщо вони вже трапилися, і який, на мою думку, алгоритм дій IT-спеціаліста, який хоче ніколи не помилятися.

Баги в фінансовій сфері — найдорожчі. Але є одне «але»...

Фінансова сфера для IT-спеціаліста передбачає роботу з великими цифрами, тому треба вміти брати на себе відповідальність і бути готовим до ризиків, бо зазвичай йдеться про величезні суми.

Як казав один колега, ми завжди маємо розробляти ПЗ, враховуючи найгірший сценарій того, що може трапитись. Одним з прикладів є термін, відомий як «fat finger» — він використовується для опису помилок вводу даних з клавіатури.

Один японський трейдер трішки помилився в кількості нулів й продав завелику кількість акцій. На той момент розмір помилки дорівнював річному бюджету такої країни як Швеція. У результаті компанія розорилась і багато людей втратили роботу.

У кожній сфері є ті критичні частини функціонала, які потребують максимальної концентрації уваги. І розробник, який займається створенням програмного забезпечення, має максимально точно розуміти визначене завдання, бути уважним, підходити до роботи з холодною головою та серйозно ставитися до обов’язків.

Він повинен ретельно аналізувати кожен крок, розуміти вимоги й очікування замовника, враховувати можливі наслідки неправильної реалізації. Це може включати фінансові втрати, витік даних, порушення безпеки, зниження продуктивності або недовіру з боку користувачів.

Але все дуже відносно, бо у фінансовій сфері йдеться здебільшого про гроші. У медицині ж «баг» може коштувати життя пацієнта, в автоіндустрії — безпеки, а на підприємствах, що займаються виробництвом хімічних речовин — забруднення навколишнього середовища, що може завдати серйозної шкоди здоров’ю людей та тварин.

Хмарні рішення як перша допомога людині

Сьогодні апаратних «багів» стає все менше й менше, тому що більшість клієнтів переходять на роботу з різними типами хмарних рішень, таких як Amazon Web Services (AWS), Google Cloud тощо.

Щобільше, великі хмарні платформи надають надійну та стабільну інфраструктуру для розгортання програмного забезпечення. Інвестують значні ресурси у високоефективне обладнання, мережеві підключення та безпекові заходи, що дозволяє знизити ризики апаратних вад. Відтак розробники можуть зосередитися на функціональних аспектах програми, знімаючи частину відповідальності за апаратну інфраструктуру зі своїх плечей.

І саме остання перевага як ніщо інше допомагає мінімізувати виникнення помилок, оскільки найвразливішим місцем в системі залишається людина. Людина ставить завдання, людина приймає їх в роботу і слідкує за виконанням. На будь-якому з цих етапів може статися помилка.

До того ж на фахівця можуть впливати такі фактори як перевтома чи відчуття емоційної нестабільності. Він також може відволіктися, що вплине на рішення. Тому людина залишається як найважливішою, так і найвразливішою ланкою при розробці програмного забезпечення.

За час моєї практики найдорожчою помилкою через людський фактор був випадок, коли тестувальники забули перейти з Production Environment на QA-environment. В результаті чого було ініційовано виконання фінансової транзакції на понад $370 000+.

Добре, що завдяки гарно налагодженим процесам цю транзакцію помітили на етапі фізичного переказу коштів та відмінили, але компанія зазнала фінансових та репутаційних втрат.

Як запобігти помилкам та що робити, якщо вони вже сталися

Як ми вже зрозуміли, вартість і, що не менш важливо, репутація, змушують компанії продумувати сценарії мінімізації «багів». Починаючи з підбору спеціалістів, котрі здатні працювати з відповідними завданнями, прискіпливо перевіряти написаний код та шукати неточності у бізнес-функціоналі.

Тому порада для спеціалістів, котрі лише починають працювати у фінансовому секторі: потрібно не боятися вчити нове та бути готовим виконувати рутинні завдання. Звучить банально, але це базується на життєвому досвіді. Програміст повинен вміти систематизувати інформацію, працювати з нецікавими завданнями, розуміти їх пріоритетність і ставити багато питань.

Також IT-спеціалісти мають пам’ятати — shit happens. Тому треба бути готовими до того, що колись баг трапиться, найважливіше в такому випадку — комунікація. Бо різний рівень критичності цієї помилки може призвести до різних наслідків.

Якщо фахівець запрограмував кнопку неправильного кольору, це може не відповідати корпоративному стилю, але така неточність не є критичною. Проте якщо це помилка в розрахунковому рахунку — все може закінчитися погано.

Це мій улюблений приклад, бо якщо ви вказуєте у рахунку хоча б одну цифру неправильно, працюватиме все, окрім надходження коштів. І знайти такий дефект відразу дуже складно.

Тому, якщо у вас є розрахунковий рахунок компанії — перевіряйте його генерацію одразу і під час кожного релізу нової версії системи. Бо час, витрачений на те, щоб пофіксити цю проблему, грає проти вас.

Якщо ж в IT-спеціаліста таки стався баг, він має розуміти його наслідки. На Заході прийнято страхувати робочі помилки. Кожен фахівець, який підписує контракт із великою компанією, має це зробити. У Канаді та США сума страхової виплати стандартно дорівнює одному мільйону доларів.

Тобто якщо в результаті роботи втрачаються дані, оприлюднюється конфіденційна інформація чи трапляється помилка через людський фактор, відповідний фахівець може бути оштрафований. Щоправда, це не стосується найманих працівників, за них несуть повну матеріальну відповідальність працедавці.

Щоб запобігти таким випадкам, компанії створюють і реалізують процедури та тренінги, проводять аудити. Також допомагає політика «закритих дверей»: кожен знає лише те, що йому потрібно для виконання своєї частини роботи.

Існує чотири «золоті правила», дотримуючись яких, можна зменшити ризик виникнення помилок у вашій роботі.

Правильне налагодження процесів. Коли на усіх етапах розробки продукту кожен фахівець знає свою роль, обов’язки та дотримується правил — майже неможливо забути чи пропустити щось критичне чи важливе.
Правильна і актуалізована документація. Прописуйте всі етапи виконання вашої роботи, у майбутньому це допоможе зекономити багато часу на пошук та виправлення багів. Це найдешевший і найпростіший спосіб застерегти себе та своїх колег від помилки. Також мінімізує час на розуміння написаного коду у майбутньому.
Тестування. Не нехтуйте ним. Все має починатись з Unit tests. Функціональне покриття ними всього коду або його частини хоча б на 90% зможе мінімізувати виникнення багів. Проводьте ручне тестування, інтеграційне тестування, автоматизуйте тривіальні сценарії — тримайте руку на пульсі якості протягом всього часу створення програмного забезпечення.
Правило приймання продукту. Це верифікація рішень бізнесом, який буде користуватися вашим продуктом. Якщо правильно і повноцінно провести приймальне тестування, то ще можна виявити помилки, виправлення яких буде мати хоча б мінімальний репутаційний вплив. Крім того, його проведенн допоможе бізнесу зрозуміти більше про функціонал системи й те, як правильно ними користуватися.

Що допомагає запобігти багам на рівні менеджменту команди

Найдешевше і найшвидше пофіксити баг на етапі розробки бізнес-задач. Тобто якщо з функціонального й технічного боків тут все досконало продумати, проблему може й не доведеться вирішувати.

Потім відбувається процес розробки, коли програміст пише код. Він теж має відповідально ставитися до своєї роботи й попередньо написати Unit test, за допомогою якого протестує прості частини коду, напише інтеграційні тести, що протестують вже інтеграцію коду в складнішій системі.

На цьому етапі теж відносно дешево виправити помилку, оскільки в IT-спеціаліста алгоритм його дій все ще свіжий в пам’яті. Після цього розпочинається процес тестування, коли вже готовий проєкт збирають докупи, і тест-інженери, відповідно до кейсів з бізнес-документації, починають його тестувати.

Крім того, в IT існує так звана «армія» Quality Assurance, яка бореться за якість тих продуктів, що виходять на ринок.

Бізнес-документація також може виявитися джерелом помилки. Якщо у ній був допущений баг, а тест-кейси писали, базуючись саме на цій документації, то з дуже великою ймовірністю ця помилка потрапить у світ.

Як приклад: якось у бізнес-документації замість крапки для розділення цілих і десяткових чисел поставили кому, а у США, наприклад, кома — роздільник не цілих і десяткових, а тисячних чисел.

Така неточність може завдати шкоди як репутації компанії, так і спричинити до серйозних фінансових втрат. Щоб потім її пофіксити, доведеться виправляти документацію, переписувати код, тестувати, випускати на продакшн — тобто заново запускати усі процеси.

Крім того, це не станеться раптово. Поки фахівці виправлятимуть помилку, продукт з нею вже може існувати на етапі виробництва. Тому найдорожче виправляти баг, коли він вже «плодоносить».

Помилок боятися не потрібно, їх припускаються у кожній сфері. З рештою — поки штучний інтелект повністю не перебрав на себе увесь функціонал людини — світ приречений на неточності, що можуть зумовити непередбачувані наслідки.

Тому потрібно запастися терпінням та робити усе, залежне від себе — перевіряти, тестувати та підходити до виконання завдань із холодною головою, щоб випадково не зробити помилку, вартістю в бюджет Швеції.