Legacy-код

Меня зовут Данил Мухаметзянов, я работаю бэкенд-разработчиком в Badoo уже семь лет. За это время я успел создать и изменить большое количество кода. Настолько большое, что в один прекрасный день ко мне подошёл руководитель и сказал: Квота закончилась. Чтобы что-то добавить, нужно что-то удалить.

Ладно, это всего лишь шутка он такого не говорил. А жаль! В Badoo за всё время существования компании накопилось больше 5,5 млн строк логического бизнес-кода без учёта пустых строк и закрывающих скобок.

Само количество не так страшно: он лежит, есть не просит. Но два-три года назад я начал замечать, что всё чаще читаю и пытаюсь разобраться в коде, который на самом деле не работает в продакшен-окружении. То есть, по сути, мёртв.

Эту тенденцию заметил не только я. В Badoo поняли: наши высокооплачиваемые инженеры постоянно тратят время на мёртвый код.



С этим докладом я выступал на Badoo PHP Meetup #4

Откуда берётся мёртвый код

Мы начали искать причины проблем. Разделили их на две категории:

• процессные те, что возникают в результате разработки;
• исторические легаси-код.

В первую очередь решили разобрать процессные источники, чтобы предотвратить возникновение новых проблем.

A/B-тестирование

Активно использовать A/B-тестирование в Badoo начали четыре года назад. Сейчас у нас постоянно крутится около 200 тестов, и все продуктовые фичи обязательно проходят эту процедуру.

В результате за четыре года набралось около 2000 завершённых тестов, и эта цифра постоянно растёт. Она пугала нас тем, что каждый тест это кусок мёртвого кода, который уже не исполняется и вообще не нужен.

Решение проблемы пришло быстро: мы начали автоматически создавать тикет на выпиливание кода по завершении А/В-теста.


Пример тикета

Но периодически срабатывал человеческий фактор. Мы снова и снова находили код теста, который продолжал исполняться, но никто об этом не задумывался и не завершал тест.

Тогда появились жёсткие рамки: каждый тест должен иметь дату окончания. Если менеджер забывал ознакомиться с результатами теста, он автоматически останавливался и выключался. И, как я уже упомянул, автоматически создавался тикет на его выпиливание с сохранением исходного варианта логики работы фичи.

С помощью такого нехитрого механизма мы избавились от большого пласта работы.

Многообразие клиентов

В нашей компании поддерживаются несколько брендов, но сервер один. Каждый бренд представлен на трёх платформах: веб, iOS и Android. На iOS и Android у нас недельный цикл разработки: раз в неделю вместе с обновлением мы получаем новую версию приложения на каждой платформе.

Нетрудно догадаться, что при таком подходе через месяц у нас оказывается около десятка новых версий, которые необходимо поддерживать. Пользовательский трафик распределён между ними неравномерно: юзеры постепенно переходят с одной версии на другую. На некоторых старых версиях трафик есть, но он настолько мал, что поддерживать его тяжело. Тяжело и бесполезно.
Поэтому мы начали считать количество версий, которое хотим поддерживать. Для клиента появилось два лимита: софт-лимит и хард-лимит.

При достижении софт-лимита (когда вышло уже три-четыре новые версии, а приложение всё ещё не обновлено), пользователь видит скрин с предупреждением о том, что его версия устарела. При достижении хард-лимита (это порядка 10-20 пропущенных версий в зависимости от приложения и бренда) мы просто убираем возможность пропустить этот скрин. Он становится блокирующим: пользоваться приложением с ним нельзя.


Скрин для хард-лимита

В этом случае бесполезно продолжать процессить приходящие от клиента реквесты ничего, кроме скрина, он всё равно не увидит.

Но здесь, как и в случае с A/B-тестами, возник нюанс. Клиентские разработчики тоже люди. Они используют новые технологии, фишки операционных систем и через некоторое время версия приложения перестаёт поддерживаться на следующей версии операционной системы. Однако сервер продолжает страдать, потому что ему приходится продолжать обрабатывать данные запросы.

Отдельное решение мы придумали для случая, когда прекратилась поддержка Windows Phone. Мы подготовили скрин, который сообщал пользователю: Мы тебя очень любим! Ты очень классный! Но давай ты начнёшь пользоваться другой платформой? Тебе станут доступны новые крутые функции, а здесь мы уже ничего сделать не можем. Как правило, в качестве альтернативной платформы мы предлагаем веб-платформу, которая всегда доступна.

С помощью такого простого механизма мы ограничили количество версий клиентов, которое поддерживает сервер: приблизительно 100 разных версий от всех брендов, от всех платформ.

Фиче-флаги

Однако, отключив поддержку старых платформ, мы не до конца понимали, можно ли полностью выпиливать код, который они использовали. Или платформы, которые остались для старых версий ОС, продолжают пользоваться той же функциональностью?

Проблема в том, что наш API был построен не на версионированной части, а на использовании фиче-флагов. Как мы к этому пришли, вы можете узнать из этого доклада.

У нас было два типа фиче-флагов. Расскажу о них на примерах.

Минорные фичи

Клиент говорит серверу: Привет, это я. Я поддерживаю фотосообщения. Сервер смотрит на это и отвечает: Здорово, поддерживай! Теперь я об этом знаю и буду тебе отправлять фотосообщения. Ключевой особенностью здесь является то, что сервер никак не может влиять на клиент он просто принимает от него сообщения и вынужден его слушать.

Такие флаги мы назвали минорными фичами. На данный момент у нас их больше 600.
В чём неудобство использования этих флагов? Периодически встречается тяжёлая функциональность, которую нельзя покрыть только со стороны клиента, хочется контролировать её и со стороны сервера. Для этого мы ввели другие типы флагов.

Аппликейшен-фичи

Тот же клиент, тот же сервер. Клиент говорит: Сервер, я научился поддерживать видеостриминг. Включить его?. Сервер отвечает: Спасибо, я буду это иметь в виду. И добавляет: Отлично. Давай покажем нашему любимому пользователю эту функциональность, он будет рад. Или: Хорошо, но включать пока не будем.

Такие фичи мы назвали аппликейшен-фичами. Они более тяжёлые, поэтому их у нас меньше, но всё равно достаточно: больше 300.

Итак, пользователи переходят с одной версии клиента на другую. Какой-то флаг начинает поддерживаться всеми активными версиями приложениями. Или, наоборот, не поддерживаться. Не до конца понятно, как это контролировать: 100 версий клиентов, 900 флагов! Чтобы с этим разобраться, мы построили дашборд.

Красный квадрат на нём означает, что все версии данной платформы не поддерживают данную фичу; зелёный что все версии данной платформы поддерживают этот флаг. Если флаг может быть выключен и включён, он периодически моргает. Мы можем посмотреть, что в какой версии происходит.


Скрин дашборда

Прямо в этом интерфейсе мы начали создавать задачи на выпиливание функциональности. Стоит отметить, что необязательно все красные или зелёные ячейки в каждой строке должны быть заполнены. Бывают флаги, которые запущены только на одной платформе. Бывают флаги, которые заполнены только для одного бренда.

Автоматизировать процесс не так удобно, но, в принципе, и не нужно достаточно просто ставить задачу и периодически смотреть на дашборд. В первой же итерации нам удалось выпилить 200 с лишним флагов. Это почти четверть флагов, которые мы использовали!

На этом процессные источники закончились. Они появились в результате флоу нашей разработки, и работу с ними мы успешно встроили в этот процесс.

Что делать с легаси-кодом

Мы остановили возникновение новых проблем в процессных источниках. И перед нами встал сложный вопрос: что делать с легаси-кодом, накопленным за долгие годы? К решению мы подошли с инженерной точки зрения, то есть решили всё автоматизировать. Но было непонятно, как найти код, который не используется. Он спрятался в своём уютном мирке: никак не вызывается, о себе никак не даёт знать.

Пришлось зайти с другой стороны: взять весь код, который у нас был, собрать информацию о том, какие куски точно выполняются, а потом сделать инверсию.

Затем мы собрали это воедино и имплементировали на самом минимальном уровне на файлах. Так мы смогли легко получить список файлов из репозитория, выполнив соответствующую UNIX-команду.

Оставалось собрать список файлов, которые используются на продакшене. Это довольно просто: на каждый реквест на шатдауне вызвать соответствующую PHP-функцию. Единственная оптимизация, которую мы здесь сделали, начали запрашивать OPCache вместо запроса каждого реквеста. Иначе количество данных было бы очень большим.

В результате мы обнаружили много интересных артефактов. Но при более глубоком анализе поняли, что недосчитываемся неиспользуемых методов: разница в их количестве была в трисемь раз.

Выяснилось, что файл мог загружаться, исполняться, компилироваться ради только одной константы или пары методов. Всё остальное оставалось бесполезно лежать в этом бездонном море.

Собираем список методов

Впрочем, собрать полный список методов получилось достаточно быстро. Мы просто взяли парсер Никиты Попова, скормили ему наш репозиторий и получили всё, что имеем в коде.

Остался вопрос: как собрать то, что исполняется на продакшене? Нас интересует именно продакшен, потому что тесты могут покрывать и то, что нам совсем не нужно. Недолго думая, мы взяли XHProf. Он уже исполнялся на продакшене для части запросов, и потому у нас были семплы профилей, которые хранятся в базах данных. Было достаточно просто зайти в эти базы, спарсить сгенерированные снепшоты и получить список файлов.

Недостатки XHProf

Мы повторили этот процесс и на другом кластере, где XHProf не запускался, но был крайне необходим. Это кластер запуска фоновых скриптов и асинхронной обработки, который важен для highload в нём исполняется большое количество логики.

И тут мы убедились, что XHProf для нас неудобен.

• Он требует изменения PHP-кода. Нужно вставить код старта трейсинга, закончить трейсинг, получить собранные данные, записать их в файл. Всё-таки это профайлер, а у нас продакшен, то есть запросов много, нужно думать и о семплировании. В нашем случае это усугубилось большим количеством кластеров с разными entry points.
• Дублирование данных. У нас работала оптимизация для файлов. Вместо того чтобы получать список методов на каждый реквест, мы просто опрашивали OPCache. Реквестов много: если использовать XHProf, то нужно на каждый реквест записать некое количество данных и используемые методы. Но большая часть методов вызывается из раза в раз, потому что это core-методы или использование стандартного фреймворка.
• Человеческий фактор. У нас произошла одна интересная ситуация. Мы запустили XHProf на кластере обработки очередей. Запустили в облегчённом режиме (через опции XHProf): выключили сбор метрик потребления CPU, памяти, потому что они были бесполезны и только нагружали сервер. По сути, это был эксперимент, который мы не анонсировали до получения результатов. Но в какой-то момент мейнтейнер XHProf aggregator (наш внутренний компонент на базе XHProf с официальным названием Live Profiler, который мы выложили в open-source) это заметил, подумал, что это баг, и включил все обратно. Включил, проанализировал и сообщил: Ребята, кажется, у нас проблемы, потому что потребление CPU выросло на этом кластере, так как мы включили профилирование для большого числа запросов, о чём Live Profiler не знал. Мы, конечно, быстро заметили это и всё пофиксили.
• Сложность изменения XHProf. Данных собиралось много, поэтому нам хотелось автоматизировать их доставку и хранение. У нас уже был процесс доставки логов для ошибок и статистики. Мы решили использовать ту же самую схему вместо того, чтобы плодить новые. Но она требовала изменения формата данных: например, специфичной обработки переводов строк (стоит отметить, как правильно заметил youROCK, этого не требует lsd, но так было удобнее для поддержки единой обертки над ним). Патчить XHProf это не то, что нам хотелось делать, потому что это достаточно большой профайлер (вдруг что-нибудь сломаем ненароком?).

Была и ещё одна идея исключить определённые неймспейсы, например неймспейсы вендоров из композера, исполняющиеся на продакшене, потому что они бесполезны: мы не будем рефакторить вендорские пакеты и выпиливать из них лишний код.

Требования к решению

Мы ещё раз собрались и посмотрели, какие решения существуют. И сформулировали итоговый список требований.

Первое: минимальные накладные расходы. Для нас планкой был XHProf: не больше, чем требует он.

Второе: мы не хотели изменять PHP-код.

Третье: мы хотели, чтобы решение работало везде и в FPM, и в CLI.

Четвёртое: мы хотели обработать форки. Они активно используются в CLI, на облачных серверах. Делать специфическую логику для них внутри PHP не хотелось.

Пятое: семплирование из коробки. По факту это вытекает из требования не изменять PHP-код. Ниже я расскажу, почему нам было необходимо семплирование.

Шестое и последнее: возможность форсировать из кода. Мы любим, когда всё работает автоматически, но иногда удобнее вручную запустить, подебажить, посмотреть. Нам нужна была возможность включать и выключать все прямо из кода, а не по рандомному решению более общего механизма модуля PHP, задающего вероятность включения через настройки.

Принцип работы funcmap

В результате у нас родилось решение, которое мы назвали funcmap.

По сути funcmap это PHP extension. Если говорить в терминах PHP, то это PHP-модуль. Чтобы понять, как он работает, давайте посмотрим, как работает PHP-процесс и PHP-модуль.

Итак, у вас запускается некий процесс. PHP даёт возможность при построении модуля подписываться на хуки. Запускается процесс, запускается хук GINIT (Global Init), где вы можете инициализировать глобальные параметры. Потом инициализируется модуль. Там могут создаваться и выделяться в память константы, но только под конкретный модуль, а не под реквест, иначе вы выстрелите себе в ногу.

Затем приходит пользовательский реквест, вызывается хук RINIT (Request Init). При завершении реквеста происходит его шатдаун, и уже в самом конце шатдаун модуля: MSHUTDOWN и GSHUTDOWN. Всё логично.

Если мы говорим об FPM, то каждый пользовательский реквест приходит в уже существующий воркер. По сути, RINIT и RSHUTDOWN просто работают по кругу, пока FPM не решит, что воркер своё отжил, пора его пристрелить и создать новый. Если мы говорим о CLI, то это просто линейный процесс. Всё будет вызвано один раз.


Принцип работы funcmap

Из всего этого набора нас интересовали два хука. Первый RINIT. Мы стали выставлять флаг сбора данных: это некий рандом, который вызывался для семплирования данных. Если он срабатывал, значит, мы этот реквест обрабатывали: собирали для него статистику вызовов функций и методов. Если он не срабатывал, значит, реквест не обрабатывался.

Следующее создание хеш-таблицы, если её нет. Хеш-таблица предоставляется самим PHP изнутри. Здесь ничего изобретать не нужно просто бери и пользуйся.

Дальше мы инициализируем таймер. О нём я расскажу ниже, пока просто запомните, что он есть, важен и нужен.

Второй хук MSHUTDOWN. Хочу заметить, что именно MSHUTDOWN, а не RSHUTDOWN. Мы не хотели отрабатывать что-то на каждый реквест нас интересовал именно весь воркер. На MSHUTDOWN мы берём нашу хеш-таблицу, пробегаемся по ней и пишем файл (что может быть надёжнее, удобнее и универсальнее старого доброго файла?).

Заполняется хеш-таблица достаточно просто тем самым PHP-хуком zend_execute_ex, который вызывается при каждом вызове пользовательской функции. Запись содержит в себе дополнительные параметры, по которым можно понять, что это за функция, её имя и класс. Мы её принимаем, считываем имя, записываем в хеш-таблицу, а потом вызываем дефолтный хук.

Данный хук не записывает встроенные функции. Если вы хотите подменить встроенные функции, для этого есть отдельная функциональность, которая называется zend_execute_internal.

Конфигурация

Как это конфигурировать, не изменяя PHP-код? Настройки очень простые:

• enabled: включён он или нет.
• Файл, в который мы пишем. Здесь есть плейсхолдер pid для исключения race condition при одновременной записи в один файл разными PHP-процессами.
• Вероятностная основа: наш probability-флаг. Если вы выставляете 0, значит, никакой запрос записан не будет; если 100 значит, все запросы будут логироваться и попадать в статистику.
• flush_interval. Это периодичность, с которой мы сбрасываем все данные в файл. Мы хотим, чтобы сбор данных исполнялся в CLI, но там есть скрипты, которые могут выполняться достаточно долго, съедая память, если вы используете большое количество функционала.

К тому же если у нас есть кластер, который не так сильно нагружен, FPM понимает, что воркер готов обрабатывать ещё, и не убивает процесс он живёт и съедает какую-то часть памяти. Через определённый промежуток времени мы сбрасываем всё на диск, обнуляем хеш-таблицу и начинаем заполнять всё заново. Если в данный промежуток времени таймаут времени все же не достиг, то срабатывает хук MSHUTDOWN, где мы пишем всё окончательно.

И последнее, что мы хотели получить, возможность вызвать funcmap из PHP-кода. Соответствующее расширение даёт единственный метод, который позволяет включить или выключить сбор статистики независимо от того, как сработало probability.

Накладные расходы

Нам стало интересно, как всё это влияет на наши серверы. Мы построили график, который показывает количество реквестов, приходящих на реальную боевую машину одного из самых нагруженных PHP-кластеров.

Таких машин может быть много, поэтому на графике мы видим количество реквестов, а не CPU. Балансировщик понимает, что машина стала потреблять больше ресурсов, чем обычно, и старается выровнять запросы, чтобы машины были нагружены равномерно. Этого было достаточно для того, чтобы понять, насколько деградирует сервер.

Мы включили наше расширение последовательно на 25%, 50% и 100% и увидели вот такую картину:



Пунктир это количество реквестов, которое мы ожидаем. Основная линия количество реквестов, которое приходит. Мы увидели деградацию ориентировочно в 6%, 12% и 23%: данный сервер начал обрабатывать практически на четверть меньше приходящих реквестов.

Этот график в первую очередь доказывает, что нам важно семплирование: мы не можем тратить 20% ресурсов сервера на сбор статистики.

Ложный результат

Семплирование имеет побочный эффект: какие-то методы не попадают в статистику, но по факту используются. Мы пытались бороться с этим несколькими способами:

• Повышение вероятности. У нас был сервер с небольшим количеством запросов для бэк-офиса, то есть для обработки внутренних реквестов. Мы повысили вероятность сбора статистики, потому что деградация кластера нам не угрожала, и увидели, что количество реквестов, количество ложноположительных результатов уменьшилось.
• Обработка ошибок. Ошибки бывают редко, но они случаются: необходимо их обрабатывать и отдавать клиенту, иначе он не поймёт, что случилось.

Для обработки ошибок мы пробовали два решения. Первое включать сбор статистики принудительно начиная с того момента, когда ошибка была сформирована: собираем error-лог и анализируем. Но здесь есть подводный камень: при падении какого-либо ресурса количество ошибок моментально растёт. Вы начинаете их обрабатывать, воркеров становится гораздо больше и кластер начинает медленно умирать. Поэтому делать так не совсем правильно.

Как сделать по-другому? Мы вычитали, и, используя парсер Никиты Попова, прошлись по стейктейсам, записав, какие методы там вызываются. Таким образом мы исключили нагрузку на сервер и уменьшили количество ложноположительных результатов.

Но всё равно оставались методы, которые вызываются редко и про которые было неясно, нужны они или не нужны. Мы добавили хелпер, который помогает определить факт использования таких методов: если семплирование уже показало, что метод вызывается редко, то можно включить обработку на 100% и не думать о том, что происходит. Любое исполнение этого метода будет залогировано. Вы будете об этом знать.

Если вы точно знаете, что метод используется, это может быть избыточно. Возможно, это нужная, но редкая функциональность. Представьте, что у вас есть опция Пожаловаться, которая используется редко, но она важна выпилить её вы не можете. Для таких случаев мы научились маркировать подобные методы вручную.

Мы создали интерфейс, в котором видно, какие методы используются (они на белом фоне), а какие потенциально не используются (они на красном фоне). Здесь можно и промаркировать нужные методы.

Скрин интерфейса

Интерфейс это здорово, но давайте вернёмся к началу, а именно к тому, какую проблему мы решали. Она заключалась в том, что наши инженеры читают мёртвый код. Читают его где? В IDE. Представляете, каково это заставить фаната своего дела уйти из IDE-мира в какой-то веб-интерфейс и что-то там делать! Мы решили, что надо пойти навстречу коллегам.

Мы сделали плагин для PhpStorm, который загружает всю базу неиспользуемых методов и отображает, используется данный метод или нет. Более того, в интерфейсе можно пометить метод как используемый. Это всё отправится на сервер и станет доступно остальным контрибьюторам кодовой базы.

На этом завершилась основная часть нашей работы с легаси. Мы стали быстрее замечать, что у нас не исполняется, быстрее на это реагировать и не тратить время на поиски неиспользуемого кода вручную.

Расширение funcmap выложено на GitHub. Будем рады, если оно кому-то пригодится.

Альтернативы

Со стороны может показаться, что мы в Badoo не знаем, чем себя занять. Почему бы не посмотреть, что есть на рынке?

Это справедливый вопрос. Мы смотрели и на рынке в тот момент ничего не было. Только когда мы начали активно внедрять своё решение, мы обнаружили, что в то же самое время человек по имени Joe Watkins, живущий в туманной Великобритании, реализовал аналогичную идею и создал расширение Tombs.

Мы не очень внимательно его изучили, потому что у нас уже было своё решение, но тем не менее обнаружили несколько проблем:

• Отсутствие семплирования. Выше я объяснял, почему оно нам необходимо.
• Использование разделяемой памяти. В своё время мы столкнулись с тем, что воркеры начинали упираться в запись конкретного ключа при использовании APCu (модуль кеширования), поэтому в своём решении мы не используем разделяемую память.
• Проблемная работа в CLI. Всё работает, но, если вы одновременно запустите два CLI-процесса, они начнут конфликтовать и публиковать ненужные ворнинги.
• Сложность постобработки. Расширение Tombs, в отличие от нашего, само понимает, что было загружено, что было исполнено, и в конце концов выдаёт то, что инвертировано. Мы же в funcmap делаем инверсию уже после (вычитаем из всего кода тот, который использовался): у нас тысячи серверов, и эти множества нужно правильно пересечь. Tombs отлично сработает, если у вас небольшое количество серверов, вы используете FPM и не используете CLI. Но если вы используете что-то сложнее, попробуйте оба решения и выберите более подходящее.

Выводы

Первое: заранее думайте о том, как вы будете удалять функциональность, которая имплементируется на короткий промежуток времени, особенно если разработка идёт очень активно. В нашем случае это были A/B-тесты. Если вы не подумаете об этом заранее, то потом придётся разгребать завалы.

Второе: знайте своих клиентов в лицо. Неважно, внутренние они или внешние вы должны их знать. В какой-то момент надо сказать им: Родной, стоп! Нет.

Третье: чистите свой API. Это ведёт к упрощению всей системы.

И четвёртое: автоматизировать можно всё, даже поиск мёртвого кода. Что мы и сделали.

Руководство не даёт мне заняться рефакторингом legacy-кода! Знакомая ситуация? Раздражает жутко. Большинство разработчиков рано или поздно сталкивается лбами с менеджером, который совершенно не заинтересован в том, чтобы совершенствовать уже готовое. То нужно реализовать что-то новое, то срочно потушить пожар, то исправить какой-то баг В общем, причина отложить рефакторинг запущенной кодовой базы у них всегда найдётся.

И даже когда пытаешься им объяснять, какие преимущества даёт опрятный код, они то ли не понимают, то ли не хотят понимать. У них только затраты и сроки на уме, а до качества никому нет дела. И получается, что вы абсолютно бессильны что-то сделать с техническим долгом, который всё копится и копится. Программисты работают на прод, а прод на запросы нетерпеливых пользователей. За рефакторинг никто платить не будет. Положение выглядит безнадёжным.

Попадая в такую ситуацию, многие толковые разработчики просто пакуют вещи и уходят из компании. И очень скоро из-за текучки в отделе уже двери не закрываются: одни уходят, другие приходят

Менеджеры не программисты

Решение проблемы состоит в том, чтобы донести до менеджеров, какое влияние низкое качество кода оказывает на бизнес. В конечном счёте, деятельность компании нацелена на получение денег. Прибыли. Соответственно, руководство ищет оптимальные пути урезать расходы и привлечь доходы. А значит, чтобы реабилитировать в их глазах рефакторинг, придётся говорить на их языке.

Мне довелось поработать и техлидом, и консультантом, так что опыт в этом деле у меня большой. Давайте поделюсь с вами некоторыми заготовками.

Пять аргументов, которые вы можете привести

1) Рефакторинг поможет снизить волатильность предельных издержек на единицу функциональности ПО

Это точная цитата из замечательного выступления Дж. Б. Рейнсберга на конференции на тему Экономика в разработке ПО. Стойте, не уходите! Всё, что здесь сказано, вам прекрасно известно, просто оно сформулировано в абстрактно-заумном духе.

Пойдём по порядку:

• Рефакторинг поможет снизить пока что всё нормально
• волатильность иными словами, непредсказуемость
• предельных издержек то есть сколько ресурса потребует производство ещё одной дополнительной единицы
• на единицу функциональности ПО она же фича, имеющая ценность для бизнеса. Ура! Ценность для бизнеса это как раз то, что нам нужно.

В основе всех пяти аргументов лежит всё та же общая идея о переводе с одного языка на другой, которой мы часто пренебрегаем в общении с людьми, далёкими от сферы IT. Не используйте сленг, напирайте на понятия из экономики и бизнеса вот и весь секретный ингредиент. Так между вами и руководством быстрее установится связь.

2) За последние месяц 63% ресурса разработки ушло на исправление проблем с качеством продукта

Ну, цифры здесь подставите свои. Смысл в том, чтобы подкрепить посыл количественными данными. Технический долг не может не влиять на ваши повседневные рабочие процессы. Можно ли это доказать? Разумеется!

Вот несколько метрик, на которые вы можете обратить внимание:

• Изменение темпов работы со временем. Сколько пунктов из списка вы успеваете обработать за спринт? Не стало ли это число снижаться в последнее время?
• Количество баг-репортов, которые поступают команде за неделю, а также количество исправленных багов за тот же срок. Не выходит ли так, что баги накапливаются? Не слишком ли много времени вы на них тратите?
• Количество аварийных ситуаций, с которыми вы сталкиваетесь за неделю. Сможет ли команда справляться с таким числом на постоянной основе? Не учащаются ли случаи их возникновения?

Покажите руководству, во что именно выливается для них плохое качество кода. А ещё лучше найдите способ перевести эти цифры в денежный эквивалент.

Как-то я присутствовал на post-mortem бага, которого можно было бы избежать, если бы была проведена проверка типов данных. Код писался на JavaScript. Как раз в то время в компании велись споры о том, стоит ли переходить на TypeScript.

Разработчики, которые разбирались в случившемся, не поленились поднять данные и сумели оценить урон, который баг нанёс бизнесу. Оказалось, что за несколько месяцев своего существования баг высосал из компании миллион канадских долларов. Миллион! Одного этого с головой бы хватило, чтобы окупить стоимость перехода на TypeScript.

Исходя из этого, было принято решение, что новые сервисы будут реализовываться на TypeScript, а для самых ключевых нужно задним числом провести проверку типов данных.

3) С технической точки зрения, чтобы быстрее выпустить продукт, мы работали в кредит. Теперь нужно выплатить часть долга, чтобы время выхода на рынок не возросло

Опять же: говорим на языке собеседника. Метафоры бывают очень эффективны, когда нужно донести мысль: они связывают для слушателя незнакомые концепты со знакомыми и тем самым помогают их понять. Понятие кредит хорошо знакомо любому менеджеру. Да и сам технический долг тоже метафора, получившая широкое хождение.

Или можно, допустим, представить компанию как ресторан, а кодовую базу как его кухонную зону. По мере накопления грязной посуды обслуживать возрастающее число посетителей становится всё сложнее и сложнее. Сотрудникам нужно успевать перемыть посуду в перерывах между приготовлением пищи.

4) Если инвестировать 10% рабочего времени в качество кода, текучесть кадров существенно снизится.

До сих пор мы говорили об очевидных последствиях низкого качества кода. Но есть одна коварная вещь, которую легко упустить из вида: текучка.

В наши дни компании с трудом удерживают при себе разработчиков, особенно талантливых. Если такой перестанет получать удовольствие от работы, для него не составит труда получить другое предложение и просто уйти куда глаза глядят, подальше от вечного хаоса. Да что там, возможно, вы и сами уже поглядываете по сторонам в поисках чего получше

А теперь давайте зададимся вопросом: во что компании обходится замена уволившегося разработчика? Нового специалиста нужно найти, провести через процесс найма, ввести в курс дела. Это требует вложений, занимает время и затормаживает всю команду. Руководство однозначно предпочло бы не заниматься подобными перестановками каждый год. Поэтому снижение текучести может стать серьёзным аргументом. А сам факт наличия плана по устранению технического долга сразу даст всей команде +100 к мотивации.

5) Если вложить 20% ресурса в рефакторинг, FRT сократится вдвое и для производительности разработчиков ROI будет положительным

FRT это время отклика, важная метрика для пользовательской поддержки. Бизнес стремится к тому, чтобы клиенты были всем довольны.

Здесь мы проделываем следующее:

• Выбираем метрики, которые имеют большой вес в техподдержке;
• Находим пару проблем, которые возникают регулярно и требуют вмешательства разработчиков;
• Предлагаем план по сокращению числа обращений в техподдержку за счёт устранения исходной причины.
• Если проблемы такого рода разрешатся, разработчиков реже будут привлекать к задачам, связанным с поддержкой пользователей. То есть у них освободится больше времени, чем было затрачено на рефакторинг, а значит, вложение окупится тот самый положительный ROI.

В конечном счёте, решать им

С этим никто не поспорит. Я предложил пять аргументов, которыми можно убедить людей в важности устранения технического долга, но теперь, думаю, следует дать ещё один дополнительный совет, прежде чем вы пойдёте обрабатывать какого-нибудь менеджера.

Проводите рефакторинг по ходу дела

Рефакторинг не должен рассматриваться как отдельный этап работы над функциональностью. Ведь вы всё равно не можете заранее предсказать, какие возможности будут внедряться в будущем. Значит, нужно подгонять кодовую базу под новые реалии по мере их поступления. Это тоже часть работы, необходимая для создания той самой материальной ценности любой разработчик-профессионал это подтвердит.

Правило работает даже для баз с legacy-кодом. Ну ладно, в божеский вид вы её к завтрашнему дню точно не приведете. И пытаться проводить крупномасштабный рефакторинг между делом тоже дохлый номер. Но с таким подходом положение, по крайней мере, не будет ухудшаться. А в работе с lrgacy-кодом приходится ориентироваться не на хорошо, а на лучше.

Исправляете баг? Потратьте лишний час на написание автоматического теста. Готовитесь выкатывать новую фичу? Потратьте лишний день, чтобы подчистить код. День изо дня старайтесь, чтобы изменения происходили безболезненно. Через несколько месяцев вы заметите, что эта привычка оказала огромное влияние на вашу производительность. А знаете почему? Потому что рефакторинг помогает снизить волатильность предельных издержек на единицу функциональности ПО.

Язык программирования COBOL старше Игоря Николаева. Люди, умеющие им пользоваться, часто того же возраста. Он лежит в основе целой финансовой системы и его нельзя оттуда убрать. Мы расскажем о том, как компьютерный язык управляет финансовой жизнью мира.

Когда Томас начинал программировать, на двое стоял 1969 год. Он был обычным парнем, только что выпустившимся из старшей школы в Торонто, не имея особых целей в жизни. Его отец был плотником, но в двери его семьи постучалась удача: оказалось, что руки у Томаса растут не из того места. Мой отец знал, что я даже не смогу приколотить одну доску к другой, смеётся он.

Поэтому его мать предложила нечто странное и новомодное: как насчёт программирования компьютеров?

В 1969 году компьютеры всё ещё были странными новыми диковинками размером с большой шкаф. Но по всему миру компании начали понимать, что эти устройства бесценны для всех задач, требующих мгновенных бухгалтерских расчётов, например, подсчёта зарплат. Вакансии предлагались любому, кто хотя бы немного умел кодить. Поэтому Томас нашёл небольшую школу-однодневку в деловом центре Торонто и за следующие два месяца изучил самый популярный на то время компьютерный язык: COBOL (Common Business-Oriented Language).

После выпуска его приняли на работу в отдел сортировки чеков крупного канадского банка. (Он не захотел говорить его названия, банки скрытны; кстати, если вы еще не догадались, Томас это псевдоним.) Тогда Томас ещё не был программистом банка, но за следующие несколько лет он чётко дал понять, что хочет им стать. Его работодатель оплатил несколько качественных курсов колледжа по кодингу и в 1978 году он начал долгую карьеру в качестве банковского программиста.

Томас полюбил работу. Она была похожа на постоянное решение головоломок, на игру в шахматы вслепую. Он садился за свой стол, писал от руки код, затем отдавал ему оператору перфокарт, проделывавшему отверстия в картах, обозначающие программные инструкции. Дважды в день они вводили эти перфокарты в огромные мейнфреймы банка. Томасу требовалось несколько часов, чтобы убедиться в правильности работы кода или в том, что он совершил оплошность, из-за которой вся работа встала. Если случалось так, то он просматривал сообщения об ошибках, переписывал код на COBOL и пробовал снова.

За следующие несколько лет Томас хорошо освоил COBOL и написал тысячи бесценных строк кода. Когда банк производил платежи, именно код Томаса ежедневно помогал ему всё правильно подсчитать. Шли 70-е, 80-е и 90-е, Томас с коллегами-кодерами написали десятки миллионов строк на COBOL. Есть одна система, которой он особо гордится, это мгновенно работающая программа, способная обработать от трёх до пяти миллионов транзакций в день. Это моё дитя! Первые куски этой программы он написал в 1988 году.

И дело в том, что его код по-прежнему работает даже сегодня.

Томас уволился из банка в 2007 году в возрасте примерно 60 лет, и когда он ушёл, банк всё ещё использовал его систему, которой к тому времени исполнилось 20 лет. Она написана ещё тогда, когда на голове у Томаса было намного больше волос, а хитом чартов была Groovy Kind of Love Фила Коллинза. Сегодня этому коду уже больше трёх десятков лет. И он по-прежнему обрабатывает миллионы записей в день. Томас считает, что бОльшая часть кода, который он и его коллеги написали в своё время, всё ещё работает, потому что банк не сможет без него функционировать.

Когда в доме в небольшом городке рядом с Торонто, куда перебрался на покой Томас, сегодня звонит телефон, это иногда бывает кто-нибудь из банка.

Здравствуйте, говорят ему. Эээ можете нам помочь обновить ваш код? Возможно, добавить в него новые функции? Потому что, как оказалось, банк больше не нанимает никого, кто понимает COBOL так же хорошо, как Томас, того, кто может погрузиться в код и изменить его так, чтобы он выполнял новую задачу. Почти все ветераны COBOL, жокеи перфокарт, создававшие критически важные банковские системы в прошлом, знающие COBOL вдоль и поперёк все они уволились. Они покинули здание, как и Томас. И немногих молодых кодеров интересует изучение пыльного пятидесятилетнего компьютерного языка. Их гораздо больше вдохновляют волнующие новые области, например, развивающееся сообщество разработчиков искусственного интеллекта в Торонто. Они изучают свежие и новые языки программирования.

Поэтому этот крупный банк по-прежнему зависит от людей вроде 73-летнего Томаса, который не только обеспечивает работу кода, но и может добавлять новые возможности и улучшения.

Переживёт ли Томаса его код на COBOL?

Вероятно.

Этот банк не одинок. Программы на COBOL, некоторые из которых были написаны ещё до появления цветных телевизоров, используются в нашей повседневной жизни повсюду.

Представьте: в более чем 80% личных транзакций финансовых организаций США используется COBOL. Когда вы проводите своей пластиковой картой, то в 95% случаев обработку выполняет COBOL. Bank of New York Mellon выяснил в 2012, что у него есть примерно 112 500 отдельных программ на COBOL, состоящих почти из 350 миллионов строк; вероятно, это типично для большинства крупных финансовых организаций. Когда ваш босс вручает вам зарплатный чек, есть вероятность, что он подсчитан при помощи COBOL. Если вы занимаетесь инвестициями, то ваша торговля акциями тоже выполняется на нём. То же самое происходит и в здравоохранении: страховые компании США используют adjudication engines программное обеспечение, определяющее, сколько заплатят врачу или фармацевтической компании; они так же написаны на COBOL. Задумывались, почему при совершении покупок в розничном магазине продавец вводит данные в старомодный терминал с зелёным текстом на чёрном фоне? Потому что в системе инвентаризации используется COBOL. Или почему специалисты по бронированию авиабилетов пользуются тем же чёрным экраном с зелёными буквами, чтобы изменить данные рейса? О, это COBOL, это совершенно точно COBOL, смеётся ведущий инженер Faircom Крейг Бейли. Его фирма создаёт ПО, помогающее компаниям управлять этими старыми системами.

Никто точно не знает, сколько существует кода на COBOL, но, по оценкам, наиболее важные аспекты нашей повседневной жизни втихомолку обслуживает примерно 240 миллиардов строк кода. Вторым по ценности ресурсом в США после нефти являются 240 миллиардов строк COBOL, говорит Филип Теплицки, десятки лет писавший на COBOL для банков по всем США.

Нам часто говорят, что технологии процветают благодаря новым, передовым инновациям, желанию рисковать и создавать с помощью кода нечто новое, двигаться быстро и сокрушать препятствия, как написал молодой Марк Цукерберг на своей стене в Facebook. И каждый день мы действительно видим, как появляется безумный новый код, написанный на модных и новых языках. Возможно, вы видели новый ИИ, способный писать предложения как человек он создан благодаря Python, хорошо известному новому компьютерному языку. Когда Facebook добавляет новые функции в своё браузерное приложение, то кодеры часто используют JavaScript ещё один популярный язык.

Но как насчёт более старых и массивных отраслей, являющихся центральными для экономики? В них по-прежнему вездесущ COBOL. Из-за этого инновации усложняются. Как создавать и прикручивать новые возможности с помощью древнего языка, который неинтересен энергичным молодым кодерам? Если крупные старые банки это не компании, двигающие прогресс вперёд с помощью сервисов наподобие Venmo или Square, или других громких финтех-продуктов, то из этого следует, что COBOL является частью проблемы. Но если это так, то почему же Томаса по-прежнему тревожат на его заслуженной пенсии, чтобы он поддерживал жизнь в этих системах? Почему нельзя обойтись без них?


Частично это вызвано тем, что COBOL был первым, и он оказался инструментом, идеально подходящим для своей задачи. Во многих смыслах COBOL был той искрой, из которой возгорелась вся наша современная компьютерная эпоха.

Программисты начали разработку COBOL в 1959 году. Когда его наконец выпустили десять лет спустя, в 1969 году, он стал первым компьютерным языком, благодаря которому компьютеры можно стало активно использовать в повседневной жизни. В конце 50-х у компьютеров только завершилась экспериментальная стадия. Обычные компании начали взвешивать возможную ценность приобретения собственного компьютера для перемалывания чисел. Однако проблема заключалась в том, что до появления COBOL кодинг был непонятным и сложным в изучении. Программисты часто писали ПО на какой-нибудь разновидности ассемблерных языков, команды которых были ужасно мудрёными. (Например, команда LXA A,K означает взять число, загруженное в ячейку A компьютерной памяти и загрузить его в индексный регистр K.) Усугубляло ситуацию то, что производители компьютеров часто создавали для своих машин собственные уникальные языки. Если написать отличный код для машины, то он не сможет работать на компьютере, изготовленном другой компанией.

Новое поколение амбициозных программистов считало это безумием. Одним из них была контр-адмирал ВМФ США Грейс Хоппер, обладавшая яркой индивидуальностью. (Именно она популяризировала выражение проще попросить прощения, чем получать разрешение.) Хоппер считала, что языки программирования должны сильнее походить на английский, чтобы их было проще учить и читать. В 1955 году она разработала язык FLOW-MATIC, предназначенный именно для этой задачи; например, для перемещения числа из ячейки A в ячейку D на нём нужно было просто написать TRANSFER A TO D.

В 1959 году программистка Мэри Хоуэс решила, что её отрасли нужен язык, на котором писать будет так же просто, как на FLOW-MATIC, способный при этом работать на любой машине. Она собрала комитет специалистов, в том числе из только зарождающейся отрасли бизнес-компьютеров, чтобы приступить к созданию языка под руководством министерства обороны. Задача заключалась в написании языка, который бы мог читать и понимать обычный менеджер компании, даже если он не учился на программиста.

Спустя десятилетие работы, активно продвигаемой множеством женщин-суперзвёзд этой отрасли, например, пионеркой компьютерных наук Джин Саммет, был создан язык, во многом напоминавший FLOW-MATIC и простой в понимании. Например, для сложения двух чисел можно было написать ADD Num1, Num2 GIVING Result. Чтобы выполнить вычисление три раза, нужно было написать PERFORM 3 TIMES.

Сложно переоценить важность COBOL, говорит адъюнкт-профессор истории Мар Хикс из Иллинойсского технологического института и автор книги Programmed Inequality. Он совершил в компьютерных вычислениях совершенно необходимый шаг. Язык заполнил ту нишу, которая оставалась пустой на протяжении первых лет компьютеров. И он изменил образ мышления, необходимый для написания программ.

Изменил он и круг тех, кто мог на нём писать. COBOL демократизировал кодинг; теперь компании могли нанимать обычных людей и обучать их, за несколько месяцев превращая в полезных программистов на COBOL, а через пару лет в специалистов. Это было критически важно, учитывая, что компаниям отчаянно требовалось больше гребцов, чтобы писать ПО.

Можно было брать людей с улицы, рассказывает британский кодер Джон Пайк, изучавший COBOL в 1960-х. И, по сути, учить их, как писать программы.

Ещё один плюс COBOL заключался в его скорости. Он проектировался специально для очень быстрого выполнения огромного количества транзакций. Если вы работаете в розничной сети, то каждый вечер вам надо подсчитывать продажи и пересчитывать остатки. А у вас на это не так много времени может быть, пара часов вечером, после завершения рабочего дня, пока ваш компьютерный персонал работает допоздна.

С банками та же ситуация: в течение рабочего дня они суматошно принимают транзакции, запросы на вывод и поступление денег клиентов на их счета. По вечерам у них есть несколько часов на подсчёт баланса всей этой бухгалтерии. Возможно, вы задавались когда-нибудь вопросом, почему клиринг размещённого вами чека занимает какое-то время. Частично это вызвано тем, что обоим банкам нужно провести все эти огромные вычислительные задачи на COBOL после ухода дневного персонала. В Citibank код Теплицки выполнялся в огромном центре из 248 компьютеров-мейнфреймов.

У тебя есть временной промежуток в шесть-восемь часов, чтобы проделать кучу работы провести все транзакции в определённом порядке, рассказывает он мне. Для выполнения миллиарда транзакций за шестичасовое окно требуется мощнейшее оборудование.

COBOL был оптимизирован для выполнения именно этой задачи: обработки целого множества транзакций. Компьютерные языки часто имеют определённую когнитивную или творческую специализацию; каждый из них создавался под конкретный тип задач. Python превосходно работает с data science и искусственным интеллектом; Fortran был создан для преобразования математических формул в код; JavaScript создавался, чтобы программисты могли делать веб-сайты интерактивными.

А что же COBOL? Он подстраивался под работу на этих мейнфреймах, которые сами проектировались специально для перемалывания миллиардов транзакций, мгновенного считывания и записи потоков данных. Он походит на высокооктановое топливо, изобретённое специально для спортивных автомобилей. На протяжении лет компиляторы COBOL программы, превращавшие напоминающий английский язык синтаксис компьютерного кода в единицы и нули, которые может выполнять чип компьютера всё больше совершенствовались, поэтому скомпилированный код COBOL стал чрезвычайно быстрым. То есть причина того, что COBOL находится в основе столь многих критически важных систем, заключается ещё и в том, что он на самом деле достаточно хорош в выполнении своей работы.

У разработчиков было пятьдесят лет, чтобы сделать всё правильно, замечает Билл Хиншоу, управляющий агентством COBOL Cowboys, предоставляющим услуги программистов на COBOL.

Как ни странно, сам возраст систем COBOL идёт ему на пользу. Поскольку его экосистема стара, её тщательно избавляли от ошибок и багов. Когда программа пишется впервые, она неизбежно имеет проблемы. Иногда это опечатка или команда не на своём месте; в другом случае пользователь делает нечто неожиданное для программиста, из-за чего всё разваливается. Когда появляется новое приложение, в нём много багов и оно подвержено вылетам: его создатели отправили его в мир со всеми этими несовершенствами. На обнаружение всех проблем уходят дни, недели или годы.

Кодеры и пользователи программ COBOL, которые управляют миром, имели десятки лет на выявление и устранение проблем.

Адриана Стерн (на этот раз это не псевдоним!), ещё одна программистка, с которой я общался, работала на крупные канадские банки. Её карьера началась в 80-х, когда из систем всё ещё устраняли различные странные баги. Однажды она выяснила, что один банковский терминал в Квебеке передаёт в систему буквы со знаками ударения, чего не предусмотрел программист системы.

Поэтому когда система пыталась интерпретировать их, она зависала, рассказывает Адриана. В другой раз постоянно вылетала ещё одна программа на COBOL. В конечном итоге Стерн разобралась: причина заключалась в имени нового клиента, содержащем одну кавычку, которую программа интерпретировала как инструкцию конец массива данных, что приводило к остановке выполнения кода.

Стерн работала на банки тридцать лет, и по её оценкам, 85% работы заключалось не в создании новых функций для банка, а в обслуживании. Её труд напоминал работу цифрового сантехника, устраняющего протечки и постепенно повышающего стабильность выполнения программ.

Это была сложная работа, мы как будто поджигали свечу с обоих концов, рассказывает она мне.

Именно поэтому такие системы COBOL настолько надёжны сегодня. Их отлаживали больше, чем практически любой другой код на планете. Громкое новое приложение наподобие TikTok может появиться и получить огромную популярность даже с кучей багов. Если количество лайков под твоим последним постом считается немного неправильно, то это не вызывает особых проблем. А если вдруг крупная розничная сеть ошибётся в инвертаризации или банк внезапно не сможет отправить деньги? Это вызовет масштабный финансовый хаос.

Весь ВВП мира находится в движении по банковской сети, говорит Теплицки. Банк ежедневно дважды оборачивает свои активы. А для клирингового банка, допустим, в Нью-Йорке, это число может быть ещё больше То есть в движении по сети находятся огромные суммы денег, и их обслуживают крупные бэкенд-системы. Они не имеют права на сбой! Если они обрушатся, произойдёт катастрофа мирового масштаба. Мирового масштаба.

COBOL не просто быстр; он, как сказал мне Томас, стабилен, стабилен, стабилен. Один из разработанных им процессов получает каждый месяц файл с примерно 2,4 миллионов государственных пенсий и переводит соответствующие суммы на банковские счета людей. Мы подтверждаем и проверяем их за 11 минут. За двадцать лет процесс ни разу не дал сбой.

Эта идея о том, что старый код может быть не только хорошим, но в критических аспектах и превосходить новый, противоречит мифологемам Кремниевой долины. Финансируемые венчурным капиталом стартапы зачастую расхваливают блестящие новые технологии. Основатели обычно не хвастаются всем, насколько стара их кодовая база. Всё наоборот: они хвалятся, насколько прогрессивен их код, написанный благодаря ночному труду сонных двадцатиоднолетних гениев. Но почти любой программист скажет вам, что чем недавней написано ПО, тем больше вероятность, что оно представляет собой сборище багов.

Хороший пример этого можно наблюдать во время пандемии. В первые дни Covid-19 бизнесы массово закрывались. Уволенные сотрудники рванулись онлайн, чтобы подать заявление на получение пособий по безработице, и веб-сайты многих правительств штатов не выдержали нагрузки. Губернатор Нью-Джерси сообщил прессе, что их системы COBOL отчаянно нуждаются в помощи, чтобы справиться с новыми потребностями. У нас в буквальном смысле есть системы, которым от сорока и более лет, заявил он.

Но технологи, работавшие за кулисами над устранением неполадок, знали, проблема заключалась не в перемалывающем числа COBOL. Эти старые системы работали хорошо. Нет, всегда ломались более новые элементы программы, управлявшие самим веб-сайтом.

С ума сходило веб-приложение между мейнфреймом и внешним миром. Именно оно падало, рассказывает программистка и писательница Марианна Беллотти, годами работавшая с государственными системами и следившая за этой системой Нью-Джерси. Но, по словам историка Хикса, властям было слишком неудобно признать ой, да, это сломались наши веб-системы.

Беллотти наблюдала подобные явления и в других государственных органах, например в Налоговом управлении США (IRS). Однажды её вызвали для помощи с неработающим веб-приложением IRS. После расследования выяснилось, что проблема и в самом деле была в новых программах, в куске плохо написанного кода на Java. Мейнфрейм с запущенным COBOL, напротив, гнал вперёд подобно Ferrari.

Мейнфреймы отвечали всего за несколько миллисекунд, говорит она.


Однако стабильность и старость кода способны создать парадокс проклятие успеха. Поскольку код хорошо работает без проверок, люди со временем будут от него уходить. Они перестают смотреть на него, перестают его изучать. И это означает, что они перестают понимать, как же именно он работает.

Они определённо знают, что он работает. Ведь он функционирует каждый день, за мгновение обрабатывая миллионы транзакций! Но никто точно не знает, как и почему. COBOL превратился в непостижимую загадку, в демона, покорно исполняющего свои задачи, но таким способом, который никто не понимает полностью.

Это может стать серьёзной проблемой, когда спустя долгие годы вам нужно будет изменить что-то или добавить новую функцию.

Дейв Гуарино стал непосредственным свидетелем этого. Он разработчик ПО, много лет проработавший в Code For America некоммерческой организации, позволяющей талантливым кодерам помогать правительствам с обновлением их древних служб. Несколько лет назад он помогал писать новое веб-приложение, чтобы калифорнийцы могли более удобно подавать заявления на продуктовые талоны. Веб-приложение находилось поверх более старых систем Калифорнии; пользователи должны были взаимодействовать с приложением, которое передавало бы их запросы коду на мейнфреймах штата Калифорния, написанному десятки лет назад.

И вот здесь возникла проблема. Команда Дейва хотела реализовать способ бронирования времени для встречи получателей продуктовых талонов с чиновником. В старых системах Калифорнии уже был раздел, способный получать подобный запрос. Но в поле Когда вам удобно прийти на встречу? старая система позволяла ввести только 40 символов и запрещала использование тире, поэтому нельзя было использовать сокращения, например, пн-ср, чтобы сообщить, что пользователь свободен с понедельника по среду.

Ну и мучение, подумал Гуарино. Он встретился с человеком, управлявшим этой старой системой ПО. К сожалению, да, таковы реальные ограничения, ответил ему человек. И это была проблема COBOL, он был написан несколько десятков лет назад. Что же мы можем сделать? Можно сделать поле побольше, или ещё что-нибудь?, спросил Гуарино. И он сразу же такой нет, здесь ничего не поделаешь! К этому коду на COBOL никто и никогда не собирался прикасаться. У штата даже не было столько денег, чтобы оплатить время, необходимое для изучения этой кодовой базы.

Кроме того, их, скорее всего, пугало то, что если они попытаются изменить что-то критически важное, то сломают код. И это ещё один парадокс успеха COBOL. Из-за его скорости и стабильности правительства и банки за годы и десятилетия привыкли полагаться на эти старые системы. Поэтому даже если вы захотите их изменить, пробовать будет слишком опасно. В том банке, где работала Стерн, можно было поседеть от стресса работы с действительно древним, критически важным кодом.

Исправление ошибок было связано с высоким уровнем риска, потому что можно было поломать что-то уже работающее, рассказывает она мне. Поэтому чаще всего вместо обширного переписывания старого кода они просто добавляли небольшие новые кусочки кода, патча системы по краям. Разработчики всё время добавляли небольшие фрагменты, и со временем система начала походить на маленького Франкенштейна, смеётся Адриана. Что, разумеется, только делало систему потенциально более непознаваемой и запутанной для будущих поколений.

Однако чрезвычайно редко так случалось, некоторые проектировочные решения, принятые десятки лет назад, оказывались ужасными, и банкам с компаниями приходилось внезапно, в панике, погружаться в дебри систем и обновлять внутренности действительно старого COBOL. Именно это произошло с печально известным багом Y2K.

Ошибка Y2K возникла вследствие старого конструктивного решения. Когда первые программисты на COBOL прописывали в своём ПО даты, они использовали две цифры: 1971 год, например, обозначался как 71. Так получилось, потому что у машин в 60-х и 70-х было очень мало памяти. Избавление от двух символов являлось серьёзной экономией. Все программы использовали память очень продуманно был дорог каждый байт, рассказывает мне Томас. Кроме того, кодеры 60-х и 70-х даже не мечтали о том, что их ПО будет использоваться тридцать лет спустя, когда приблизится 2000 год.

Но 2000 год надвигался, и даты из двух цифр превратились в огромную дилемму. В новом тысячелетии ПО на COBOL не будет знать, что означает 00 2000 или 1900. Если банк будет вычислять проценты по вкладу, сделанному в году 01, то он может ошибочно предположить, что вклад был сделан в 1901 году и перечислить клиенту проценты за 99 лет. Огромное количество банковских, розничных и зарплатных транзакций используют даты, поэтому необходимо было обновить миллиарды строк программ. Поскольку 2000 год приближался, банки вызвали своих старичков с пенсии, заплатили им за изучение кодовых баз, нахождение всех мест, где используются даты, и исправление ситуации.

На подготовку к Y2K мы потратили два с половиной года, посмеивается Томас. Это одна из причин, почему многие из программистов наподобие меня так хорошо знают наши системы. Нам пришлось разбираться в каждой программе.

Но даже при всём этом банку Томаса не хватило времени на полное решение проблемы. В некоторых случаях банки и фирмы не меняли код, чтобы можно было использовать полную дату из четырёх цифр, например, 2016. Вместо этого они применяли хак: правило сдвига. Они выбирали год далеко в будущем, например, 2045, и делали его новой точкой разрыва. Поэтому если COBOL встречает дату из двух цифр, которая больше 45, то он предполагает, что она относится к 1900-м, то есть, допустим, 87 это 1987 год. А если он встречает число меньше 45, то предполагает, что это 2000-е, то есть 33 означает 2033 год.

По словам Томаса, это означает, что проблема Y2K для них решена не полностью. Они просто отложили её решение. Когда наступит 2045 год, у них снова может возникнуть паника. А это означает, что специалистам по COBOL нужно будет исправлять новый COBOL.

Если только они ещё будут живы Крейг Бейли из программной фирмы Faircom работал с клиентами, помогая им мигрировать со старых систем COBOL. Фирма работала с каждым клиентом, находя старых уволившихся сотрудников, которые изначально писали эти системы, но время от времени ветераны в процессе работы умирали.

Однажды в понедельник утром нам позвонили: боже, проект встал такой-то работник умер, рассказывает Бейли.

Банкам приходится надеяться, что старички продержатся как можно дольше, потому что сегодня не так много молодёжи, изучающей COBOL.

Нам постоянно звонят компании: у вас есть кто-нибудь с любым опытом в COBOL? Они в отчаянии, рассказывает Мэрилин Цеппетелли, бывшая сотрудница IBM, работавшая на мейнфреймах компании, ныне профессор Marist College.

Marist один из немногих университетов, обучающих COBOL на постоянной основе. Многие учебные программы не рекламируют его. В научных кругах COBOL давно находится в униженном положении. Когда этот язык получил популярность в 70-х, элитные компьютерные учёные скорбели они заявляли, что COBOL стимулирует к выбору ужасных стилей кодирования, которые выходили из моды. Одним из таких примеров является конструкция GOTO: COBOL позволяет приказать программе внезапно перескочить с одной строки на другую, допустим, со строки 899 на строку 217. Честно говоря, компьютерные учёные правы! Подобный стиль кодинга приводит к созданию неряшливих, неупорядоченных программ, которые иногда сложно читать (это так называемый спагетти-код), а языки после COBOL в основном отказались от GOTO. Как бы то ни было, обвинения прилипли к языку. Для людей, серьёзно стремившихся к прогрессу в программировании, COBOL был языком неудачников, застоем.

Работа с COBOL вредит мозгу; следовательно, его преподавание должно считаться уголовным преступлением, так написал в 1975 году знаменитый компьютерный учёный Эдсгер Дейкстра. COBOL был скорее языком рабочего класса, вторжением синих воротничков в святыню кодинга. Кроме того, когда в 80-х появились недорогие настольные PC, они стали привлекательной новой территорией для запуска кода. Купить их мог любой, а для изучения COBOL требовался доступ к огромным мейнфреймам, которые в основном были только у банков или крупных розничных сетей. Когда малые и средние машины получили настоящую популярность, вузы перенесли весь процесс обучения на эти платформы, а мейнфреймы остались немного в стороне, говорит Цеппетелли. В наши дни смартфоны сделали COBOL ещё менее актуальным для студентов: Он просто не выглядит таким же сексуальным, как некоторые другие платформы.

Из-за малого количества специалистов многие банки, правительства и розничные продавцы уже давно используют аутсорсинг работ на COBOL. Они содержат в своём штате небольшое ядро кодеров, знающих язык, а когда им требуется написать что-то новое, нанимаются фирмы, имеющие полки кодеров на COBOL, например, COBOL Cowboys Билла Хиншоу или индийские компании.

Некоторые фирмы, озабоченные тем, что в будущем будет слишком трудно найти адептов COBOL, пытаются переписать всю свою систему на новом языке. Почти всегда это является адской задачей: необходимо продумать каждый аспект задач, выполняемый сложным, создававшимся десятки лет программным обеспечением, и воссоздать каждый малейший шаг на новом языке. Три года назад New York Times переписал систему циркуляции газет с COBOL на Java; попытка оказалась успешной, однако на подтверждение того, что новая система способна на всё то, что и старая, потребовалось неожиданно много времени.

И им ещё повезло. Commonwealth Bank of Australia попробовал переписать ядро системы на новом языке: на проект потратили вдвое больше ожидаемого, 1 миллиард австралийских долларов. Специалист по мейнфреймам с большим опытом Лен Санталусия однажды работал с финансовой организацией DTCC над исследованием возможности перехода с COBOL на Java.

У них было примерно семьдесят пять миллионов строк кода на COBOL, и они выяснили, что это будет им стоить так много, что на восполнение затрат потребуется, возможно, пара веков. Это было смехотворно. А ведь у них больше денег, чем у Бога.

Поэтому банки пожимают плечами и говорят: чёрт с ним. Если не сломано, то не надо чинить. Продолжим работать со старым COBOL. Эти программы работали круглосуточно в режиме 24/7 в течение тридцати-сорока лет. Зачем нам их менять?, говорит Томас.

В то же время банки пытаются мотивировать как можно больше людей изучать COBOL. Ты получишь работу на всю жизнь, смеётся Томас.

Однако проблема банков в том, что несмотря на стабильность их кода на COBOL, ожидания их клиентов могут оказаться не столь постоянными. Как вы могли догадаться, ситуация в финансовой отрасли быстро меняется. Транзакции всё больше происходят в приложениях типа Venmo, позволяющих людям отправлять деньги друзьям; сервисы наподобие Coinbase позволяют покупать криптовалюты; существуют новые приложения для кредитовая наподобие Tala и Upstart. Сегодня люди ожидают максимально простых способов управления своими деньгами через ПО.

И в этой области банки, у которых должно бы иметься постоянное преимущество в перемещении денег, испытывают трудности. Им сложно быстро создавать новые функции, потому что приходится иметь дело со стеками технологий юрского периода. Таково мнение Дэниса Райана, бывшего банкира, который сейчас работает директором по росту в ирландской фирме Showoff, занимающейся созданием приложений для финтеха. Эти старые бекэнды под управлением COBOL хранят данные в различных источниках по словам Дэниса, у них много ячеек. И, разумеется, со старым кодом опасно слишком много экспериментировать: Начинаются проблемы с ресурсами, технологиями, эксплуатацией и рисками.

При этом стартап может делать всё, что угодно. У него нет старых систем. Они находятся в ситуации, которую программисты с любовью называют с чистого листа. Вместо покупки мейнфреймов ценой сотни тысяч долларов для хранения и обработки данных они просто арендуют пространство в облачной системе типа Amazon. Они могут писать код на новом языке, поэтому способны нанять любого энергичного студента компьютерных наук. И им даже не обязательно создавать что-то самостоятельно: когда Showoff пишет новое финтех-приложение, для выполнения сложной задачи она может использовать готовый сервис, например, Stripe для обработки платежей, а не пытаться создать это ПО для себя.

Это снимает с команды большую долю эксплуатационной нагрузки, поэтому она может масштабировать свой продукт, говорит Райан, и работать над продуктом, не особо заботясь об инфраструктуре. Иными словами, им не нужно беспокоиться о COBOL.

Вероятно, COBOL никогда не умрёт. Однако это не мешает многим кодерам снова и снова прогнозировать его роковой конец. Первое предупреждение о том, что COBOL умер, появилось ещё до того, как он был выпущен.

К 1960 году комитет, изобретавшего COBOL, проработал всего лишь год, однако один из членов комитета, представитель RCA Говард Бромберг, беспокоился, что они движутся слишком медленно. Он утверждал, что если не выпустить COBOL быстрее, то мир бизнеса может уйти вперёд! Изготовители компьютеров выпустят собственные уникальные языки, а в бизнес-программировании возникнет ситуация вавилонского смешения языков.

Поэтому Бромберг в сердцах решил отправить послание главе комитета по COBOL Чарли Филлипсу, работавшему в министерстве обороны. Бромберг привёз могильный камень, увенчанный гранитным знаком жертвенного агнца, с выгравированным словом COBOL. (Что это за имя такое?, спросили его в агентстве ритуальных услуг.)

Бромберг засунул могильный камень в ящик и отправил Филлипсу в Пентагон. По всей отрасли ходят слухи, что COBOL умирает, позже вспоминала Грейс Хоппер.

60 лет спустя этот могильный камень находится в Музее компьютерной истории в Маунтин-Вью, Калифорния, а COBOL продолжает править миром.