10 привычек, которые делают веб-разработчика сильнее

Статьи вида «10 советов» обычно сборник банальностей: будьте внимательны, не бойтесь трудностей. Здесь список из десяти привычек без лозунгов: то, что реально меняет качество кода и скорость работы, проверено на практике, а не на красивых цитатах. Часть из них про сам код, часть про то, как вы работаете с другими людьми и с собственным временем.

Привычка в этом смысле отличается от разового усилия: её не нужно каждый раз заново решать соблюдать. Она встроена в рабочий процесс настолько, что отказаться от неё сложнее, чем выполнить. Ниже каждая привычка разобрана с конкретным действием, а не только с объяснением, почему это полезно.

Любопытство, направленное в сторону, а не вовне

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

• Перед правкой legacy-функции прочитать git-историю: кто и почему менял её раньше
• Спросить у автора кода, а не переписывать молча, если решение непонятно
• Выделять раз в неделю час на один вопрос «как это работает внутри», а не на ленту новостей

Этот же принцип работает и с новыми версиями языка или фреймворка. Разработчик, который прочитал список изменений в PHP 8.3 и 8.4 целиком, помнит из него через месяц немного. Разработчик, который применил одну конкретную возможность, например readonly-классы или типизированные константы, в своём текущем проекте, запоминает её навсегда, потому что она решила реальную задачу.

Привычка читать чужой код раньше, чем писать свой

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

• История коммитов своего же проекта за последний год
• Код открытых библиотек, которые вы используете как зависимости
• Pull request'ы с комментариями ревьюеров, не только финальный diff

enum OrderStatus: string
{
    case Pending = 'pending';
    case Paid = 'paid';
    case Cancelled = 'cancelled';
}

final readonly class Order
{
    public function __construct(
        public string $id,
        public OrderStatus $status,
    ) {}
}

Такой код из PHP 8.3 читается почти как спецификация: статус заказа ограничен конкретным набором значений, а не произвольной строкой, а неизменяемость объекта видна прямо в сигнатуре класса. Чтение подобного кода в чужих проектах быстрее учит современным идиомам языка, чем список фич из блога о релизе.

Тесты как часть привычки, а не отдельная задача

Тесты, написанные после сдачи задачи для галочки, покрывают happy path и ничего больше. Привычка писать тест одновременно с логикой, не обязательно строго TDD, но рядом, меняет сам код: функции становится проще тестировать, значит они становится проще и для чтения. Если тест сложно написать, это почти всегда сигнал, что функция делает слишком много.

composer test
composer phpstan analyse

Статический анализ вроде PHPStan или Psalm дополняет тесты, а не заменяет их: он ловит несовпадения типов и обращения к несуществующим свойствам до запуска кода, но ничего не знает о бизнес-логике. Привычка держать оба инструмента в одной команде, которую запускаете перед каждым коммитом, экономит время на тривиальных багах, которые иначе всплывут только на ревью.

Документация: писать и читать

Документация внутри команды почти никогда не читается, если её писать как формальность для галочки. Работает другой подход: документировать решения, а не очевидные вещи. Комментарий к коду должен объяснять «почему», код и так показывает «что». Если задача заняла больше дня из-за недокументированного решения, хорошая привычка, оставить короткую запись, чтобы следующий человек (возможно, вы сами через полгода) не повторял путь.

• README с разделом «почему так», а не только «как запустить»
• Комментарий у нестандартного решения, а не у каждой строки
• Запись в трекере задач: что попробовали и почему отказались

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

Умение сказать «не понимаю» и попросить код-ревью

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

Та же привычка работает в обратную сторону, когда вы сами проводите ревью. Если после прочтения PR остался вопрос, честный вариант, задать его прямо в комментарии, а не одобрить код из опасения показаться невнимательным. Хорошие ревьюеры задают вопросы не реже, чем дают указания на правки.

Отдых как часть продуктивности, а не её враг

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

1. Отключить уведомления на время фокус-сессии
2. Одна задача за раз, не три вкладки с разными тикетами
3. Перерыв по таймеру, а не пока сам не остановишься
4. В конце дня короткая заметка: что сделано, что осталось

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

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