Код — это не просто строки. Это безопасность, деньги и иногда — человеческие жизни
В мире, где от программного обеспечения зависят жизни людей и судьбы компаний, есть специалисты, которые видят то, что другие упускают. Они понимают: код — это не просто строки на экране. Это безопасность, деньги, репутация, а иногда — человеческие жизни. И обычный подход «написать код по заданию» оказывается недостаточным.
Дарья Золотухина работает там, где ошибки недопустимы. Диспетчерские системы крупнейших аэропортов Европы. Автоматизация открытия брокерских счетов в банке. Отрасли, где сбой означает не «перезагрузите страницу», а реальные убытки и риски.
Её отличает редкое умение: она видит технические риски через призму того, как устроена отрасль изнутри. Знание банковских операций и авиационных процессов позволяет найти проблему ещё на этапе проектирования — до того, как она появилась в реальной работе системы.
В эксклюзивном интервью она рассказывает, почему инженер, понимающий бизнес, строит лучшие системы, как одна кнопка может стоить компании миллионов и почему слепое следование требованиям — путь к хрупким решениям.
— Дарья, вы работаете в отраслях, где от программного обеспечения зависит больше, чем удобство пользователя. Авиация, банки — там, где ошибка стоит дорого. Как вы попали в эту нишу?
— Честно говоря, это произошло не сразу. В начале карьеры я, как и многие, воспринимала свою роль классически: есть техническое задание, есть сроки, есть код. Но постепенно пришло понимание: в сложных системах слепое следование требованиям часто ведёт к созданию хрупких решений.
Проблема в том, что бизнес-требования редко учитывают все технические нюансы и пограничные сценарии, которые возникают в реальной эксплуатации. Именно здесь проходит граница между просто хорошим специалистом и инженером, который способен строить по-настоящему надёжные системы.
— Ваш опыт охватывает две очень разные, но одинаково критичные отрасли — авиацию и финансы. Что общего в подходе к разработке для таких систем?
— На первый взгляд — ничего. Авиация — это безопасность полётов, финансы — это сохранность средств. Но на уровне инженерии общее одно: цена ошибки здесь не просто баг в отчёте. В авиации задержка или потеря данных на экране диспетчера — это риск для реальных рейсов. В банках дублирующая проводка или потерянный документ — это прямые убытки и репутационные потери.
Поэтому классическое представление о роли инженера как простого исполнителя технических заданий здесь не работает. Если слепо следовать требованиям, не понимая контекста, можно построить хрупкую систему. Проблема в том, что бизнес-требования редко учитывают все пограничные сценарии, которые возникают в реальной эксплуатации. Именно здесь проходит граница между просто хорошим специалистом и инженером, который способен строить по-настоящему надёжные системы.
— Давайте начнём с авиации. Вы работали с системами для крупнейших аэропортов Европы. Что значит «проектировать для диспетчера»?
— Для меня это был самый яркий пример того, как контекст диктует архитектуру. Задача звучала формально: настроить передачу данных от авиакомпаний в диспетчерскую систему. Но если бы я подошла к этому как к простой интеграции, я бы сделала обычный конвейер данных.
Однако я понимала: диспетчер принимает решения в реальном времени, и любая задержка или устаревшая информация на его экране могут привести к ошибкам в управлении воздушным движением. Поэтому мы внедрили механизмы буферизации и приоритизации источников. Даже если данные от авиакомпаний поступают хаотично или с перегрузкой, диспетчер всегда видит самую свежую и достоверную информацию. Это архитектурное решение было продиктовано не техническим заданием, а пониманием критичности бизнес-процесса — в данном случае безопасности полётов.
— Потом вы перешли в банковский сектор и создавали инвестиционную платформу для малого и среднего бизнеса. Как изменилась ваша роль?
— В банке я была backend-разработчиком, и здесь требования к надёжности другие, но не менее жёсткие. В финансах инженер должен видеть за кодом юридические и финансовые последствия.
Например, мы проектировали механизм подписания документов для открытия брокерских счетов. На первый взгляд — просто форма с кнопкой. Но я сразу закладывала защиту от повторных запросов и проверку состояний на уровне базы данных. Почему? Потому что в реальности клиент может нажать кнопку дважды из-за плохого интернета или торможения интерфейса. Если система не обработает это корректно, она создаст два дублирующих счёта или два платёжных поручения. Для бизнеса это — хаос в учёте, для клиента — головная боль. Понимание этого контекста заставило меня проектировать идемпотентность* с самого начала, а не «допиливать» потом, когда ошибки уже возникли.
* идемпотентность — свойство объекта или операции при повторном применении давать тот же результат, что и при первом.
— Вы также упомянули работу с внешними данными и интеграциями. Почему это отдельная зона риска?
— В сложных проектах информация часто поступает из десятков разных источников, и структура у неё хаотичная. Если инженер не погружён в доменную область, он может воспринимать это просто как техническую задачу по перекладыванию данных. Но я всегда уделяю внимание созданию слоёв валидации, которые проверяют файлы на целостность и подмену форматов ещё до начала обработки.
В финансах, например, приходит выписка от контрагента. Если инженер не понимает, что в этой выписке критически важно, он может пропустить некорректный формат, и система тихо обработает данные с ошибкой. В результате — расхождение балансов, потеря документов, которые потом сутками разбирают аналитики. Понимание бизнес-контекста позволяет заранее предусмотреть такие риски и заложить защиту.
— В одном из ваших проектов была миграция миллионов документов при слиянии банковских структур. Это как раз тот случай, когда быстрое решение может обернуться катастрофой?
— Абсолютно. Когда перед командой стоит задача перенести огромные массивы данных, всегда есть соблазн написать одноразовые скрипты: «быстро, дёшево, и потом забудем». Но я понимала ценность этих данных для бизнеса — это не просто файлы, а юридически значимые документы. Потеря или искажение хотя бы одного из них могла обернуться многомесячными разбирательствами.
Вместо одноразовых скриптов я выстроила процесс на основе строгих паттернов обработки транзакций и механизмов блокировок в базе данных. Это потребовало больше времени на этапе проектирования, но зато гарантировало полную согласованность данных. Мы избавили команду от необходимости вручную исправлять ошибки после миграции. Для меня отказ от быстрых решений в пользу фундаментально правильной архитектуры — это не перфекционизм, а способ защитить бизнес от сбоев в будущем.
— Получается, что ключевое отличие вашего подхода — это глубокое погружение в бизнес-процессы. Но как этому научиться? Многие разработчики считают, что их дело — код, а «вот это всё» — работа аналитиков.
— Я часто слышу такое разделение и считаю его вредным. Профессиональный рост инженера невозможен без выхода за рамки написания кода. Я всегда советую коллегам как можно больше общаться с аналитиками и, если возможно, с конечными пользователями. Когда ты понимаешь, как твоя система работает на практике, многие технические решения становятся очевидными.
Например, если бы я не знала, что диспетчеры работают в условиях стресса и должны мгновенно считывать информацию, я бы никогда не догадалась приоритизировать источники данных. Если бы я не представляла, как клиент взаимодействует с формой подписания, я бы не заложила защиту от двойного клика. Программное обеспечение создаётся для обслуживания реальных процессов. Чем лучше мы понимаем эти процессы, тем более надёжные и качественные системы мы способны строить.
— Ваш путь — от авиационных систем до банковских платформ — показывает, что вы не боитесь менять домены. Что помогает вам быстро входить в новую предметную область?
— Мне помогает инженерный подход, перенесённый на анализ бизнеса. Я не пытаюсь выучить все тонкости отрасли сразу. Вместо этого я задаю вопросы: что самое ценное в этой системе? Какие сценарии самые критичные? Где цена ошибки максимальна? Ответы на них сразу дают точки фокуса.
Кроме того, я считаю, что хороший инженер должен обладать эмпатией к пользователю. В авиации моим пользователем был диспетчер, в банке — сначала сотрудники, потом клиенты-предприниматели. Если ты можешь поставить себя на их место, понять, в каких условиях они работают и что для них важно, то и технические решения становятся не абстрактными, а очень конкретными и правильными.
— Если подводить итог, какой главный совет вы бы дали разработчикам, которые хотят перейти от роли исполнителя к роли архитектора, создающего надёжные системы?
— Я бы сказала три вещи:
Первое: не бойтесь выходить за рамки своей задачи. Спрашивайте «зачем» у бизнеса, изучайте, как работает вся цепочка.
Второе: всегда закладывайте защиту от ошибок, которые неизбежно возникнут в реальной эксплуатации — двойные клики, хаотичные данные, сбои связи. Не надейтесь, что пользователь будет идеальным.
Третье: не гонитесь за быстрыми решениями в ущерб фундаментальной архитектуре. Технический долг в критических системах — это не абстракция, это реальные риски и многократно возросшие затраты на поддержку.
В конечном счёте программное обеспечение создаётся для людей и процессов. Чем лучше мы понимаем и тех, и другие, тем более надёжные системы мы строим. И это, на мой взгляд, и есть настоящая инженерия.