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

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

Думаю, главная причина этого в том, что в больших компаниях куча разработчиков трудится не по своей специализации. В среднем сотрудник крупной технологической компании работает в ней всего один-два года¹. Условия оплаты труда в них обычно организованы так, чтобы ограничить срок карьеры разработчика четырьмя годами: спустя четыре года завершается полный вестинг изначального пакета, заставляя разработчиков соглашаться на потенциальное снижение компенсации на 50%. Да, компании выпускают временные ежегодные пакеты, но это, очевидно, мотивирует разработчиков искать новую работу, где им не придётся гадать, будут ли они каждый год получать половину компенсации.

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

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

Ветераны

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

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

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

Медианный продуктивный разработчик

Подведём итог: как же можно описать медианного продуктивного² разработчика в крупной технологической компании? Обычно он:

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

• или работает с кодовой базой или языком, во многом новым для него,

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

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

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

Большие технологические компании это устраивает

Я много писал о внутренней динамике технологических компаний, способствующей такому положению дел. В посте Seeing like a software company я говорю о том, что крупные технологические компании всегда отдают приоритет внутренней понятности (способности мгновенно понять, кто над чем работает, и при необходимости перебрасывать людей) в ущерб продуктивности. Крупные компании знают, что когда они обращаются с разработчиками, как с винтиками, и переводят их туда-сюда, то уничтожают возможность накопления долговременной экспертизы в отдельной кодовой базе. И на этот компромисс они идут осознанно. Они отказываются от определённой величины экспертизы и качества ПО, чтобы получить возможность быстро перебрасывать опытных разработчиков на новую «горящую» задачу.

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

Сами разработчики по отдельности совершенно никак не могут изменить эту динамику. Особенно актуально это в 2025 году, когда баланс сил сместился в сторону руководства технологических компаний. Лучшее, что может сделать конкретный разработчик — попытаться стать «ветераном»: наработать экспертизу хотя бы в одной области, и с её помощью отклонять наихудшие изменения, направляя других разработчиков в сторону хотя бы минимально разумных технических решений. Но даже это часто оказывается движением против потока организации в целом, и если не справляться этим филигранно, то можно перестать соответствовать требованиям плана по улучшению показателей, а то и ещё что похуже.

Чистая и грязная разработка

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

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

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

Этот пост собрал много комментариев на Hacker News и lobste.rs.

Меня удивило то, что многие комментаторы посчитали мою точку зрения неприятно нигилистичной. Лично я достаточно оптимистично отношусь к своей работе. На самом деле, пост написан для того, чтобы защитить разработчиков от их критиков!

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

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

1. Мне не удалось найти хорошие оригинальные источники этих данных. В отчёте PayScale за 2013 год говорится о том, что медианная текучка в Google составляет 1,1 года; мне кажется, что это слишком мало.

2. Многие разработчики в крупных технологических компаниях непродуктивны, но это уже тема для отдельного поста. Я не хочу вдаваться в эту тему по двум причинам. Во-первых, я считаю, что даже компетентные разработчики создают плохой код, поэтому можно ограничиться только ими. Во-вторых, даже если код написал некомпетентный разработчик, его почти всегда проверяют компетентные, и вопрос о том, почему этого не произошло, по-прежнему интересен.

3. Здесь я имел в виду не недавний пример GitHub Actions, с которым я напрямую не соприкасался. Мне припоминаются как минимум десять примеров, которые были связаны непосредственно со мной.

4. На мой взгляд, причина этого в основном в нехватке воображения: представлении, что твоя рабочая среда сильно похожа на все остальные.