Старый ящик — новый ящик, белый ящик — черный ящик. Теорвер или эзотерика?

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Условия задачи:
Есть программная система разработанная в течении многих лет разными разработчиками. Несколько месяцев назад она была развернута и как-то работала на серверах (по крайней мере это утверждает клиент). После этого была продана клиенту, который пришел с ней к украинским мастерам для того, что бы они ее наладили и «допилили».

Результаты анализа:
Документация — отсутствует. Люди, обладающие знанием о системе — недоступны. Клиент систему в работе видел только несколько раз и понимания как она работала не имеет (вместо этого у него есть представление что в ней уже есть все готовое что бы воплотить его самые безумные фантазии). Единственный источник данных о системе — это исходный код. Для некоторых модулей неизвестного происхождения исходный код отсутствует и они подключаются в виде скомпилированных библиотек. Количество модулей велико, их интерфейсы и взаимодействие нигде не описаны.

Исходный код написан разными людьми в разное время. Общей архитектуры, практик и соглашений по дизайну, именованию, оформлению кода не прослеживается. Часть кода содержит явные ошибки и очевидно является «мертвой», либо ошибки не влияли на конечный результат. Распространенной практикой является подавление любых ошибок внутри метода без логирования и возврат результата «по умолчанию» (NULL, 0, −1). Часть кода закомментирована, во многих местах присутствуют комментарии из которых можно понять что это «заплатка», временное решение либо девелопер не мог понять что делает код написанный другим (и написал что-то вроде «не знаю зачем Вася это здесь вызывает но оставлю на всякий случай»). В коде очень большая косвенность (классы вызывают друг-друга по многу раз даже для выполнения простых задач), много «предположений» построенных на совпадении имен или идентификаторов, активно используется динамическое связывание и «рефлексия». Так же присутствуют меж-потоковые и меж-процессные вызовы разного вида (как по сети так и «локальные») что усложняет дебагинг.

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

Это было описание «старого ящика», который нам отдал клиент.

Цель: клиент хочет от нас починить и развернуть систему в рабочем состоянии. После этого «сконфигурировать» ее что бы она реализовала видение клиента. У клиента есть мнение что это не сложная задача (ведь система «рабочая»), с которой профессионалы могут справится очень быстро.

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

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

Сейчас стоит проблема выбора стратегии поисков. Все возможные стратегии делятся на метод «черного ящика» — когда мы не смотрим в код, и метод «белого ящика» — когда смотрим.

А) Черный ящик

А.1) Слепой перебор. Пробуем развернуть на «голом» сервере «как есть», запускаем тесты, если не сработало то что-то меняем.
Плюсы:
— Если составить все возможные значения настроек и перебирать все комбинации без пропуска то риск пропустить правильную довольно низкий.
— Время проверки известно как известно и число комбинаций поэтому можно оценить общее время и прогресс задачи.
— Не требует больших знаний от исполнителей — можно посадить много людей перебирать свой набор настроек.
Минусы:
— Время перебора всех комбинаций огромно (десятки тысяч часов).
— Вероятность угадать правильную комбинацию не зависит от времени (она может оказаться последней).

А.2) Направленный перебор. Делаем предположение о наиболее разумном наборе настроек, проверяем, анализируем ошибки, меняем предположение, проверяем опять.
Плюсы:
— Поскольку первыми пробуем наиболее логичные комбинации, то вероятность угадать раньше повышается.
Минусы:
— Зависит от знаний и интуиции исполнителей.
— Сложно распаралелить работу и непонятно насколько это ускорит процесс.
— Невозможно заранее предсказать сроки получения результата и невозможно отслеживать прогресс.
— Есть риск пропустить правильную комбинацию разминувшись с ней всего в одной настройке.

Б) Белый ящик

Б.1) Полный анализ кода. Изучить весь код, разобраться как он работает, пройти дебагом все основные маршруты, нарисовать схемы, все документировать и т.д.
Плюсы:
— Гарантированное получение результата и возможности исправлять проблемы.
Минусы:
— Исключает вероятность случайной удачи.
— Время изучения кода велико (тысячи часов). Превосходит время разработки подобной системы «с нуля».
— Процесс изучения нелинейный и тяжело отслеживать прогресс.
— Зависит от квалификации девелоперов.
— При уходе девелопера часть знаний будет неизбежно потерянна.
— Сложно распаралелить работу и непонятно насколько это ускорит процесс.

Б.2) Частичный анализ кода. Изучение кода, построение гипотезы как он работает, проведение экспериментов, корректировка гипотезы.
Плюсы:
— Совмещает накопление знаний о системе с вероятностью случайной удачи.
— Есть вероятность что потребует меньше времени, чем изучение всего кода и чем перебор вариантов.
Минусы:
— Гипотезы могут быть ложными а понимание кода — неполным.
— Процесс изучения нелинейный и тяжело отслеживать прогресс.
— Зависит от квалификации девелоперов.
— Сложно распаралелить работу и непонятно насколько это ускорит процесс.

В) Новый ящик
Как особую стратегию необходимо так же учесть вариант «нового ящика». Вместо работы со старой системой начать строительство новой «с нуля» и постепенно реализовать в ней все ожидания клиента.
Плюсы:
— Полный контроль над ходом проекта и результатами.
— Возможность быстро находить и исправлять проблемы а так же вносить изменения.
— Использование современных библиотек и компонентов ускоряет разработку.
— Можно распаралелить работу.
— Промежуточные результаты видны клиенту.
— Можно добавить функциональность, которая отсутсвовала в старой системе.
Минусы:
— Исключает вероятность случайной удачи. Новая система не заработает пока не будет готова.
— Единственным источником информации о том, что должна делать система является клиент.
— Время разработки системы «с нуля» значительное (около тысячи часов). Оно зависит от изменений требований.

Очевидно, что в последнее время клиенты не рискуют отдавать на разработку в Украину новые масштабные проекты. Поэтому «лидеры рынка» все чаще с радостью берут старые, гнилые проекты на «бесконечный ремонт и перекраску». Или продают своих сотрудников в международные команды таких проектов. Куда набирают команду из принципа: не прибыльный проект, но закрывать жалко — наберем со всего мира кого подешевле: авось что-то сделают. В наших условиях вариант «не соглашаться с клиентом» и менеджеры даже не рассматривают — ведь местных менеджеров в европах никто не ждет, в отличии от девелоперов.

Вопросы к тем, кто сталкивался с подобным «старым ящиком»:
— Какую стратегию выбирали?
— Чье это было решение: команды, менеджера, клиента?
— Делали ли ставку на удачу: поковыряем — и вдруг сразу заведется?
— Или ныряли в пучины спагетти-кода?
— А может втихаря делали новую версию «с нуля» что бы потом удивить клиента?
— Какая текучка кадров при разной стратегии: сколько спивается от бесполезных попыток или сходит с ума от дебага кода?

И, наконец, самый главный вопрос — вопрос Веры! Можно верить в науку и теорию вероятности. Но после многих дней бесплодных попыток днем и ночью (каждая попытка занимает время и надо ждать), после крушения сотен логичных предположений, после неоднократных блужданий в коде, который на проверку оказывался мертвым, моя вера в науку и здравый смысл начинает истончаться. В конце-концов та же наука не исключает возможность удачи или даже чуда при самой низкой вероятности события. Может есть возможность как-то повлиять: найти удачливого девелопера, положить подкову на сервер, пригласить гадалку, экстрасенса или батюшку? Что если математическое ожидание количества попыток давно пройдено — а результата все нет? Может это «бес водит» или кто-то сглазил? Что делать?

Я знаю что на ДОУ есть верующие девелоперы: скажите, есть примеры когда искренняя молитва помогала запустить приложение? Практикуете ли вы иконы, свечи, часовню, церковные службы в офисе?

Или может есть увлекающиеся эзотерикой: помогают ли гороскопы, имеет ли смысл переставить сервера по фен-шую, можно ли сделать «снимок ауры» и отследить потоки негативной энергии или геопатогенные зоны в офисе?

Ну и напоследок: есть ли у вас в компании штатный психолог, который помогает тем, у кого уже начинает съезжать крыша от такой работы?