Каждую пару лет кто-нибудь замечает, что крупные технологические компании иногда пишут на удивление мусорный код. Если вы не работали в большой компании, то вам может быть сложно понять, почему это происходит. Уровень зарплат в крупных технологических компаниях позволяет привлекать многих компетентных разработчиков. Они работают довольно неспешно, поэтому создаётся впечатление, что у них достаточно времени, чтобы выполнять работу качественно. Как же появляется плохой код?
Большинство изменений в код вносится относительными новичками
Думаю, главная причина этого в том, что в больших компаниях куча разработчиков трудится не по своей специализации. В среднем сотрудник крупной технологической компании работает в ней всего один-два года1. Условия оплаты труда в них обычно организованы так, чтобы ограничить срок карьеры разработчика четырьмя годами: спустя четыре года завершается полный вестинг изначального пакета, заставляя разработчиков соглашаться на потенциальное снижение компенсации на 50%. Да, компании выпускают временные ежегодные пакеты, но это, очевидно, мотивирует разработчиков искать новую работу, где им не придётся гадать, будут ли они каждый год получать половину компенсации.
Если же учесть внутреннюю текучку, то ситуация становится ещё хуже. Максимальный мой срок нахождения в одной команде или кодовой базе — три года, и это было в самом начале моей карьеры. Я уже привык к тому, что реорганизация будет происходить каждый год, а иногда и ещё чаще.
Однако средний срок службы кодовой базы в крупной технологической компании гораздо дольше. Многие сервисы, которые я разрабатывал, существуют десяток лет или больше, и за эти годы они сменили множество отвечающих за них команд. Из-за этого многим разработчикам постоянно приходится разбираться в новом для себя коде. Довольно высокий процент изменений вносится «новичками»: людьми, которые пришли в компанию, перешли к этой кодовой базе или даже на новый язык программирования за последние шесть месяцев.
Ветераны
В какой-то степени проблема устраняется благодаря «ветеранам»: разработчикам, достаточно долго находящимся в орбите конкретной системы и выработавшим реальный опыт работы с ней. Эти разработчики могут проводить тщательные ревью кода и отлавливать очевидные проблемы. Но когда надеешься на «ветеранов», возникает две проблемы.
Во-первых, этот процесс оказывается совершенно неформальным. Крупные технологические компании предпринимают на удивление мало усилий к тому, чтобы накапливать долговременную экспертизу в системах, и после её получения они, похоже, вообще не стремятся её сохранять. Часто обладающих знаниями о системе разработчиков переводят на другие сервисы, и они или должны выполнять свои обязанности «ветерана», по сути, на добровольной основе, или забросить их и стать относительным новичком в совершенно новой системе.
Во-вторых, опытные разработчики всегда перегружены. Быть одним из малочисленной группы разработчиков с глубокой экспертизой в конкретном сервисе — это напряжённая работа. У таких людей не хватает времени на личное ревью каждого программного изменения и на активное участие в каждом процессе принятия решений, ведь им ещё и нужно выполнять собственную работу: если тратить всё своё время на ревью изменений и участие в обсуждениях, то компания, скорее всего, накажет тебя за недостаточно большой личный вклад.
Медианный продуктивный разработчик
Подведём итог: как же можно описать медианного продуктивного2 разработчика в крупной технологической компании? Обычно он:
достаточно компетентен, чтобы преодолеть планку найма и ��правляться с работой, но в то же время он:
или работает с кодовой базой или языком, во многом новым для него,
или пытается не утонуть в потоке изменений кода, параллельно успевая выполнять свою собственную работу.
Почти всегда он работает в условиях дедлайна или нескольких пересекающихся дедлайнов разных проектов. Иными словами, пытается справляться со своей работой в среде, не предназначенной для написания качественного кода.
Очевидно, именно так и возникает плохой код. Например, разработчик-джун берёт тикет надоедливого бага в кодовой базе, с которой он едва знаком. Несколько дней он разбирается в новом для себя коде и создаёт костыльное решение. Один из «ветеранов», сениор-разработчик вкратце просматривает это решение за полчаса (если повезёт), отклоняет его и предлагает что-нибудь слегка получше, чтобы оно хотя бы работало. Джун реализует его предложение в пределах своих возможностей, тестирует его, решение проходит краткое ревью и выпускается, после чего все участвовавшие в его создании немедленно переходят к работе с более высоким приоритетом. Пять лет спустя кто-то замечает это решение3 и думает: «Ого, вот так накостылили. Почему такой плохой код пишут в большой технологической компании?»
Большие технологические компании это устраивает
Я много писал о внутренней динамике технологических компаний, способствующей такому положению дел. В посте Seeing like a software company я говорю о том, что крупные технологические компании всегда отдают приоритет внутренней понятности (способности мгновенно понять, кто над чем работает, и при необходимости перебрасывать людей) в ущерб продуктивности. Крупные компании знают, что когда они обращаются с разработчиками, как с винтиками, и переводят их туда-сюда, то уничтожают возможность накопления долговременной экспертизы в отдельной кодовой базе. И на этот компромисс они идут осознанно. Они отказываются от определённой величины экспертизы и качества ПО, чтобы получить возможность быстро перебрасывать опытных разработчиков на новую «горящую» задачу.
Не знаю, хорошо это или плохо. Это определённо работает в крупных технологических компаниях, особенно сегодня, когда так важно, насколько быстро они могут развернуться в сторону чего-нибудь, связанного с ИИ. Но если так делать, то при этом безусловно будет возникать откровенно плохой код. Именно это и происходит, когда ты заставляешь разработчиков быстренько выдавать результат в системах, с которыми они незнакомы.
Сами разработчики по отдельности совершенно никак не могут изменить эту динамику. Особенно актуально это в 2025 году, когда баланс сил сместился в сторону руководства технологических компаний. Лучшее, что может сделать конкретный разработчик — попытаться стать «ветераном»: наработать экспертизу хотя бы в одной области, и с её помощью отклонять наихудшие изменения, направляя других разработчиков в сторону хотя бы минимально разумных технических решений. Но даже это часто оказывается движением против потока организации в целом, и если не справляться этим филигранно, то можно перестать соответствовать требованиям плана по улучшению показателей, а то и ещё что похуже.
Чистая и грязная разработка
Думаю, многое из этого сводится к различию между чистой и грязной разработкой. Для «чистых» разработчиков, работающих над автономными техническими проектами, например, над языком программирования, единственное объяснение плохого кода заключается в некомпетентности. Однако работа «грязных» разработчиков больше напоминает труд сантехников или электриков. Они работают в рамках дедлайнов над относительно новыми для них проектами, и даже если их технические знания безукоризненны, в конкретной ситуации всегда найдётся что-то, делающее её неудобной или неожиданной. Для «грязных» разработчиков плохой код — это неизбежность. Но если в целом система работает достаточно хорошо, то проект можно считать успешным.
В крупных технологических компаниях разработчики не могут решать, выбрать ли им «чистую» или «грязную» работу. Это не их кодовая база! Если компания пожелала перевести их с работы над инфраструктурой базы данных на создание новой платёжной системы, то имеет на то полное право. То, что разработчик может совершать ошибки в незнакомой ему системе, или то, что старые коллеги из команды инфраструктуры базы данных могут пострадать ��ез его опыта — это сознательное решение, принимаемое компанией, а не разработчиком.
И вполне нормально указывать на примеры плохого кода в больших компаниях. Как минимум, это может быть эффективным способом устранения конкретных проблем, потому что руководство обычно с радостью ухватывается за любую возможность превратить плохой пиар в хороший. Но я думаю, было бы ошибкой4 возлагать непосредственную ответственность на разработчиков из этих компаний. Даже если взмахнуть волшебной палочкой и сделать всех разработчиков вдвое сильнее, плохой код всё равно будут писать, потому что почти никто не может прийти в совершенно новую для него кодовую базу и сразу начать вносить изменения без малейших ошибок. Первопричина этого в том, что в большинстве крупных компаний разработчики вынуждены работать с незнакомыми кодовыми базами.
Этот пост собрал много комментариев на Hacker News и lobste.rs.
Меня удивило то, что многие комментаторы посчитали мою точку зрения неприятно нигилистичной. Лично я достаточно оптимистично отношусь к своей работе. На самом деле, пост написан для того, чтобы защитить разработчиков от их критиков!
У некоторых комментаторов на Hacker News есть альтернативные теории причин возникновения плохого кода: отсутствие мотивации, намеренная деморализация разработчиков, чтобы они не объединялись в профсоюзы, или просто оптимизация для обеспечения скорости. Исходя из моего собственного опыта, такие объяснения не кажутся мне убедительными. Многие мои коллеги сильно мотивированы, и я не думаю, что хоть какая-то технологическая компания намеренно старается деморализовать своих разработчиков и сделать их несчастными.
Некоторые читатели не согласились со мной в том, что RSU мотивируют увольняться, потому что их компании периодически выдают новые пакеты. Я тоже их получаю, но если их нет в договоре, то не думаю, что это важно — компания может решить не выдавать вам 50% компенсации по собственному усмотрению, просто приостановив выдачу новых пакетов, а это мотивация менять работу, чтобы получать компенсации ещё четыре года.
Мне не удалось найти хорошие оригинальные источники этих данных. В отчёте PayScale за 2013 год говорится о том, что медианная текучка в Google составляет 1,1 года; мне кажется, что это слишком мало.
Многие разработчики в крупных технологических компаниях непродуктивны, но это уже тема для отдельного поста. Я не хочу вдаваться в эту тему по двум причинам. Во-первых, я считаю, что даже компетентные разработчики создают плохой код, поэтому можно ограничиться только ими. Во-вторых, даже если код написал некомпетентный разработчик, его почти всегда проверяют компетентные, и вопрос о том, почему этого не произошло, по-прежнему интересен.
Здесь я имел в виду не недавний пример GitHub Actions, с которым я напрямую не соприкасался. Мне припоминаются как минимум десять примеров, которые были связаны непосредственно со мной.
На мой взгляд, причина этого в основном в нехватке воображения: представлении, что твоя рабочая среда сильно похожа на все остальные.
Комментарии (47)
LinkToOS
08.12.2025 13:44Довольно высокий процент изменений вносится «новичками»: людьми, которые пришли в компанию, перешли к этой кодовой базе или даже на новый язык программирования за последние шесть месяцев.
Если человек пришел на новое место, но еще толком не изучил проект, и не имеет большого опыта программирования на языке который используется в этом проекте, то можно ли его называть "хорошим разработчиком" в этот момент? Даже если он был хорошим разработчиком на предыдущем месте.
vvbob
08.12.2025 13:44Пришел ты весь такой хороший в проект. Открываешь код и видишь огромную кучу воняющего нечто.. При этом на тебя постоянно давят что "как-то долго ты вкатываешься, давай уже приноси пользу проекту", и наваливают на тебя гору дедлайнов. Приводить эту кучу в порядок нет ни сил, ни времени, да и желания, чего уж, обычно там не что-то прикольное из разряда запуска ракет к Марсу, а какое-либо унылое Г по выдаче кредитов каким-либо дурачкам, готовым платить дико завышенные проценты.
Alex_RF
08.12.2025 13:44А какая разница между задач по запуску ракет на Марс и выдачи кредитов? Более того ракету запустили и можно про ту программу забыть, а кредиты по той программе будут выдаваться лет 10, если не более. Вот и приходишь - а там сидит сварливая женщина, у которой, 20 лет назад программисты на гору по 2 задачи в день делали. Что там в этих задачах была, ей просто не ведомо, так как не ее это код писать. А сейчас не те программисты пошли, она их как рентгеном видит, все хотят на теплое место и деньги получать. Но она на страже - всех саботажников определит. В общем в лучшим случае народ пробел ставит и commit делает, с переводом в статус "решено", а могут с помощью ИИ кучу кода, который не чего не делает поставить или вообще не обратить внимание, что соседний функционал сломается заплатку на скорую поставить, и так вместо полдня, целый день на дебаг потратил. Какое приведение в порядок. Есть мысли после испытательного срока, но его проходят единицы.
vvbob
08.12.2025 13:44А какая разница между задач по запуску ракет на Марс и выдачи кредитов?
Вопрос такой.. вроде и простой и сложный одновременно. С точки зрения сложности решаемых задач первая может даже и проще оказаться чем какой-либо хитрый софт по впариванию кредитов. Тут скорее субъективщина. Очень многим людям далеко не все равно на что они тратят годы своей жизни, и им куда как приятнее думать что они делают пускай и скромный, но все-же реальный вклад в развитие человечества, в освоение нашей солнечной системы. На другом полюсе - годы жизни потраченной на то, что-бы владелец какой-либо МФО более ловко одурачивал наивных лохов и получил с них больше прибыли.
Чаще всего, конечно, встречается что-то между этими крайностями, вроде и не МФО, а "солидный банк", который откровенным мошенничеством не занимается, но удовольствие от таких проектов получить тоже сложновато как-то..
Есть люди, которым все равно чем заниматься, лишь бы деньги платили, есть те, кому не все равно. Впрочем, те кому все равно, обычно им и на качество кода так-же все равно. Ну лежит там "под капотом" отвратительно воняющая куча дерьма, но она как-то там работает? Деньги за ее поддержку тебе платят? Ну и отлично все!
Alex_RF
08.12.2025 13:44Это очень философский вопрос. Банк платит налоги, которые идут в том числе на финансирование полетов на Марс. Или позволяет аккумулировать деньги для реализаций различных проектов - в том числе строительство жилья. Это сейчас какие-то не разумные проценты, но когда-то много народу в ипотеку (кредит) купили себе жилье, замечу себе! Хотя, жить с родителями или снимать квартиру, для того что бы писать программы запуска кораблей на Марс - то же хорошая дело. Но проблема не в этом. Проблема в том - что бизнес заставляет писать быстро и не качественно.
vvbob
08.12.2025 13:44Да, потому я и начал с того что вопрос не простой.
Однако, вот заметьте, в случае с банком приходится себя уговаривать и притягивать налоги и функции банка как аккумулятора, цепочка рассуждений длинноватая получается, сложнее себя убедить что занимаешься чем-то полезным не только для владельца бизнеса и себя лично в качестве наемного работника, и все равно где-то в душе остается ощущение что ты просто сам себя уговорил. Я это по своему опыту воспроизвожу, так и не смог работать в банке, не уговорил, хотя тоже что-то похожее думал.
Zalechi
08.12.2025 13:44Когда ты в авангарде строишь ракеты — это немного другое, чем когда ты помогаешь косвено:
https://habr.com/ru/companies/ruvds/articles/974452/#comment_29229802
Daddy_Cool
08.12.2025 13:44Вы сейчас транслируете свои ценности. Роскосмос и SpaceX уже ждут ваше резюме!
Кто-то скажет - софт для кредитов - это понятная и нужная штука, а ваш рокет-саенс - блажь!
Кто-то скажет - мне просто нравится программировать. Когда буковки на экране начинают делать что-то осмысленное - это магия!
Есть просто ответственные люди, которые к тому же хорошо осознают личные цели - и они хотят денег, отсутствия стресса, наличие свободного времени и т.п... разве они хотят слишком многого?
(Я сам занимаюсь наукой и всё это очень хорошо понимаю).vvbob
08.12.2025 13:44Так я вроде достаточно подробно и понятно все расписал. Да, это индивидуально все. Но по моим ощущениям это очень распространенная проблема для таких проектов.
Есть просто ответственные люди, которые к тому же хорошо осознают личные цели - и они хотят денег, отсутствия стресса, наличие свободного времени и т.п... разве они хотят слишком многого?
Тут проблема в том что ответственность и дисциплина это хорошо и правильно, но если нет кайфа от такой работы, то его чувством ответственности не заменишь, и это все чувствуется и по коду и в целом по атмосфере в командах на таких проектах. Насчет отсутствия стресса и свободного времени - тут не факт что с этим все хорошо в условных банковских проектах.
Zalechi
08.12.2025 13:44А какая разница между задач по запуску ракет на Марс и выдачи кредитов?
Открывать новые горизонты, гораздо интереснее надоевших дел… натура у нас такая — сапиентная.
BOM
08.12.2025 13:44Если вы считаете, что хороший разработчик становится плохим в новой кодовой базе, то вам следует нанять действительно плохого разработчика на ту же работу и вы будете неприятно удивлены.
Terimoun
08.12.2025 13:44Хороший не тот, кто знает конкретный язык или проект, а тот кто умеет быстро разбираться в новом и принимать адекватные решения в условиях неполной информации. Так что да, можно. Просто его хорошесть будет проявляться не в идеальном коде, а в том что его костыли будут менее страшными, чем у плохого разработчика
mclander
08.12.2025 13:44Я приходя на новое место работы, часто начинал заниматься с фикса багов, до которых не дошли руки других разработчиков. Это даёт очень быстрое погружение в код. Минус - бывает сталкиваешься с формальным или излишне придирчивым ревью. Первое - это как раз приводи к тому, что плодишь костыли (поскольку пока не знаешь, как надо в этом окружении). Второе - это когда вылизываешь то, что в принципе и так неплохо в том числе и с т.з. культуры кода. Но кто-то кому з/п платят не за это доводит до идеального вылизывания, т.е. время уходит не на погружение в проект, а на best of best of the best practices
AlexGorky
08.12.2025 13:44В большой компании (как и в малой) вне зависимости от зарплаты ты можешь или спокойно сидеть и спокойно заниматься разработкой и писать качественный код. Или на тебя могут повесить всё, что можно, включая техподдержку (а фигли, зря что ли ему платим?) и обучение новичков. Ну и тестирование заодно.
Так что нет ничего удивительного.
Dhwtj
08.12.2025 13:44отказываются от определённой величины экспертизы и качества ПО, чтобы получить возможность быстро перебрасывать опытных разработчиков на новую «горящую» задачу.
А если вспомнить, откуда берётся половина горящих задач (от плохой архитектуры и кода, от потери экспертизы, никто не знает программу и бизнес процессы), то попахивает шизофренией.
Текст про классические галеры. А уж на аутстаффинге и подавно.
Но это больше похоже на системный недостаток, чем на best practice. Верно?
unmorsino
08.12.2025 13:44Текст про классические галеры.
в резюме у чувака последние 4 года работа над GitHub Copilot, до этого ZenDesk, не думаю что это можно считать галерами
Terimoun
08.12.2025 13:44Просто разные горизонты планирования. Менеджер, которому нужно "запустить фичу к квартальному отчету", мыслит категорией недель, а последствия в виде техдолга наступят через год, когда он уже будет работать в другом отделе. Для него это локально-оптимальное решение
pravosleva
08.12.2025 13:44Как-то в одной крупной компании я был свидетелем обсуждения недовольства, почему пин-код клиента для входа в приложение хранится в локал-сторадж ("это немыслимо", "что скажут безопасники"...). Но как-то недалеко от релиза я слышу "ребят, давайте запустим уже через месяц, топ-менеджмент ждать не любит". И тут я все понял...
capslocky
08.12.2025 13:44Объяснение от обратного. Вот где реально необходимо писать качественный код? Когда цена необратимой ошибки очень высока: медицинское оборудование, ядро платежных систем, управление самолетом и т.д. И тут есть существенный минус: необходимо много времени на серьезный code review, глубокое тестирование перед релизом. В типичном корпоративном бизнесе все наоборот: скорость доставки на порядок важнее, чем отсутствие проблем в коде или архитектуре. Таким образом, это не является существенной проблемой самого бизнеса.
Yuriy_75
08.12.2025 13:44Те, кто готовы променять скорость доставки на качество кода, через какое-то время оказываются и без скорости доставки.
1) В запутанно-костыльной системе, задача "сделайте это быстро" - дополнительный прессинг на разработчиков.
2) В результате текучка, и получаем новичков на запутанно-костыльной системе без документации. И у новичков сделать что-то быстро (пускай даже костыльно) - уже не выходит.
Собственно, еще одна иллюстрация принципа "скупой платит дважды"
capslocky
08.12.2025 13:44Согласен, я сам разработчик, так всегда и происходит. Только я никого не оправдываю и не обвиняю. Замедление скорости доставки под грузом старой архитектуры и качества кода - это, к сожалению, нормально. Бизнес редко выбирает риск переписывания системы с нуля.
capslocky
08.12.2025 13:44Сделать сразу грамотную архитектуру, писать только качественный код обычно нереально. Настоящие бизнес требования, которые приносят прибыль, находятся только после множества релизов.
Dhwtj
08.12.2025 13:44В типичном корпоративном бизнесе все наоборот: скорость доставки на порядок важнее, чем отсутствие проблем в коде или архитектуре
Что же это за такой типичный "корпоративный бизнес"?
capslocky
08.12.2025 13:44Это практически все случаи, когда кому-то платят деньги за написание кода. В бизнесе компания вынуждена зарабатывать деньги, а расходы на разработку ПО - это большая и серьезная статья расходов, которую она стремится минимизировать. Только корпорации могут себе позволить такие большие затраты.
dragulaxis
08.12.2025 13:44Как говорил Конфуций: "Напиши хороший код, и ты будешь нужен бизнесу пару дней. Напиши плохой код, и ты будешь нужен компании всю жизнь".
ivankoltsov
08.12.2025 13:44так ведь это правильно, потому что поддерживать плохой код кому-то придется, и кому, если не автору этого плохого кода?)
Yago
08.12.2025 13:44Обычно представители бизнеса видят результат, и считают его приемлимым для продажи. А результат для них - это часто обложка приложения, которая всегда красивая и вылизанная. А тот факт, что за обложкой скрывается неподдерживаемое нечто обычно пропускается, т.к. у бизнеса нет в этом экспертизы, а деньги за обложку можно получить уже сегодня.
Бизнес сам ограничен коротким жизненным циклом продукта, и его цели чаще из себя представляют "сделать вчера и желательно бесплатно, чтобы завтра продать за миллионы". Такие условия диктует нестабильная экономика во всем мире.
И когда на этапе MVP разработчики говорят про то, что этот MVP нужно выкинуть и переписать, бизнес переключает их на другие более прибыльные проекты, а на доработку этого MVP ищет уже новую команду поддержки, которая посговорчивее, и еще не насытилась наследием. Таким образом и старые разработчики вроде как заняты и приносят прибыль на новых проектах, и новые разработчики пока не так сильно токсичат ковыряясь в MVP-наследии. А дальше уже исходя из того, какие MVP выстрелили, принимаются решения из разряда от "так уж и быть, выделим бюджет на прическу этого MVP, которое стало нести золотые яйца" до "ну не выстрелило, давайте забудем этот проект как страшный сон".
Самое страшное где-то посередине: когда проект полудохлый и приносит малый доход, бизнес рогом упирается и только пилит фичи, которые не нужны пользователю, а разработка уже эмоционально не выносит внутреннее состояние кода.
Dhwtj
08.12.2025 13:44Выкручивание рук разработчикам, у которых горизонт планирования выше, чем у руководства. Ну вы же понимаете, что это бред.
capslocky
08.12.2025 13:44Именно! Инженерам нужен длинный горизонт планирования, но в бизнесе ситуация постоянно меняется и планы тоже. Бизнесу нужны постоянные эксперименты с фичами, чтобы выжить, а инженер хочет неизменность функциональных требований. Это неизбежное фундаментальное противоречие.
Gradiens
08.12.2025 13:44хорошие разработчики пишут плохой код в больших компаниях
Это норма жизни. И это неплохо. Оно худо-бедно работает и приносит пользу.
Потому что плохие разработчики пишут ужас-ужас-ужас (С), от чего кровь-кишки-[sencored]
ImagineTables
08.12.2025 13:44Думаю, главная причина этого в том, что в больших компаниях куча разработчиков трудится не по своей специализации
“Это правда-истина!” (Cloud Atlas). Помню, в одной крупной компании такой диалог на собесе:
— Вы знаете C#?
— Да!
— А OpenGL?
— Да!!
— А пользовательские интерфейсы писать любите?
— Да!!!
— Выходите в понедельник.В понедельник:
— Вот вам фрезерный станок, надо писать для него управляющий код. Вы, кстати, правша или левша?
— Правша о_О
— Тогда распишитесь в журнале ТБ левой рукой и чаще пользуйтесь ею при тестировании.(Я чуть-чуть изменил детали, но клянусь, что суть осталась неизменной).
Terimoun
08.12.2025 13:44"Медианный продуктивный разработчик... работает в условиях дедлайна" - а разве бывает по другому? Идея о том что где-то существуют компании, где можно месяцами вылизывать код без давления со стороны бизнеса, это миф. Грязная разработка не особенность больших компаний, а нормальное состояние 99% коммерческих проектов
evtomax
08.12.2025 13:44Как-то всё меньше пользы для конечного потребителя от подобной организации экономической деятельности...
grigorym
08.12.2025 13:44Уважаемый переводчик, вы забыли перевести на русский язык некоторые фразы:
спустя четыре года завершается полный вестинг изначального пакета
anzay911
Хорошо быть архитектором в крупных технологических компаниях. Занимаешься своими делами, никто про тебя не вспоминает.
dvb1
Во-первых, про всех помнят. И никакого "спокойно" в любом случае не будет.
Во-вторых, в компаниях про которые идёт речь, традиционно нет архитекторов. Предполагается что там разработчики умные и архитекторы им не нужны.
Мне лично это кажется глупым, но что есть то есть
Ivan22
я работаю как раз архитектором в большой компании. Но честно говоря код-ревью занимаюсь очень редко. Это задача тимлидов. От архитектора требуется нарисовать архитектуру и продать ее бизнесу.
dvb1
Я тоже работаю архитектором в большой компании - market cap > 500 bln
код-ревью занимаюсь примерно никогда потому что у меня 400 разработчиков на разных продуктах, и делать ревью физически невозможно.
Но в компаниях, про которые идёт речь, архитекторов нет, так что те, кто правят код, не в курсе какая там архитектура
Zalechi
Как по мне, не в архитекторах и разработчиках проблема (судя по заголовку статьи), а в бизнесе и маркетологах с их дедлайнами и идеями на милльон.
dvb1
Проблема не в том, что разработчики плохие, а в том, что их кидают с одного проекта на другой
Zalechi
В бизнес процессах проблема.
vvzvlad
Проблема в том, что бизнес-процессы в вашей голове отличаются от реальных
Zalechi
И так и сяк — во круг да около, как не крути.