Почему говнокод — это норма: объясняют опытные кодеры
Спросили у разработчиков, кто из них мог бы открыто признаться, что пишет говнокод — и почти собрали стадион.
Спросили у разработчиков, кто из них мог бы открыто признаться, что пишет говнокод — и почти собрали стадион.
«Говнокод — не патология, а норма» — говорят они. Ну или для кого-то «почти норма».
Рекрутер пожаловалась в линкедине, что кандидата, на которого она сделала ставку, — отвергли, потому что он «большую часть времени работал в стартапах». Для нанимающего менеджера это — red flag, так как в стартапах всё собирают дешёво и быстро «из г… и палок». В комментариях — дискуссия: кто-то согласен, а кто-то, наоборот, говорит, что в крупных компаниях говнокода больше.
Спросили у комьюнити: грязный код — это ок?
Виктор начал работать программистом ещё в 1995 году, сейчас — консультант в ИТ. Он вызвался выступить «адвокатом дьявола»:
— Говнокод не просто «бывает», это в индустрии — норма. А вот красивый код — скорее, исключение из правил. И так и должно быть.
Объясню, почему. Но прежде сделаю оговорку: говнокод — это не про «руки не из того места» и не про квалификацию. Работающий говнокод пишут все — и стаффы принципалы и джуны. Потому что говнокод ограничен прежде всего временем. Если вам надо «завтра или никогда», то вы будете писать, как быстрее, а не красивые абстракции и вычисления типов.
В сущности, единственная область, где красивый код в приоритете — это open source.
Да, мы помним: говнокод — это издержки на модификацию и развитие, и весьма часто его приходится выбрасывать целиком и заменять таким же, но другим… говнокодом. И вот это и даёт нам ключ к пониманию.
Мы все стараемся писать красивый и поддерживаемый код, и все практики построены на том, чтобы код не был говнокодом. Но всё в мире стоит денег.
Поэтому истинное искусство программирования и состоит в тонком балансе между простотой, понятностью и красотой кода, между издержками «сегодня» и издержками «завтра». Между корпоративными процессами и «херак-херак — и в продакшен».
Выбор делает тот, кто распоряжается деньгами, даже если он не делает этот выбор и идет на поводу у команды.
Приведу несколько примеров. В моей практике были очень смешные случаи, когда быстрый говнокод делался за три вечера одним сеньором и решал бизнес-задачу. А потом три месяца целая команда из 6 человек по процессам делала то же самое, с аджайлом, спринтами, покрытием тестами, документированием… И все это время быстрый говнокод «держал продакшн».
И нет — у всех причастных не случилось помутнение рассудка, как кто-то мог бы подумать. Просто крупный бизнес оказался брать на баланс говнокод — потому что тогда придётся нанять его автора. А на суппорт Greater Chennai Area нужно было передать железобетонную конструкцию, которую при всем желании местные джуны не смогут быстро сломать.
Или вот ещё пример: команда из ~12 инженеров, плюс менеджер и QA, писала лютейший говнокод в течение целой пятилетки.
Текучка в команде была неимоверная, потому что клиент был очень недоволен результатом — но не настолько, чтобы сменить поставщика услуг (да, так бывает). В результате, никто из команды не понимал, как это работает — и все занимались только наматыванием «костылей» к предыдущим «костылям» в режиме 24/7.
Я сам, собственно, и есть тот консультант из второго примера. И мне тоже, к сожалению, иногда приходится писать говнокод — видимо, такова специфика работы: ко мне обращаются, когда уже «всё горит». Но опыт позволяет делать модно, молодежно, в тренде, и даже с тестами (нет, unit tests как правило не делаю, разве что чуть-чуть, а вот интеграционные — почти всегда).
Может ли за говнокод прилететь — может да, а может и нет, зависит от обстоятельств. Порой клиенту это неважно, а иногда даже при отсутствии проблем он устраивает ревью, которое длится раза в три дольше, чем писался сам код.
Бывает и так, что я специально подсовываю немножко говнокода — и ненавязчиво показываю его клиенту: пока он сражается с названиями переменных, ему неинтересны сомнительные архитектурные решения, которые идут «в комплекте».
Хотя больше всего я люблю open source — вот тут реально есть запрос на хороший код.
Сергей говорит про себя: «я — сеньор, но всё же пишу говнокод, потому что я разрабатываю на Lua и JavaScript, а там по-другому нельзя».
— Говнокод — это норма, а не патология, и он есть везде — и в крупных компаниях, и в небольших стартапах (но больше там, где не следят за чистой кода).
Сергей оговаривается, что старается следить за чистой кода, и другим указывает на ошибки, если видит.
— Понятно, что приложение будет работать и на говнокоде — и, вероятно, даже хорошо. Но вот поддержка с каждой его строкой будет становиться всё хуже и хуже, что, потенциально, влечёт за собой проблемы.
Фулстек-разработчик на JS\TS и Python Алесь (в профессии с 2021 года) сравнивает написание кода с работой художника:
Алесь вот уже несколько лет менторит студентов на бесплатном курсе. Он говорит, что видел десятки проектов начинающих разработчиков, однако говнокода там немного.
— Как правило он — у студентов с низкой базой, пишущих по принципу: «работает, и ладно».
В жизни говнокода больше там, где плохо организована работа: постоянно меняется ТЗ, сроки — неадекватные, рефакторинг отсутствует, и есть ощутимый недостаток квалифицированного персонала или малое участие в ревью кода. Ну и да, бывает, что код пишется так: «лишь бы прошёл тесты» — и потом ты узнаёшь, что программист устал, есть проблемы в коллективе или вне его (например, со здоровьем).
Что обычно называют словом «говнокод» — когда задачи решены неоптимально, алгоритмы запутаны, и всё это сложно поддерживать новому разработчику. Но в большинстве языков код обрабатывается компилятором или интерпретатором, и не факт что после этого он всё ещё будет плох (проблем производительности это конечно не исправит, но всё остальное — вполне).
И да, неслучайно успешные стартаперы советуют новичкам: делайте так, чтобы приложение просто работало, — а когда ваш стартап взлетит, наводите красоту в коде.
Считаю ли я себя говнокодером — да, и по моим наблюдениям, это показатель того, что с тобой всё нормально. Сегодня ты видишь задачу таким образом, пишешь код, чтобы её выполнить, тестируешь — и довольный результатом переходишь к другой задаче. А через месяц смотришь на этот код и не можешь поверить, что ты мог такое написать, и думаешь, что лучше было сделать по-другому.
Ещё раз повторю: написание кода — это творчество в чистом виде, одной правды тут никогда нет.
Олег — .NET-разработчик с 6 годами опыта. И тоже признаётся, что ему «иногда приходится» писать говнокод:
— Например, если в процессе релиза на прод выскакивает неожиданный баг, то порой нет времени на долгие раздумья — «вкорячиваешь» костыль, и всё работает. Главное — это дело обмазать todo-комментом, чтобы коллеги потом не съели заживо.
Часто без говнокода просто не обойтись, потому что у бизнеса есть свои цели — и он к ним идет любой ценой, но… не ценой времени. Заказчику плевать, что какие-то части системы ещё не переехали на новые рельсы и живут себе спокойно в легаси. Сделай задачу к концу спринта, а лучше — «вчера».
И если тебе приходится натягивать сову на глобус и скрещивать новые сервисы с легаси-системой — «запиши это в техдолг, чтобы потом сделать» (нет!). Отмечу, что сам код может выглядеть неплохо и быть вполне читаемым, но при этом на верхних уровнях рушить все зависимости, смачно харкая на схемы и диаграммы, нарисованные солюшен-архитектором.
И ещё перефразирую пословицу: если кто-то говорит, что он не пишет говнокод, будьте уверены — он делает это даже больше, чем остальные.
Вот, кстати, только что я «вкорячил» ещё один костыль в код.
Андрей — Java-программист с 15-летним стажем. «Говнокодером» себя не считает, наоборот, он — перфекционист. И при этом признаёт, что говнокод — «как мат в обычной речи: без него можно обойтись, но бывают ситуации, когда с ним проще».
— В начале карьеры слышал в свой адрес упрёк: «говнокодер» — а сейчас уже некому такое мне сказать. Но, глядя на свой код 2-4-летней давности очень часто говорю: это полный говнокод, можно было сделать лаконичнее и правильнее.
Чаще всего к говнокоду ведёт:
В стартапе может быть маленькая мотивированная команда с парой опытных программистов, которые вроде бы должны писать не говнокод, — но в угоду быстрому старту проекта делают часть задач низкоприоритетными. А в большой компании, возможно, даже есть большие требования к code-style, но вовлеченность исполнителей — слабая, и они нередко говнокодят.
Я ставлю на то, что в продуктовых компаниях говнокода по естественным причинам меньше. Однако добавлю, что он есть во всех сферах, в том числе вне ИТ — только названия у таких продуктов соответствующего качества другие.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Автор один из тех кто понял устройство вселенной :)
Джун пишет связанный говнокод.
Техникал лид делает простую архитектуру которая заставляет всех писать не связанный говнокод.
"ваше полное покрытие юнит тестами — это время, не потраченное на написание полезного бизнес-кода, это большие издержки" - сэкономил время на пару тестов и ковыряешься ночью всей командой в продакшне, вот так экономия времени.
Советую поднять скилы всей команде, если отсутствие пары тестов приводят к ковырянию ночью всей командой в продакшне. Тут проблемы и с QA, и с организацией деплоя, и с уровнем разрабов. Юнит тесты эти проблемы не исправят, увы.
Вы правы. Тут уже комплексная проблема, когда прод отваливается.
Покрытие же тестами на бэке решает проблему сопровождения кода и дальнейшей разработки. Экономит время разрабов и тестеров на последующих этапах жизни проекта, уменьшает количество итераций между ними. Иначе возникают такие странные советы, что если говнокод работает, то лучше не трогать и что нельзя так просто взять и пофиксить.
Нет. Еще один человек с маленьким опытом разработки. Время не уменьшается! Это детская чушь! Тем более, юнит тесты на бекенде. При чем тут количество итераций к юнит тестам?
Это возникает вне зависимости от наличия юнит тестов. В случае говнокода и наличия тестов на бекенде, тебе придется еще и переписывать тесты, покрывающие говнокод. Азатот, это же очевидно...
Запомни, джун, зачем нужны юнит тесты:
-- Когда у вас не строгая типизация (что уже вопрос, почему для серьезного проекта (а в несерьезных тесты по умолчанию не нужны) выбран язык без строгой типизации)
-- Когда заказчик готов оплачивать 1.5-3 раза больше, что бы избежать даже малейшие возможные ошибки (медицинский софт, алготрейдинг). Но если не готов, то и без них работается.
-- Если время жизни софта планируется на 15+ лет (банковский ентерпрайз)- тесты помогут обнаружить ошибки при смене мажорных версий библиотек/языка.
-- TDD
Может и больше, но это то с чем лично сталкивался.
Забей себе в голову следующее:
ВРЕМЯ РАЗРАБОТКИ НЕ ЭКОНОМИТСЯ НИ НА ОДНОМ ИЗ ЭТАПОВ! Обратное это непонятно от какого-то инфоцыгана бред, время разработки с тестами ВСЕГДА больше разработки без тестов.
Пользователь отредактировал комментарий 28 апреля 2024, 12:42
Маленький опыт как раз у вас. И тесты бывают не только юнит
Не видел ещё чтоб юнит-тесты реально спасали продакшн хоть раз. Обычно это просто дублированние кода в тестах ради красивых метрик.
Давайте я вам расскаху за отсутствие тестов, на реальном примере.
Жил был легаси без покрытия, ну так на то он и легаси. Написать и поддерживать тесты стоило (даже без 100% coverage) ~$50k.
Лет через пять после апгрейда на новые версии фреймворков прод успешно сдох, так обычно и бывает. Овертайм пары лидов на выходных обошелся в $5k.
Бизнес, глядя на непотраченные 45 000 USD, смотрит на вас с ленинским прищуром ;-)
https://media0.giphy.com/media/11mwI67GLeMvgA/giphy.gif
Пользователь отредактировал комментарий 30 апреля 2024, 14:17
повезло :)
А могла бы база с финансовыми транзакциями закорраптиться.
Ну и обычно пока система лежит два дня, пользователи не могут войти, бизнес терпит убытки.
О, кстати, про транзакции. Жила была огромная контора, с такими же клиентами. Проект вместе с транзакциями передали на сопровождение очень дещевым индусам... и через полгода сервак с деньгами сдох.
Бэкап последний раз делали во время трансфера проекта.
Ииии знаете что? А ничего, индусов похвалили, за то что они неделю собирали базу из кусочков, перед клиентами за потери транзакций извинились.
И все.
А, и еще пара мидл-менагеров не получили квартальный бонус, во.
Когда вам рассказывают про бизнес-критикал, "нужно вчера", "breach the contract" и прочие ужасы эти самые мидл-менагеры, знайте - они рассказывают вам это только для того, чтобы получить свою премию.
Исключения - редки.
Говнокод слишком абстрактное понятие.
Хороший код - максимально простой и понятный код для решения конкретной задачи (с учётом специфики проекта).
Чтобы научиться писать простой код, нужно много поработать с избыточно сложным.
Понимание необходимого качества кода на данном этапе проекта приходит с опытом.
Избыточная сложность решения (паттерны и обобщения "на будущее") так же плоха, как и спагетти.
Неспособность писать простой и понятный код, как правило, никак не связана с временными ограничениями. Такие люди при любых условиях дают тупые именования и не умеют делать базовую декомпозицию.
Отсутствие оптимизаций в коде зачастую обусловлено временными ограничениями. Но достаточно прогнозируемо исправляется выделением доп. времени.
Нытьё уровня "везде говнокод, нужно рефакторить" не может быть исправлено выделением времени на рефакторинг, так как чаще всего ноющие не могут дать оценку и не представляют финальный результат.
Пользователь отредактировал комментарий 27 апреля 2024, 16:40
Это что, 10 заповедей?
В целом разделяю мнение, хотя оно тоже абстрактное (избыточная сложность, необходимое качество, хороший код). Рефакторить приходится. Эстимация не всегда правильная, а у релиза дедлайн. Усугубляет еще и социализм. Дев может и порефакторил спагетти, если бы ему пришлось возвращаться к данному коду. Но современная парадигма разработки подразумевает взаимозаменяемость, надо лазить по всему коду и не утопать в деталях.
олдфаги пишут юниттесты без копайлота, они еще и камни в поле руками собирают
LOL!
Как раз в опенсурсе и встречается самый лютый говнокод который я только видел.
Это как раз разумный подход. Надо было быстро найти работающее решение, а потом, когда уже обкатанная логика - пишется чистовая её имплементация.
Есть такое, даже после 20+ лет непрерывного опыта смотришь на свой же старый, уже забытый код, свежим взглядом и видишь места, где можно улучшить.
Плохо смотрели.
А соклько вы видели закрытых проектов? 10? ну 20? какраз комерческий софт и есть полное г, потому что каждый васян переизобретает один и тот-же кривой велосипед потому что нормальный алгоритм не может использовать из за всяких лицензий и прочей чепухи. Закрытого нормального софта единицы. И тот построен в большинстве на открытом, где лицензия позволяет.
Код - это искусство. Это как картина, поэма, сонет. Если писать произведение в тесной кавалерке на сухом пайке из костей, конечно же выйдет гамнакод. Поэтому IT было, есть и будет в Беларуси. Сытый поэт(программист) всегда сделает продукт лучше, чем его коллега, который все время думает, где бы достать денег на оплату очередного месяца панской кавалерки.
Комментарий скрыт за нарушение правил комментирования.
[censored - П. 4.1.2. Пользовательского соглашения — https://devby.io/pages/polzovatelskoe-soglashenie]
Комментарий скрыт за нарушение правил комментирования.
[censored - П. 4.1.2. Пользовательского соглашения — https://devby.io/pages/polzovatelskoe-soglashenie]
Комментарий скрыт за нарушение правил комментирования.
[censored - П. 4.1.2. Пользовательского соглашения — https://devby.io/pages/polzovatelskoe-soglashenie]
Чувствую, как от твоей пылающей ж*пы эуропка решает своей энергетический кризис🤣🤣
Большенство кода никогда не увидит свет продакшн. Зачем напрягаться?
Если фрагмент окажется успешным то позже можно переписать.
Так сама природа велела, см. закон Парето или 20-80.
Комментарий скрыт за нарушение правил комментирования.
[censored - П. 4.1.2. Пользовательского соглашения — https://devby.io/pages/polzovatelskoe-soglashenie]
Понятие "говнокод" довольно расплывчатое, каждый под этим понимает что-то свое)
Код не только пишется, но потом еще и читается (в т.ч. другими людьми, вашими коллегами или еще кем) и дебагится. Если индийцам когда-то по легендам платили за строки кода, то сейчас нередко видимо бывает суровая экономия текста, и за лишнуюю строку бьют по рукам. Поэтому встречается код типа Rechtsschutzversicherungsgesellschaften, т.е. где в одну строку через точки и стрелки идет какой-то паровозик. Ибо раз за строки кода не платят, то и нефиг. И лишную локальную промежуточную переменную завести - жалко стека. А дебагить потом who cares. Зато эффективно)
Ахаха. Гавнокодеры защищают гавнокод.
Да, гавнокод к сожалению это обыденность сейчас, но не есть номра.
Говнокодеры утешают себя, что это нормально