Python-обертка или полный rewrite legacy C
Есть legacy C-компонент и желание дать пользователям удобный Python/API слой. Как рассуждать: делать обертку вокруг C или полностью переписывать реализацию на Python?
Короткий ответ
Нужно сравнить correctness risk, скорость разработки, performance, поддержку C-кода, безопасность и стоимость миграции. Часто разумный путь - Python facade плюс постепенное вынесение/переписывание частей.
Полный разбор
Полный rewrite привлекателен чистотой, но несет высокий риск потери совместимости и долгой стабилизации. Обертка вокруг C сохраняет проверенную реализацию и performance, но оставляет legacy-зависимость, сложный debugging, memory safety риски и границу FFI.
Решение зависит от того, где находится ценность. Если C-компонент реализует сложный протокол и уже надежно работает, Python facade может быстро дать удобный API, observability, auth, validation и интеграции. Если старый код небезопасен, плохо тестируем и мешает развитию, можно переписывать по частям, фиксируя контракт golden tests.
На интервью важно показать не идеологию "Python проще" или "C быстрее", а миграционный план: контракт, тесты совместимости, feature parity, performance budget, rollout и fallback.
Теория
Миграция legacy-системы - это управление риском совместимости. Язык реализации вторичен по отношению к контракту, тестам и rollout-стратегии.
Типичные ошибки
- Недооценивать стоимость полного rewrite.
- Оставлять C-компонент без тестов и observability.
- Не иметь rollback/fallback при замене критичной реализации.
Как отвечать на собеседовании
- Назови facade/adapter, FFI, golden tests и phased migration.
- Сравни скорость разработки, performance и correctness risk.