Как хорошие инженеры пишут плохой код в крупных компаниях

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

Большинство изменений в коде вносятся новичками

Я думаю, главная причина заключается в том, что в крупных компаниях полно инженеров, работающих вне своей зоны экспертизы. Среднестатистический сотрудник бигтеха работает на одном месте всего год или два¹. На самом деле, компенсационные пакеты в бигтехе обычно рассчитаны на ограничение срока работы инженера четырьмя годами: через четыре года первоначальный пакет акций полностью переходит в собственность (вестится), что приводит к сокращению дохода инженера, порой на 50%. Компании предлагают временные ежегодные обновления пакетов, но это очевидно стимулирует инженеров искать другую работу, где им не придется гадать, получат ли они вторую половину своей компенсации каждый год.

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

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

Старожилы

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

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

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

Среднестатистический продуктивный инженер

Собрав всё это вместе, как выглядит среднестатистический продуктивный² инженер в крупной технологической компании? Обычно они:

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

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

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

Крупные технологические компании это устраивает

Я много писал о внутренней динамике технологических компаний, которая способствует этому. Наиболее прямо в статье Seeing like a software company я утверждаю, что крупные технологические компании последовательно ставят внутреннюю управляемость (legibility) — способность мгновенно видеть, кто над чем работает, и менять это по своему желанию — выше продуктивности. Крупные компании знают, что отношение к инженерам как к заменяемым ресурсам и их перемещение разрушает их способность развивать долгосрочную экспертизу в одной кодовой базе. Это сознательный компромисс. Они жертвуют некоторой долей экспертизы и качества программного обеспечения ради возможности быстро перебрасывать квалифицированных инженеров на любую «проблему месяца».

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

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

Чистая и нечистая инженерия

Я думаю, многое сводится к различию между чистой и «нечистой» (impure) программной инженерией. Для «чистых» инженеров — тех, кто работает над самодостаточными техническими проектами, такими как язык программирования, — единственным объяснением плохого кода является некомпетентность. Но «нечистые» инженеры действуют скорее как сантехники или электрики. Они работают в условиях дедлайнов над проектами, которые для них относительно новы, и даже если их технические основы безупречны, всегда найдется что-то в конкретной конфигурации данной ситуации, что будет неудобным или неожиданным. Для таких инженеров плохой код неизбежен. Пока общая система работает достаточно хорошо, проект считается успешным.

В крупных технологических компаниях инженеры не решают, работают ли они над «чистой» или «нечистой» инженерной задачей. Это не их кодовая база! Если компания хочет перевести вас с работы над инфраструктурой баз данных на создание новой платежной системы, она имеет полное право это сделать. Тот факт, что вы можете совершить ошибки в незнакомой системе — или что ваши бывшие коллеги из команды инфраструктуры БД могут пострадать без вашей экспертизы — это сознательный компромисс, на который идет компания, а не инженер.

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

Для меня было удивительно, что многие комментаторы сочли эту точку зрения неприятно нигилистической. Я считаю себя довольно оптимистичным в отношении своей работы. На самом деле, я задумывал этот пост как вдохновляющую защиту инженеров бигтеха от их критиков! Тем не менее, я нашел этот ответный пост в блоге отличным выражением позиции «это слишком цинично» и, вероятно, скоро напишу продолжение. Если вам не терпится, я немного писал на эту тему в начале 2025 года в статье Is it cynical to do what your manager wants?.

Некоторые комментаторы на Hacker News выдвигали альтернативные теории того, почему появляется плохой код: отсутствие мотивации, намеренная деморализация инженеров, чтобы они не объединялись в профсоюзы, или просто чистая оптимизация скорости. Я не нахожу их убедительными, основываясь на моем собственном опыте. Многие мои коллеги высоко мотивированы, и я просто не верю, что какая-либо технологическая компания намеренно пытается сделать своих инженеров деморализованными и несчастными.

Несколько читателей не согласились со мной по поводу того, что RSU (акции) создают стимул к уходу, потому что их компании дают обновления пакетов акций (refreshers). Я не знаю насчет этого. Я тоже получаю обновления, но если их нет в контракте, то я не думаю, что это имеет значение — компания может решить не давать вам 50% вашей компенсации по своему желанию, просто приостановив обновления, что является стимулом сменить работу, чтобы зафиксировать сумму еще на четыре года.