Как повторить плохо описанный протокол
Проекту нужно повторить плохо документированный legacy-протокол. Как подойти к исследованию и реализации, если часть поведения приходится восстанавливать по трафику и старой системе?
Короткий ответ
Нужно собрать observable behavior: документация, дампы трафика, эталонная система, edge cases. Затем зафиксировать контракт тестами и строить совместимую реализацию итерациями.
Полный разбор
Рабочий план начинается с границ совместимости: какие клиенты или сервисы должны считать новую реализацию эквивалентной старой. Дальше собираем источники: официальная документация, старый код, Wireshark/pcap, логи, ответы эталонной системы на набор запросов. Важно сразу выделить core-сценарии и obscure edge cases.
Реализацию лучше вести через тесты совместимости: для каждого восстановленного сценария фиксировать input/output, ошибки, таймауты, порядок сообщений и ограничения версий. Если протокол бинарный, нужны парсер, golden fixtures и property/invariant checks. Если есть неопределенность, ее нужно записывать как assumption, а не превращать в скрытое поведение.
С точки зрения lead-а ключевой риск - бесконечный research без delivery. Поэтому полезно разделить MVP-совместимость, production-hardening и long tail протокола.
Теория
Reverse engineering в backend - это не угадывание реализации, а восстановление внешнего контракта через наблюдаемое поведение и тесты совместимости.
Типичные ошибки
- Сразу переписывать все, не зафиксировав контракт совместимости.
- Не сохранять дампы и golden cases.
- Не отделять обязательные сценарии от редких edge cases.
Как отвечать на собеседовании
- Скажи про Wireshark/pcap, golden fixtures и compatibility tests.
- Обозначь MVP-scope и риски неизвестного поведения.