Технічний борг: програмна епідемія

Програмне забезпечення схоже на наше здоров’я: ми не підтримуємо його так, як слід

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

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

Принципи збереження здоров’я не важкі. Це важка дисципліна. Ось чому люди отримують підтримку, наприклад, отримання тренера: тренер тут не для того, щоб розповідати вам, що робити, а для того, щоб нагадати вам про основні принципи та нести відповідальність. Знання тренера доступні за кілька десятків доларів (книги чи вміст в Інтернеті), але справжня цінність тренера – це дисципліна та мотивація, які вони приносять.

Програмне забезпечення нічим не відрізняється від нашого здоров’я. Ми точно знаємо, як зберегти програмне забезпечення здоровим та простим у обслуговуванні. І все ж ми не в змозі це зробити. Ми продовжуємо накопичувати нові можливості, не думаючи про наслідки для архітектури. Ми забуваємо задокументувати новий код, тому що «нам потрібно швидко доставити цей код». Ми продовжуємо накопичувати проблеми в кодовій базі, доки не усвідомлюємо, що надто пізно, і єдиним показником якості нашого коду є кількість “wtf за хвилину”.

Дуже часто компанії діють в останній момент, коли проблеми починають проявлятися. Як наслідок, на вирішення ситуації, яку можна було б з часом пом’якшити за допомогою регулярного обслуговування, потрібні роки. Наприклад, Австралійський банк Співдружності замінив свою основну банківську платформу у 2012 році та відійшов від COBOL. Їм знадобилося п’ять років і 1 мільярд доларів австралійських доларів, щоб завершити роботу (джерело). Такий перехід міг початися багато років тому (ми знаємо, що COBOL потрібно замінити з 90 -х років) і відбувся з часом.

Це стосується не тільки старих проектів. У день запуску healthcare.gov він мав час безперебійної роботи 43% (системи зазвичай працюють більше 99%). Швидко було створено оперативну групу для вдосконалення системи та доведення її до 95% часу безперебійної роботи, яка обслуговувала понад 50000 користувачів (джерело). Але таких проблем можна було уникнути на початку процесу розробки.

Основна проблема полягає в тому, що більшість часу програмне забезпечення розглядається як витрата, наприклад, лампочка, де програмне забезпечення набувається, а не активно обслуговується та замінюється, коли вважається «застарілим». Супровідники програмного забезпечення не вважаються важливими учасниками, хоча насправді вони повинні відігравати важливу роль у життєвому циклі продукту. Реальність така, що обслуговування програмного забезпечення становить до 90% загальної вартості життєвого циклу (джерело). Навіть якщо ваші витрати на технічне обслуговування нижчі за ці, вони становитимуть більше 50% (як повідомляють багато джерел – наприклад, цей чи цей) – і просто продемонструють, наскільки важливо інвестувати у обслуговування програмного забезпечення.

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

Ми всі бачили старі, не обслуговувані системи з проблемами. У 2020 році, під час кризи COVID-19, системи безробіття в Нью-Джерсі не змогли розглянути всі заяви про безробіття, оскільки система спиралася на програми, написані в COBOL. Губернатор закликав програмістів прийти і допомогти підтримувати систему (джерело).

Але навіть коли компанії намагаються активно підтримувати своє програмне забезпечення, на них все ще впливає поганий код, який уповільнює їх спритність та збільшує вартість обслуговування. Навіть технічні компанії, які мають армії розробників програмного забезпечення, не застраховані від цих проблем. У звіті Stripe за 2018 рік оцінюється, що поганий код та технічний борг втрачають більше 30% часу розробника програмного забезпечення (джерело). Інші дослідження повідомляють про подібні оцінки (див. Дослідження червоноперого або багатозначність). Коли середня зарплата інженера -програміста становить близько 107 000 доларів на рік, це означає, що компанії витрачають близько 34 000 доларів на одного інженера на рік для вирішення технічних боргів.

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

Ми можемо зупинити епідемію технічного боргу

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

Розробникам потрібно мати інструктора, який буде нагадувати їм про те, що являє собою чисту, здорову кодову базу. Інструмент, який нагадуватиме їм, що «ще одна копія/вставка для надання цієї нової функції не зашкодить якості кодової бази» – це просто еквівалент «ще одна скибочка торта не зашкодить моєму здоров’ю».

Розробникам необхідно дотримуватися простих правил, які гарантують хорошу якість коду, таких як:

уникнення запаху коду та неефективних шаблонів, які можуть бути вузькими місцями

не покладайтесь на будь -яку застарілу функцію чи бібліотеку, які можуть вплинути на безпеку програмного забезпечення або його ремонтопридатність (наприклад, використання strcpy () у C замість strncpy ())

уникайте копіювання/вставлення та дублювання коду, рефакторируйте дублікат коду у функцію, коли це доречно

писати короткі функції, які мають чіткий обсяг і легко зрозумілі

послідовно код документа

писати тести

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

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

Code Inspector також залишається в курсі передових практик і автоматично повідомляє вас, коли ваша база коду не відповідає належним практикам. Наприклад, якщо буде виявлено нову вразливість (наприклад, CVE або CWE), платформа сповістить вас і запропонує автоматичне виправлення. Якщо залежність застаріла і її потрібно замінити, вона запропонує її замінити і навіть змінити код за вас.

Важливо також періодично переглядати свій технічний стек кілька разів на рік і ініціювати потенційні міграції, якщо технологія застаріває. Якщо мова (наприклад, COBOL або Python 2), бібліотека (стара версія Ruby on Rails) або апаратна платформа (невлаштоване ядро Linux) припиняються, важливо бути ініціативним та планувати перехід на новішу технологію. Це дозволить уникнути дорогої міграції в майбутньому. Подібним чином, якщо служба стає занадто великою, може бути гарною ідеєю розділити її на кілька менших служб.

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

Про автора

Жульєн Деланж – засновник Code Inspector – платформи, яка автоматизує перевірку коду та допомагає розробникам скоротити технічні борги. Code Inspector доступний для хмарних платформ для розробки програмного забезпечення (GitHub, Gitlab та Bitbucket) та пропонує корпоративні програмні рішення, які допомагають розробникам програмного забезпечення створювати кращий код.

Слідкуйте за Жульєном або Code Inspector у Twitter.

Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/technical-debt-software-epidemic-julien-delange/.

Julien Delange люб’язно дозволив нам перекласти і опублікувати цю статтю.