Почему говнокод — это норма: объясняют опытные кодеры
Спросили у разработчиков, кто из них мог бы открыто признаться, что пишет говнокод — и почти собрали стадион.
«Говнокод — не патология, а норма» — говорят они. Ну или для кого-то «почти норма».
Рекрутер пожаловалась в линкедине, что кандидата, на которого она сделала ставку, — отвергли, потому что он «большую часть времени работал в стартапах». Для нанимающего менеджера это — red flag, так как в стартапах всё собирают дешёво и быстро «из г… и палок». В комментариях — дискуссия: кто-то согласен, а кто-то, наоборот, говорит, что в крупных компаниях говнокода больше.
Спросили у комьюнити: грязный код — это ок?
«Команда наняла консультанта — и он за три месяца написал новый вариант говнокода»
Виктор начал работать программистом ещё в 1995 году, сейчас — консультант в ИТ. Он вызвался выступить «адвокатом дьявола»:
— Говнокод не просто «бывает», это в индустрии — норма. А вот красивый код — скорее, исключение из правил. И так и должно быть.
Объясню, почему. Но прежде сделаю оговорку: говнокод — это не про «руки не из того места» и не про квалификацию. Работающий говнокод пишут все — и стаффы принципалы и джуны. Потому что говнокод ограничен прежде всего временем. Если вам надо «завтра или никогда», то вы будете писать, как быстрее, а не красивые абстракции и вычисления типов.
В сущности, единственная область, где красивый код в приоритете — это open source.
Да, мы помним: говнокод — это издержки на модификацию и развитие, и весьма часто его приходится выбрасывать целиком и заменять таким же, но другим… говнокодом. И вот это и даёт нам ключ к пониманию.
Если вы не планируете менять что-то вот в этом конкретном месте — то именно здесь говнокод разумен, эффективен и полезнее красивого кода (потому что дешевле). А если планируете — то наоборот.
Мы все стараемся писать красивый и поддерживаемый код, и все практики построены на том, чтобы код не был говнокодом. Но всё в мире стоит денег.
- И ваш лид, который полдня ревьюил код, ровно те же полдня не писал код сам — это издержки.
- Ваше полное покрытие юнит тестами — это время, не потраченное на написание полезного бизнес-кода, это большие издержки.
Поэтому истинное искусство программирования и состоит в тонком балансе между простотой, понятностью и красотой кода, между издержками «сегодня» и издержками «завтра». Между корпоративными процессами и «херак-херак — и в продакшен».
Выбор делает тот, кто распоряжается деньгами, даже если он не делает этот выбор и идет на поводу у команды.
Приведу несколько примеров. В моей практике были очень смешные случаи, когда быстрый говнокод делался за три вечера одним сеньором и решал бизнес-задачу. А потом три месяца целая команда из 6 человек по процессам делала то же самое, с аджайлом, спринтами, покрытием тестами, документированием… И все это время быстрый говнокод «держал продакшн».
И нет — у всех причастных не случилось помутнение рассудка, как кто-то мог бы подумать. Просто крупный бизнес оказался брать на баланс говнокод — потому что тогда придётся нанять его автора. А на суппорт Greater Chennai Area нужно было передать железобетонную конструкцию, которую при всем желании местные джуны не смогут быстро сломать.
Вот поэтому клиент и получил: а) быстрое решение, закрывшее его нужды и б) точно такое же решение, делающее то же самое, но — которое дешёвые суппортеры не сразу сломают. В тех обстоятельствах это было лучшим решением из всех возможных на тот момент. Отдельно добавлю, что оба решения делались в одной комнате.
Или вот ещё пример: команда из ~12 инженеров, плюс менеджер и QA, писала лютейший говнокод в течение целой пятилетки.
Текучка в команде была неимоверная, потому что клиент был очень недоволен результатом — но не настолько, чтобы сменить поставщика услуг (да, так бывает). В результате, никто из команды не понимал, как это работает — и все занимались только наматыванием «костылей» к предыдущим «костылям» в режиме 24/7.
Чтобы вы понимали, как глубока кроличья нора, приведу пример с генерацией отчёта: исправить собственно генератор никто не решался, поэтому после генерации запускался набор regexps — чтобы «переделать по-новому то, что генерится по-старому». Потом появился новый набор, исправляющий аналогичным способом результат работы предыдущего «костыля»… И так несколько раз!
В итоге, команда наняла консультанта (через дорогу) — и он за три месяца написал новый вариант говнокода, который делал всё то же самое без «костылей» и примерно на порядок быстрее по скорости. После чего новый говнокод тихонечко внедрили вместо старого, и команда принялась развлекаться уже с новой базой.
Я сам, собственно, и есть тот консультант из второго примера. И мне тоже, к сожалению, иногда приходится писать говнокод — видимо, такова специфика работы: ко мне обращаются, когда уже «всё горит». Но опыт позволяет делать модно, молодежно, в тренде, и даже с тестами (нет, unit tests как правило не делаю, разве что чуть-чуть, а вот интеграционные — почти всегда).
Может ли за говнокод прилететь — может да, а может и нет, зависит от обстоятельств. Порой клиенту это неважно, а иногда даже при отсутствии проблем он устраивает ревью, которое длится раза в три дольше, чем писался сам код.
Бывает и так, что я специально подсовываю немножко говнокода — и ненавязчиво показываю его клиенту: пока он сражается с названиями переменных, ему неинтересны сомнительные архитектурные решения, которые идут «в комплекте».
Хотя больше всего я люблю open source — вот тут реально есть запрос на хороший код.
«Говнокод — норма, а не патология, он есть везде — и в крупных компаниях, и в стартапах»
Сергей говорит про себя: «я — сеньор, но всё же пишу говнокод, потому что я разрабатываю на Lua и JavaScript, а там по-другому нельзя».
— Говнокод — это норма, а не патология, и он есть везде — и в крупных компаниях, и в небольших стартапах (но больше там, где не следят за чистой кода).
Сергей оговаривается, что старается следить за чистой кода, и другим указывает на ошибки, если видит.
— Понятно, что приложение будет работать и на говнокоде — и, вероятно, даже хорошо. Но вот поддержка с каждой его строкой будет становиться всё хуже и хуже, что, потенциально, влечёт за собой проблемы.
«Для кого-то и черновой набросок — отличное работающее решение»
Фулстек-разработчик на JS\TS и Python Алесь (в профессии с 2021 года) сравнивает написание кода с работой художника:
— Как и в любом творчестве, всё начинается с наброска — и после нескольких итераций код может превратиться в шедевр. Но для кого-то и черновой набросок — отличное работающее решение. Иногда нет времени делать красиво, нужно «вчера». А разработчик с плохой базой не знает, что можно бы сделать лучше и по-другому.
Алесь вот уже несколько лет менторит студентов на бесплатном курсе. Он говорит, что видел десятки проектов начинающих разработчиков, однако говнокода там немного.
— Как правило он — у студентов с низкой базой, пишущих по принципу: «работает, и ладно».
В жизни говнокода больше там, где плохо организована работа: постоянно меняется ТЗ, сроки — неадекватные, рефакторинг отсутствует, и есть ощутимый недостаток квалифицированного персонала или малое участие в ревью кода. Ну и да, бывает, что код пишется так: «лишь бы прошёл тесты» — и потом ты узнаёшь, что программист устал, есть проблемы в коллективе или вне его (например, со здоровьем).
Что обычно называют словом «говнокод» — когда задачи решены неоптимально, алгоритмы запутаны, и всё это сложно поддерживать новому разработчику. Но в большинстве языков код обрабатывается компилятором или интерпретатором, и не факт что после этого он всё ещё будет плох (проблем производительности это конечно не исправит, но всё остальное — вполне).
Хорошо протестированный и отлаженный говнокод будет работать годами, и вряд ли кто-то заметит, что что-то не так. Да, код мог выполнить операцию не за 1 секунду, а за треть. Но если у приложения нет такого объёма данных или такой нагрузки, где это становится критичным, — то зачем заказчику тратить на это время и деньги?
И да, неслучайно успешные стартаперы советуют новичкам: делайте так, чтобы приложение просто работало, — а когда ваш стартап взлетит, наводите красоту в коде.
Считаю ли я себя говнокодером — да, и по моим наблюдениям, это показатель того, что с тобой всё нормально. Сегодня ты видишь задачу таким образом, пишешь код, чтобы её выполнить, тестируешь — и довольный результатом переходишь к другой задаче. А через месяц смотришь на этот код и не можешь поверить, что ты мог такое написать, и думаешь, что лучше было сделать по-другому.
Ещё раз повторю: написание кода — это творчество в чистом виде, одной правды тут никогда нет.
«Нет времени на долгие раздумья — „вкорячиваешь“ костыль, и всё работает»
Олег — .NET-разработчик с 6 годами опыта. И тоже признаётся, что ему «иногда приходится» писать говнокод:
— Например, если в процессе релиза на прод выскакивает неожиданный баг, то порой нет времени на долгие раздумья — «вкорячиваешь» костыль, и всё работает. Главное — это дело обмазать todo-комментом, чтобы коллеги потом не съели заживо.
Часто без говнокода просто не обойтись, потому что у бизнеса есть свои цели — и он к ним идет любой ценой, но… не ценой времени. Заказчику плевать, что какие-то части системы ещё не переехали на новые рельсы и живут себе спокойно в легаси. Сделай задачу к концу спринта, а лучше — «вчера».
И если тебе приходится натягивать сову на глобус и скрещивать новые сервисы с легаси-системой — «запиши это в техдолг, чтобы потом сделать» (нет!). Отмечу, что сам код может выглядеть неплохо и быть вполне читаемым, но при этом на верхних уровнях рушить все зависимости, смачно харкая на схемы и диаграммы, нарисованные солюшен-архитектором.
И ещё перефразирую пословицу: если кто-то говорит, что он не пишет говнокод, будьте уверены — он делает это даже больше, чем остальные.
Вот, кстати, только что я «вкорячил» ещё один костыль в код.
«Глядя на свой код 2-4-летней давности часто говорю: это полный говнокод»
Андрей — Java-программист с 15-летним стажем. «Говнокодером» себя не считает, наоборот, он — перфекционист. И при этом признаёт, что говнокод — «как мат в обычной речи: без него можно обойтись, но бывают ситуации, когда с ним проще».
— В начале карьеры слышал в свой адрес упрёк: «говнокодер» — а сейчас уже некому такое мне сказать. Но, глядя на свой код 2-4-летней давности очень часто говорю: это полный говнокод, можно было сделать лаконичнее и правильнее.
Чаще всего к говнокоду ведёт:
- малый опыт;
- низкий приоритет у задачи;
- незаинтересованность исполнителя;
- слабые требования (или даже их отсутствие) к code-style.
В стартапе может быть маленькая мотивированная команда с парой опытных программистов, которые вроде бы должны писать не говнокод, — но в угоду быстрому старту проекта делают часть задач низкоприоритетными. А в большой компании, возможно, даже есть большие требования к code-style, но вовлеченность исполнителей — слабая, и они нередко говнокодят.
Я ставлю на то, что в продуктовых компаниях говнокода по естественным причинам меньше. Однако добавлю, что он есть во всех сферах, в том числе вне ИТ — только названия у таких продуктов соответствующего качества другие.
Читать на dev.by