Вечный вопрос разработчика: как писать код быстрее, не превращая его в поддерживаемый кошмар? Дедлайны давят, требования растут, а перфекционизм подсказывает: «Еще рефакторинг!» Автор годами искал баланс между скоростью и качеством в разработке ПО и вывел практические правила. Делимся опытом: черновики вместо идеала, борьба с отвлечениями, маленькие патчи и навыки, реально ускоряющие работу. Готовы ускориться?

Создание программного обеспечения всегда связано с ограничениями по времени и качеству. Нам хочется написать хороший код и при этом сделать всё в кратчайшие сроки.

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

Этот текст посвящён работе разработчика в небольшой команде, занимающегося поддержкой программного обеспечения на протяжении нескольких лет. Здесь речь не идёт о создании быстрых прототипов, и всё, о чём я пишу, основано исключительно на моём собственном опыте.

«А насколько хорошим это должно быть?»

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

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

Например, если вы делаете игру во время 24-часового состязания, едва ли стоит уделять приоритетное внимание чистоте кода. Это будет просто пустой тратой времени! Кому, вообще, важно, насколько элегантен и безукоризнен ваш код?

А вот если вы создаёте кардиостимулятор, ошибаться крайне опасно — такой проект требует идеального качества. Я не хотел бы рисковать своей жизнью из‑за чьего‑то спагетти‑кода.

Большинство моей работы находится где‑то посередине. У некоторых работодателей крайне жёсткие сроки, где небольшое количество багов вполне допустимо, тогда как другие проекты требуют высочайшего уровня качества и допускают более расслабленный график. Разобравшись, где именно находится грань, мне удалось понять, куда направить свои усилия. В чём заключается понимание «достаточно хорошо» в моей команде? Какие баги приемлемы, если вообще приемлемы? Где я могу позволить себе сделать работу «неидеально», чтобы уложиться в сроки?

Как правило, я придерживаюсь следующего принципа: цель — достичь 8 баллов из 10, но вовремя. Код должен быть хорошим и выполнять свою задачу. Пусть там будут мелкие недочёты, но ничего критичного. И главное — работа завершена вовремя! (Конечно, я только стремлюсь к этому. Это не всегда удаётся.) Но снова повторю: всё зависит от проекта — иногда я добиваюсь абсолютного совершенства, пусть и с опозданием, а порой спешу закончить, соглашаясь на сыроватый код.

Для быстрого прототипирования, генерации кода или помощи с тестами мы пользуемся разными нейросетями. Удобно работать с ними через агрегаторы вроде BotHub, где есть доступ к Claude Sonnet/Opus 4, Gemini 2.5 Pro, Grok 4 и другим в одном интерфейсе, а регистрация приносит 100 000 бонусных капсов.

Черновики

Программное обеспечение, как и текст, может выиграть от наличия черновика. В программировании его называют «spike» или «walking skeleton» («ходячий скелет»).

Я люблю создавать черновик как можно быстрее, чтобы потом обработать и доработать его до финального решения.

Мой черновой код, откровенно говоря, ужасен. Вот несколько характеристик моих типичных spike‑ов:

• Множество багов и проваленных тестов.

• Десятки комментариев TODO.

• Ошибки никак не обработаны. (Например, однажды в моей ветке ошибка логировалась 20 раз в секунду.)

• Повсюду print‑операторы.

• Полное игнорирование производительности.

• Сообщения к коммитам состоят из трёх букв: «WIP» («work in progress», «работа в процессе»).

• Подключены три пакета, из которых ни один больше не используется.

• Много бессмысленного дублирования кода.

• Данные заданы хардкодом.

• Линтер недоволен и краснеет.

Это всё звучит кошмарно, но у такого подхода есть одно важное преимущество: код хоть отдалённо напоминает готовое решение.

Как вы, наверное, догадались, все эти ошибки я исправляю до финального принятия изменений. (Конечно, иногда команды подталкивают меня выпустить этот неказистый код, чему я стараюсь сопротивляться. Черновик — это не финальная версия!)

Такой подход с черновиками имеет несколько плюсов:

• Он помогает выявить «неизвестные неизвестности». Прототипы часто вскрывают вещи, о которых невозможно подумать заранее. Лучше узнать о них как можно раньше, чем после того, как вы отшлифовали код, который придётся выбросить.

• Огромное количество проблем исчезает в процессе работы над черновиком, так что их не приходится устранять. Например, я могу написать функцию, которая работает медленно, но достаточно годится для прототипа. Позже я осознаю, что эта функция вообще не нужна. Хорошо, что я не тратил время на её оптимизацию! (Даже не могу сосчитать, сколько функций я подробно протестировал, а потом удалил. Настоящая трата времени!)

• Это помогает мне сосредоточиться: я не отвлекаюсь на исправление багов в другой части кода или на раздумья о лучшем названии функции. Я спидраню черновик, чтобы разобраться в сути задачи.

• Это помогает избежать преждевременных абстракций. Если я стремлюсь быстро запустить что‑то неуклюжее, я реже пытаюсь изобретать сложные абстракции. Я концентрируюсь на том, что нужно для решения конкретной проблемы, а не на том, что, возможно, понадобится в будущем (и на самом деле, скорее всего, никогда не понадобится).

• Это упрощает общение с другими о ходе работы. Во‑первых, я обычно могу точнее оценить время завершения задачи, ведь теперь я знаю, что примерно остаётся сделать. Во‑вторых, у меня уже есть что показать: это позволяет заинтересованным сторонам понять, над чем я работаю, и дать обратную связь. Иногда такая обратная связь может даже изменить направление работы, что лучше узнать раньше.

Вот несколько конкретных вещей, которые я делаю при создании черновиков:

• Фокус на ключевых решениях. Некоторые выборы, например язык программирования или структура базы данных, сложно изменить позднее. Черновик — это хорошее время, чтобы их исследовать и убедиться, что я не загоняю себя в угол, о чём потом буду жалеть.

• Отслеживание упрощений и обходных путей. Каждый раз, когда я делаю что‑то нестандартное или срезаю угол, я оставляю комментарий TODO или что‑то подобное. Позже, когда наступает время шлифовки, я запускаю git grep TODO, чтобы увидеть всё, что требует внимания.

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

• Выделение мелких изменений в процессе работы. Иногда в ходе черновика я замечаю, что где‑то в коде нужно внести улучшения. Возможно, требуется обновление зависимости. Перед тем как закончить окончательный вариант, я делаю отдельный патч, чтобы только обновить эту зависимость. Это само по себе полезно, а также облегчит последующие изменения. Патч можно отправить на ревью отдельно, и, если всё пойдёт гладко, он уже будет объединён, когда я завершу финальную версию.

Попробуйте изменить требования

Как правило, чем меньше делаешь, тем быстрее и проще! В зависимости от задачи можно смягчить требования.

Вот несколько вопросов, которые стоит задать:

• Можно ли объединить несколько экранов в один?

• Есть ли вариант обойтись без обработки сложной частной ситуации?

• Вместо API, поддерживающего 1000 потоков входных данных, что если поддерживать только 10?

• Можно ли сделать прототип вместо финальной версии?

• А что если вообще отказаться от этого?

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

Избегайте «брождения» по коду

Современный мир полон отвлекающих факторов: уведомления с телефона, сообщения от коллег, ненавистные встречи. У меня, честно говоря, нет идеальных ответов на то, как с ними справляться.

Но есть ещё один тип отвлечений: я начинаю «бродить» по коду. Берусь за одно задание, а через два часа вдруг понимаю, что занимаюсь чем‑то абсолютно посторонним. Возможно, я теоретически занимаюсь полезным делом и даже улучшаю кодовую базу, но тот баг, который мне поручили исправить, так и остался нерешённым. Проще говоря, я «заблудился в соусе».

Я нашёл два конкретных способа справляться с этим:

• Запускать таймер. Когда я начинаю работать над конкретной задачей, я часто устанавливаю таймер. Например, я предполагаю, что написание функции займёт 15 минут. Или что понадобится час, чтобы понять причину бага. Обычно мои оценки оказываются неточными, но, когда таймер срабатывает, это часто выдёргивает меня из какого‑нибудь бесполезного отвлечения. А ещё нет ничего приятнее, чем сделать git commit ровно в момент, когда таймер звенит, — идеально рассчитанное время. (Кстати, это ещё и помогает оттачивать искусство оценки времени задач, хотя я всё ещё далёк от совершенства.)

• Парное программирование. Работа с напарником помогает не сбиться с пути. Ещё одна душа рядом вряд ли позволит тратить её время на какой‑нибудь незначительный вопрос.

Некоторые программисты от природы умеют избегать такого отвлечения, но только не я. Дисциплина и осознанное действие помогают мне сосредоточиться.

Делайте небольшие изменения

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

Небольшие, точечные диффы почти всегда работали для меня лучше. У них есть несколько преимуществ:

• Они обычно проще в написании, так как держишь в голове меньше деталей.

• Их легче проверять. Это снижает когнитивную нагрузку коллег, помогает заметить мои ошибки и обычно приводит к тому, что мой код быстрее сливается с базой.

• Их легче откатить в случае чего.

• Они уменьшают риск возникновения новых ошибок, поскольку вы меняете гораздо меньше за раз.

Мне нравится разбивать крупное изменение на более мелкие части. Например, если я добавляю экран, для которого нужно исправить баг и обновить зависимость, я могу сделать три отдельных патча: один для исправления бага, другой для обновления зависимости и третий для добавления экрана.

Маленькие изменения обычно помогают мне писать код быстрее и качественнее.

Полезные навыки

Бо́льшая часть из всего вышеперечисленного относится к довольно общим принципам. А вот несколько более конкретных навыков, которые оказались для меня незаменимыми, особенно когда я стараюсь разрабатывать ПО быстро:

• Чтение кода — без сомнения, самый важный навык, который я приобрёл как программист. Пришлось немало поработать, чтобы овладеть им! Его польза огромна: становится проще обнаруживать ошибки, поскольку можно понять, как работает какая‑то функция; баги и плохая документация в сторонних зависимостях уже не пугают; оно является великолепным проводником знаний — и это далеко не всё.

• Моделирование данных имеет критическое значение, даже если на это уходит больше времени. Сделав некорректные состояния недопустимыми, можно избежать целых классов ошибок. Неправильно спроектированная структура базы данных может привести к множеству проблем в дальнейшем. Я думаю, что стоит потратить время на аккуратное продумывание моделей данных, особенно если они будут сохраняться или использоваться для обмена.

• Скриптинг. Умение быстро и непринуждённо писать скрипты на Bash или Python значительно ускоряет мою работу. Каждую неделю я пишу несколько скриптов для решения различных задач: например, сортировки списков в Markdown, очистки данных или поиска дубликатов файлов. Я настоятельно рекомендую Shellcheck для Bash — он помогает избежать множества распространённых ошибок. Кроме того, нейросети (LLM) хорошо справляются с написанием таких скриптов.

• Отладчики сэкономили мне массу времени. Ничто не может заменить полноценный отладчик. Он значительно упрощает понимание происходящего (будь то баг или нет) и быстро становится эффективнее, чем отладка через print().

• Умение вовремя сделать перерыв. Если я застреваю на задаче и не двигаюсь вперёд, мне стоит отвлечься. Так происходило со мной десятки раз: я мучился с проблемой на протяжении часов, отходил на некоторое время, возвращался — и находил решение за пять минут.

• Предпочтение чистым функциям и неизменяемым данным. Стиль функционального программирования помогает избежать множества ошибок и снижает когнитивную нагрузку. Часто он оказывается проще, чем проектирование сложных иерархий классов. Не всегда практично, но это мой стандартный выбор.

• LLM (модели машинного обучения) могут ускорять некоторые этапы разработки. Мне понадобилось время, чтобы понять их сильные стороны, но теперь я пользуюсь ими в повседневной работе.

Все эти навыки я неоднократно оттачивал на практике, и, как мне кажется, вложенные усилия сделали меня более быстрым разработчиком.

Итог

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

• Определите, насколько качественным должен быть ваш код для выполнения задачи.

• Начинайте с черновика, скелета.

• Постарайтесь смягчить требования, если возможно.

• Не допускайте отвлечений.

• Делайте небольшие изменения.

• Практикуйте специфические навыки.

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

Мне любопытно, что вы открыли для себя на эту тему? Знаете ли вы ещё какие‑нибудь хитрости или, возможно, несогласны с моими методами?

Быстрая разработка — это не магия, а набор практик: принятие неидеальности, итеративность (от черновика к чистовой), фокус, атомарность изменений и прокачка полезных скиллов. Главное — понять, где ваша грань «8 из 10». Попробуйте эти подходы, адаптируйте под себя и свою команду. Скорость придет с практикой.