Transcription
Ось те, про що більшість програмних команд знають, але не завжди говорять. Як розробники часто витрачають більше часу на спроби зрозуміти існуючі системи, ніж на написання нового коду. Насправді, дослідження показують, що близько 60-70% часу розробника йде на розуміння контексту, перш ніж можна буде безпечно внести будь-які зміни. Це багато витраченого часу. Це схоже на те, як вам вручають ключі від будинку, який ви не будували. Звісно, ви можете бачити кімнати, але ви не знаєте, чому вимикач знаходиться в шафі, або чому одна труба ванної кімнати підключена до кухні. Вам потрібно розібратися з усім цим, перш ніж ви зможете безпечно провести ремонт. Сьогодні ми поговоримо про те, як агентне кодування змінює це, і як команди розробки програмного забезпечення використовують його для вирішення однієї зі своїх найбільших проблем – модернізації.
Тепер, давайте на секунду відступимо. Агентне кодування означає системи ШІ, які можуть автономно орієнтуватися та розуміти кодові бази, пропонувати зміни та виконувати завдання з мінімальним втручанням людини. І модернізація. Це означає взяти існуючу програму та розвивати її для задоволення нових системних вимог та випадків використання, не порушуючи те, що вже працює. Сьогодні ми будемо слідувати прикладу того, як команди розробки використовують агентне кодування, чому застарілий код, як Java, може бути складним для зміни, а потім, як це впливає на процес розробки загалом.
Дозвольте мені створити сцену, щоб зробити це реальним. Ми поставимо себе на місце компанії, що надає фінансові послуги, яка використовує велику програму на Java. Ця програма обробляє клієнтські рахунки, обробку кредитів, платежі та конвеєри звітності в одному місці. Вводиться вимога додати оцінку ризиків у реальному часі за допомогою ШІ, щоб клієнти могли отримувати миттєві рішення щодо кредитів. Звучить чудово, чи не так? Але щоб досягти цього, команді потрібно модернізувати. Як згадувалося раніше, не порушуючи нічого, що вже працює. І ось тут стає цікаво для нашої команди.
Проблема з модернізацією насправді не в самому старому застарілому коді. Це втрачене розуміння. Уявіть собі це як айсберг. Код, який ви бачите, – це лише верхівка. Під поверхнею – все, що зникло з часом. Чому процес схвалення кредиту перевіряє в певному порядку. Чому заплановане завдання звітності виконується о 2 годині ночі. Чому встановлені часові обмеження, або чому зміна одного рядка в платіжному потоці одного разу заморозила клієнтські рахунки на 4 години. Наша команда, можливо, не записала це. Люди, які це створили, могли піти, і ці знання тепер поховані під роками виправлень та оновлень.
Отже, давайте поговоримо про три речі, які роблять це особливо складним для нашої команди, коли вони намагаються додати новий інструмент оцінки ризиків. По-перше, це заплутані залежності. Різні частини програми з часом стали глибоко пов'язані таким чином, що команда ніколи повністю не відображала. Змініть спосіб розрахунку процентної ставки, і раптом система звітності про відповідність починає позначати неправильні рахунки. Чому? Тому що дві системи тихо ділили таблицю бази даних, про яку ніхто в команді не знав.
По-друге, це прогалини у фреймворках. Система працює на Java 8, яка обробляє багатопоточність та управління пам'яттю зовсім інакше, ніж сучасні версії. Щось таке звичайне, як оновлення до Java 17, може виявити десятки прихованих проблем сумісності та бібліотек, до яких команда не торкалася роками.
По-третє, це зовнішні з'єднання, які не задокументовані. Ця система підключається до зовнішніх кредитних бюро, платіжних мереж та систем регуляторної звітності, кожна з яких має свої суворі вимоги до формату даних. Змініть формат одного поля внутрішньо, і нічний звіт про відповідність може почати відхиляти подання, без того, щоб хтось у команді негайно зрозумів, чому.
Все це тут може сприяти тим 60-70% часу розробника, що зникає, і саме тому наша команда не змогла просунутися вперед у реальному часі оцінки ризиків, про яку просить бізнес. Кожен раз, коли вони наближаються, складність того, що може зламатися, відтягує їх назад. І це саме ті проблеми, які призначений вирішувати партнер з розробки ШІ. Замість того, щоб залишати наших розробників розплутувати всю цю складність вручну, партнер з розробки ШІ втручається, щоб провести розслідування разом з ними. Уявіть собі це як інспектора будівництва, який може зробити рентген всієї системи, простежити кожен дріт і намалювати кожну трубу, перш ніж хтось візьметься за молоток.
І важливо, це відбувається не як одноразовий прохід, а як частина ітеративного циклу модернізації. Нам потрібно зрозуміти, що існує, внести безпечну зміну, перевірити її, а потім розширюватися звідти. Модернізація буде виглядати трохи по-різному для кожної команди, але ось як виглядає цикл для нашої команди фінансових послуг, коли вони працюють над винесенням логіки прийняття рішень щодо кредитів у власну систему.
Крок перший – аналіз кодової бази. Наш партнер з розробки ШІ аналізує програму та створює робочу модель того, як все пов'язано. Шляхи викликів, потоки даних та приховані залежності. І майже відразу він виявляє щось, чого команда не знала. Кожна заявка на кредит насправді запускає дуже специфічну послідовність; перевірки кредитоспроможності, перегляди списків спостереження, перевірки відповідності в суворому порядку, який ніколи ніде не був записаний. Без цього виявлення команда б відокремила неправильну логіку. Рішення щодо кредитів почали б надходити неправильно, і це той тип проблеми, який дуже швидко виявляється у звіті про відповідність. Цей ризик був усунений ще до того, як був змінений будь-який код.
Крок другий – визначення безпечних меж для змін. З цією моделлю наш партнер з розробки ШІ пропонує, де безпечно відокремити логіку прийняття рішень щодо кредитів, і не тільки що витягти, але й що від нього залежить, від чого він залежить, і як нова служба повинна взаємодіяти з рештою системи. Він позначає граничні умови, спільні дані, приховані зв'язки. Тому команда не вгадує, де провести межу. Натомість вони перевіряють межу, яка вже була відображена.
Крок третій – генерація тестового покриття. Перш ніж щось буде змінено, партнер з розробки ШІ генерує широкий набір тестів на основі того, що він виявив. Не тільки щасливі шляхи, але й граничні випадки, включаючи тайм-аути перевірки кредитоспроможності, часткові збої в заявках та клієнтів, які позначаються в середині процесу. Він створює покриття навколо реальної поведінки, а не тільки того, що команда припускала, що робить система. Чи можливо це в кожному сценарії? Ні. Але це набагато більше покриття, ніж команда реально могла б створити з нуля, особливо під тиском часу.
Крок четвертий – наші розробники переглядають та затверджують. Ось тут розробники повертаються. Вони переглядають запропоновані межі, перевіряють припущення та перевіряють згенеровані тести, а потім затверджують кожен крок, перш ніж щось буде рухатися вперед. Чого вони не роблять, це витрачати тижні, копаючись у застарілому коді, намагаючись зрозуміти, що з чим розмовляє. Вони приходять зі своїм судженням.
Крок п'ятий – запускати старе та нове пліч-о-пліч. Після введення нової служби прийняття рішень щодо кредитів, вона не замінює стару негайно. Вона буде працювати поруч з нею. Той самий вхід, два виходи. Якщо є будь-яка різниця, партнер з розробки ШІ негайно позначає її. Повний контекст, що змінилося і де це відхилилося, щоб команда могла виправити проблеми рано, перш ніж клієнт побачить це, і перш ніж це потрапить до регуляторного звіту.
Тепер, дозволити ШІ працювати з системою, яка обробляє реальні заявки на кредити, яка живить звіти про відповідність, і яку регулятори очікують, що буде правильною щоразу, це не те, що команда повинна сприймати легковажно. Це працює лише тоді, коли контроль, перевірка та відстежуваність вбудовані з самого початку. Для будь-якої команди це проявляється трьома дуже конкретними способами.
По-перше, це людське схвалення. Будь-які зміни, особливо ті, що впливають на конвеєри звітності, повинні бути переглянуті та схвалені перед тим, як вони кудись потраплять, і розробником. По-друге, це повна історія змін. Все знаходиться в Git, легко переглядається, легко відкочується. І останнє – це відсутність автономного розгортання. Розробники завжди беруть участь, перш ніж щось вийде в ефір. Ці запобіжники роблять весь підхід достатньо надійним для використання командою на системі, від якої щодня залежать реальні клієнти та регулятори.
Замість того, щоб витрачати купу часу на навігацію старим кодом, наша команда розробки вчасно доставила функцію оцінки ризиків у реальному часі. Час, який раніше втрачався на археологію застарілого коду, пішов безпосередньо на необхідну роботу з розробки. Отже, як ваша команда зараз справляється з модернізацією?