Почему хороший код — это не главное

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

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

Каждый тянет одеяло на себя

В погоне за личным представлением об идеальном исполнении задачи, надо помнить, что в первую очередь надо выполнить задачу, а уже во вторую сделать это так как считаете нужным. Обычно в конфликте за код — три участинка: менеджеры, разработчики и пользователи. Разберёмся, кто чего хочет. Тогда станет видно, что определяет ситуацию.

Менеджер: Быстрее. Дешевле. Лучше

Для менеджера чистый код — не цель, а издержка. Его задача — результат: вовремя запустить фичу, удержать клиента, уложиться в бюджет. Он мыслит цифрами, планами и рисками. Если проект горит, он не будет ждать, пока программист «вылижет» архитектуру. Надо выпускать — а баги можно поправить потом. Или пусть чинят другие.

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

Хрестоматийный пример — история с Cyberpunk 2077. Бизнес торопился к праздничным продажам, несмотря на предупреждения команды. Вышло вовремя, но сыро: баги, скандалы, возвраты, удаление из PS Store. Да, игру потом допилили, но репутация уже пострадала.

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

Разработчик. Лучше меньше, но лучше

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

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

Именно здесь начинается конфликт с менеджером. Одному нужно быстрее, другому — надёжнее. Менеджеру важен релиз, разработчику — чтобы не стыдно было на Code Review.

Иногда это уходит в крайности. Вспомним Netscape: когда команда решила переписать всё с нуля, но проиграла рынок Internet Explorer. Браузер вышел спустя годы — медленный, устаревший, никому не нужный. Код был чище, но пользователь ушёл.

Или другая крайность — когда инженер, прикрываясь качеством, переписывает модуль просто потому, что «не нравится стиль» предыдущего разработчика. Время теряется, а пользы нет. Бывает и саботаж — пассивный, когда тянут время, и активный: баги, чтобы потом чинить за деньги. Редко, но случается.

Чаще — просто непонимание. Разработчик хочет изучить новую технологию, прокачаться, сделать «по фэншую». Менеджер боится рисков. Один хочет фокус, другой — многозадачность. Компромисс? Обсуждать. Хороший разработчик умеет говорить на языке бизнеса: «если не исправим сейчас — через полгода выпуск фич замедлится». Плохой — либо ломается, либо тайно делает по-своему.

В идеале всё решает диалог. Но пока его нет, программист защищает проект от будущего коллапса. Или думает, что защищает.

Пользователь. Просто сделайте это

Пользователю всё равно, кто в команде прав. Ему неинтересно, на чьей стороне аргументы — бизнеса или разработки. Он оценивает продукт по одному критерию: работает или нет.

Если побеждает бизнес-оптика — релизы выходят быстро, но страдает качество. Пользователь сталкивается с багами, нестабильной работой, неудачными решениями в интерфейсе. Он недоволен, делится негативным опытом, уходит к конкурентам.

Если доминирует подход разработки — всё надёжно, продумано, покрыто тестами, но слишком медленно. Функции появляются редко или не появляются вовсе. Пользователь ждёт, теряет интерес — и тоже уходит. В обоих случаях страдает именно он, хотя формально в конфликте не участвует.

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

Хороший пример — история MySpace. Платформа позволяла пользователям встраивать на страницы произвольный HTML, CSS и Flash. Это давало широкие возможности кастомизации, но превращало сайт в набор тяжёлых, нестабильных страниц. Вместо того чтобы оптимизировать опыт, владельцы сделали ставку на монетизацию: добавляли рекламу, перегружали интерфейс, продолжали расширять функциональность. В результате пользователи столкнулись с деградацией качества и начали уходить. Даже творцы, которым эта свобода нравилась, не смогли удержать тех, кому она мешала. Когда компания попыталась перезапустить платформу, аудитория уже окончательно ушла на более стабильные альтернативы. Этот кейс наглядно показывает: проигнорированный пользовательский опыт способен обрушить даже крупнейший продукт.

Пример того как пользователь решил себя выразить

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

Иногда пользователь напрямую вовлекается в диалог — в open-source проектах, играх с бета-тестом, через отзывы и обращения в поддержку. Его реакция может оказывать реальное влияние: побуждать менеджеров требовать доработок, а разработчиков — пересматривать архитектурные решения. Если пользователи массово жалуются на неудобства, откладываются новые фичи, приоритет смещается на устранение критичных проблем. Обратная связь становится полем переговоров между командами — и аргументом в пользу реальных действий.

Важно помнить: пользователь не делит команду на менеджеров и разработчиков. Он видит продукт целиком. Его не волнуют внутренние конфликты — только итог. Если что-то не работает, он воспринимает это как провал всей команды. Поэтому зрелые компании стремятся минимизировать влияние внутренних споров на пользовательский опыт. Они отдают приоритет коротким итерациям, тестированию перед релизом, сбору и обратной связи.

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

Как конфликты реально влияют на индустрию: разбор кейсов

Рассмотрим несколько реальных конфликтов между бизнес-целями и идеализмом разработки в истории IT, их последствия и чему они научили индустрию.

Кейс 1: Переписывание Netscape Navigator с нуля (1998-2000)

Этот случай стал хрестоматийным примером того, как техническое решение, принятое без учёта бизнес-реалий, погубило продукт. В конце 90-х браузер Netscape Navigator доминировал на рынке, но кодовая база устаревала. Разработчики Netscape, стремясь сделать «как лучше», убедили руководство пойти на радикальный шаг – полностью переписать браузер с нуля, заодно открыв исходный код (проект Mozilla). Казалось, что новая архитектура сделает продукт лучше в долгосрочной перспективе. Но что произошло на практике? Пока инженеры два года создавали идеальный новый браузер, конкурент Internet Explorer от Microsoft захватил рынок, воспользовавшись паузой в развитии Netscape​. Версия Netscape 6.0, наконец выпущенная через три года, оказалась сырой и медленной, а доля рынка Netscape к тому моменту упала почти до нуля​. Компания потерпела крах: её продали, а вскоре подразделение Netscape было закрыто. По сути, переписывание «на будущее» убило тот самый бизнес, ради которого всё затевалось.

Этот кейс наглядно показывает: хороший код и правильная архитектура не спасут продукт, если время упущено. Решение разработчиков переписать всё обернулось стратегической ошибкой. Извлечённый урок сформулировал блогер Джоэл Спольски: «Никогда не переписывайте работающий софт с нуля», называя это худшей стратегической ошибкой в разработке​.

Кейс 2: Релиз Cyberpunk 2077. Бизнес против качества (2020)

У CD Projekt Red были огромные ожидания от релиза Cyberpunk 2077: миллионы предзаказов, маркетинговые кампании, давление инвесторов. Команда настаивала, что игра сыровата, особенно на старых консолях. Но менеджмент решил не переносить релиз — слишком велик был соблазн выйти к праздничному сезону.

Лицо игроков запустивших киберпанк на ps4 в день релиза

Результат: скандал. Масса багов, недовольство игроков, игра удалена из PlayStation Store — беспрецедентный шаг. CDPR принесла извинения и почти год выпускала патчи. К 2021 году игру удалось стабилизировать, но репутационные потери и падение акций стали высокой ценой.

Вывод: краткосрочная победа бизнеса обернулась долгосрочными убытками. Компромисс между сроками и качеством — не прихоть, а необходимость.

Кейс 3: Внутренние конфликты и увольнения

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

Том ДеМарко, автор Peopleware, отмечал: «Качество, сильно превышающее требования, снижает продуктивность», — и подчёркивал важность общения.

Если конфликт не решается, проигрывают все — команда разваливается, проекты буксуют. Иногда помогает смена культуры или переход на подход, где команду действительно слышат (например, agile). Главный урок — нельзя игнорировать человеческий фактор. Без диалога даже сильные специалисты не спасут проект.

Что важно запомнить начинающему разработчику

Хороший код — это не тот, что идеален с точки зрения синтаксиса или архитектуры, а тот, который решает задачу. Не забывайте, что цель вашей работы — не чистота кода ради неё самой, а польза для продукта и пользователя.

Перед тем как тратить время на рефакторинг или переосмысление архитектуры, задавайте себе вопросы:

• Заметит ли пользователь эту работу?

• Поможет ли это продукту?

• Можно ли достичь того же результата проще?

Иногда лучше выпустить «рабочее решение» и вернуться к улучшениям позже. В другой ситуации — наоборот: стоит затормозить релиз, если качество слишком сильно пострадает. Всё зависит от контекста.

Рассмотрим реальные советы, которые могут помочь.

Понимайте бизнес-реальность

Разработчикам важно учиться видеть картину шире. Менеджеры не давят «просто так» — за ними тоже стоят сроки, бюджеты, обязательства перед клиентами или акционерами. Когда вы понимаете, откуда идут требования, проще искать компромиссы.

Вместо того чтобы воспринимать бизнес как оппонента, рассматривайте его как партнёра. Вы работаете на общий результат.

Развивайте навык коммуникации

Общение — ключевой софт-скилл в команде. Умение говорить понятно и по делу поможет вам быть услышанным.

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

И наоборот — когда продакт говорит, что нужно ускориться, попробуйте понять, в чём реальная потребность. Возможно, не нужно делать всё сразу — достаточно MVP.

Ищите баланс

Умение договариваться и находить разумный баланс между скоростью, качеством и удобством для пользователя — один из важнейших навыков разработчика. Научиться видеть этот баланс и не впадать в крайности (перфекционизм или спешка) — то, что приходит с опытом. Но начать можно прямо сейчас: задавая вопросы, предлагая решения, не уходя в глухую оборону.

В итоге сильный разработчик — это не только тот, кто пишет хороший код. Это тот, кто помогает делать продукт лучше. А значит — умеет видеть за задачей пользователя, за фичей — цель, а за диалогом — шанс построить что-то действительно ценное.

Ты точно программист, если читаешь это! Больше мемов, инсайтов и боли кодеров тут.