Сеньоры специально пишут запутанный код, чтобы стать незаменимыми? Дискуссия в Threads
В Threads обсуждают, правда ли, что некоторые разработчики специально пишут запутанный код без каких-либо комментариев, чтобы стать незаменимыми на проекте.
В Threads обсуждают, правда ли, что некоторые разработчики специально пишут запутанный код без каких-либо комментариев, чтобы стать незаменимыми на проекте.
Топикстартер поделился мыслью: он вдруг понял, что среди сеньоров распространена практика — они не пишут понятный код и не снабжают его комментариями, чтобы со временем стать незаменимыми на проекте.
— Один коллега за 3 года получил четыре повышения и +210% к зарплате. «Только он понимает эти системы». Два разработчика, пытавшиеся разобраться в его коде, уволились. По моим наблюдениям, так делают около 30% опытных разрабов.
Комментаторы, как это обычно бывает, разделились на два лагеря.
Первые соглашаются: всё так.
— Видел такие проекты, как правило там имеется человек, за которым последнее слово — и это его/её влияние. Пока этот человек на проекте, исправить код на читаемый и поддерживаемый не дадут, если это не исходит от того, кто выше по иерархии. Тоже, кажется, что так они пытаются сделаться незаменимыми.
— Дважды приходил на такие проекты и говорил с руководством. И дважды мне давали понять, что всех всё устраивает. На обоих проектах большую часть переписал по-человечески, вводил какие-то практики, однако меня там нет, а эти «присосавшиеся», скорее всего, и сейчас там.
Кто-то накидывает ещё несколько приёмов и трюков «их выживания». «Например, дробят собственные задачи на нано-подзадачи, а новичкам в команде сбрасывают тяжёлые комплексные таски, чтобы потом в отчёте показать бóльшую производительность, а значит и ценность в глазах микроменеджмента.
Или на встречах отвешивают комментарии к задачам новичков из серии: «Да это очень просто», а свои микро-таски мучают месяцами, выдумывая проблемы, т. к. им легко верят из-за их опыта работы с конкретным клиентским кодом.
Вторые удивлены: они никогда «с подобным не сталкивались». И в целом не понимают, как можно так работать, если существует код-ревью.
Кто-то полагает, что запутанный код — следствие «сжатых сроков и/или халатности/низкой квалификации разработчика». А кто-то пишет, что сам такой разработчик — но всё непреднамеренно: «так автоматически получается. Ещё и документации ноль. А потом совесть не позволяет уволиться…»
— Какие-то сказки! Обычно за непонятный код увольняют, а если нет процесса код-ревью, то это шарага какая-то.
— …Это очень опасный человек для бизнеса: так можно погубить продукт вовсе, придется всё переделывать.
Здесь же, кстати, развернулась небольшая дискуссия на тему, а как люди, которые намеренно запутывают свой код, чтобы задержаться в компании и стать в ней незаменимыми, избегают код-ревью, и где вообще такие водятся.
— Хитрость, наверное, в том, что эти ребята мастерски избегают код-ревью: «срочно в продакшн», «потом задокументирую»…
— …Либо в компании нет процессов, либо наоборот уже бюрократический ад. Поэтому такие отлично сидят либо в мелких шарагах, либо в гигантском бигтехе. В первом случае они «как бы незаменимы», во втором хрен доберёшься до них через все процессы.
Ещё под постом отметились те, кто в целом согласен, но мириться с подобным не готов — особенно если это коснулось их напрямую.
— Мне как раз достался такой код, когда я перешла в новую компанию. Сам автор кода отказывался его комментировать или помогать мне разобраться с ним, т. к. у него «не было времени». Я 2 недели мучалась, эскалировала проблему, пробовала за ним бегать — парень хитрил, как мог. Так вот я разозлилась и написала с нуля новый код, с документацией.
Я в той компании уже 3 года не работаю, недавно встретила бывшего коллегу, он мне сказал: так классно ты тот функционал написала, мы его до сих пор юзаем.
— Нечем гордиться, потому что в один прекрасный момент никто не будет разбираться — просто перепишут этот функционал с нуля, с участием код-ревью, документирования, внедрением стандартов и прочего. Или самого же разработчика заставят переписывать.
Опытные наоборот стремятся чтобы код был понятным, оптимальным и легко читаемым любым разработчиком. Я сам переписывал с нуля проекты, в которых чёрт ногу сломает.
А у вас есть/были такие коллеги? И как считаете — это распространённое явление или всё же нет? Пишите в комментариях.
Почему говнокод — это норма: объясняют опытные кодеры
Почему говнокод — это норма: объясняют опытные кодеры
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Сеньоры пишут специально сложный код, чтоб джуниоры, которых продали, как мидлов, ничего не понимали?неужели поэтому?!😱 это чудовищно. Гребаные скуфы-миллениалы👻
А если индусы тоже так делают, чтоб сохранить места, а не потому что... 🤔
Пользователь отредактировал комментарий 4 марта 2025, 21:03
Не видел ни одного человека который бы писал "сложный" для "незаменимости".
Исходя из моего опыта есть 2 причины почему люди переусложняют
90% случаев - недостаточная квалификация. Как следствие - попытки сделать так, не работает, переделать так по-быстрому чтобы не заругали. В результате мусор в коде и ДАЛЕКО не оптимальное решение. 10% - Особенности мышления. И талантливый человек может слишком далеко и наперед закинуть архитектуру системы под какие то "будущие требования" и наворотить лишнего прямо здесь и сейчас.
Пользователь отредактировал комментарий 5 марта 2025, 01:53
Не чаще, чем джуны/мидлы пытаются всё "переписать с нуля с документацией и комментариями", чтобы казаться умнее. И тех и других хватает.
Пользователь отредактировал комментарий 5 марта 2025, 07:31
Встречался с двумя причинами усложнения кода.
Низкая квалификация, получается не сложный, а избыточный и не оптимальный код. Высокая квалификация. В код закладывается, не всегда очевидная на данном этапе разработки, возможность дальнейшего масштабирования.
Что бы кто то специально усложнял, я за два десятка лет не встречал, хотя успел руку приложить и к достаточно сложным проектам.
И кстати, комментариями в коде загонялся когда был совсем молод и глуп. Нормальный код сам по себе читается как книга, а плохой и комментарии не особо помогут понять.
Сейчас AI откомментирует любой код практически ничем не хуже кодера, и даст подробные объяснения на уточняющие вопросы. Только с архитектурными вещами будут проблемы.
Лучше быть заменимым и менять работу почаще, делая прибавки по 10-20%. В пределах разумного разумеется - каждые 2-3 года например.
Это прибавки которые позволят вам только лишь, оставаться на уровне инфляции.
Тут вообще затронули больше тем, чем просто нечитаемый код.
Хороший код вопрос опыта.
Люди с отговорками когда бизнеса всё устраивает или они не на своём месте. Так как бывает и медленные процессы разработки и поддержки. И бывает что человек работает чисто за деньги, а не для результата.
Бред, конечно. Сложный код возникает только когда разработчик является слабым архитектором или когда пользователи накидали лишних требований. Что-то усложнять в нашей работе нет смысла. Она у нас и так сложная.