Топ 6 привычек, которые отличают хорошего разработчика
Разница между посредственным и хорошим разработчиком редко сводится к знанию редкого фреймворка или трюка с языком. Куда чаще дело в нескольких простых привычках, которые складываются в заметный результат только на длинной дистанции. Собрали шесть таких привычек — без разговоров о хард-скиллах и модных технологиях.
Почему привычки важнее конкретных технологий
Технологии меняются быстрее, чем успевает устареть учебник: фреймворк, актуальный сегодня, через несколько лет может уступить место чему-то новому. Привычки читать документацию, писать понятный код и не бояться спрашивать остаются полезными независимо от того, какой стек используется на текущем проекте.
Ни одна из шести привычек ниже не требует особого таланта — все они вырабатываются практикой и сознательным повторением. Именно поэтому разница между тем, кто их применяет, и тем, кто нет, со временем становится заметнее, а не наоборот.
Статистику про то, сколько именно процентов успеха определяют привычки, а не технические навыки, здесь сознательно не приводим — таких точных цифр никто честно не считал. Но наблюдение за тем, кого в командах чаще называют «удобным в работе» разработчиком, довольно последовательно указывает именно на эти шесть пунктов.
Топ 6 привычек хорошего разработчика
Читать документацию
не только искать готовый ответ на форуме, но и разбираться в первоисточнике
Готовый фрагмент кода, найденный в интернете, часто решает сиюминутную задачу, но не даёт понимания, почему решение работает и в каких случаях оно перестанет работать. Официальная документация отвечает и на эти вопросы, хотя требует чуть больше времени на чтение.
Привычка сначала заглянуть в документацию, а не сразу в поиск, окупается на нетипичных случаях. Именно там, где готового ответа в интернете ещё не существует, разница между тем, кто умеет читать первоисточник, и тем, кто полагается только на чужие примеры, становится особенно заметной.
Это не значит, что искать готовые решения — плохая практика: экономить время таким образом нормально. Вопрос в том, что делать, когда готового решения нет или оно не подходит под конкретный случай.
- Даёт понимание, почему решение работает, а не только что писать
- Особенно ценно в нетипичных случаях без готовых примеров
- Снижает зависимость от устаревших или неточных сторонних статей
- Часто медленнее, чем скопировать готовый пример
- Документация не у всех инструментов одинаково качественная
- Требует привычки, которая не формируется за один день
окупается в нетипичных случаях · оценка 9,3
Писать код понятно для людей
компилятору или интерпретатору всё равно, а вот следующему человеку — нет
Код, который работает, но требует пятнадцати минут вдумчивого чтения ради понимания одной функции, создаёт скрытый долг — за него рано или поздно расплатится кто-то другой, а иногда тот же самый автор через полгода. Понятные имена переменных, разумная длина функций и последовательная структура — не эстетика ради эстетики, а экономия чужого и своего будущего времени.
Понятный код — это код, написанный с мыслью о читателе, а не только о том, чтобы он заработал. Полезная проверка — представить, что этот же код через полгода придётся объяснять новому человеку в команде, который вообще не в контексте.
Более широкий разбор конкретных приёмов, которые делают код читаемым, — в материале про правила, чтобы ваш код читали.
- Снижает время на понимание кода для всей команды в будущем
- Уменьшает число ошибок, возникающих из-за неверного понимания логики
- Формирует репутацию удобного в совместной работе разработчика
- Требует немного больше времени в моменте написания
- Представление о «понятности» отличается у разных людей и команд
- Легко скатиться в чрезмерное усложнение ради мнимой «красоты» кода
экономит чужое время в будущем · оценка 9,2
Делать маленькие изменения
небольшой понятный коммит или пул-реквест проще проверить, понять и при необходимости откатить
Огромный пул-реквест на пару тысяч строк, затрагивающий сразу несколько несвязанных задач, почти невозможно нормально проверить: рецензент либо тратит на это несоразмерно много времени, либо пролистывает поверхностно, теряя смысл проверки. Маленькое изменение с одной ясной целью проверяется быстрее и внимательнее.
Маленькие изменения снижают цену ошибки. Если что-то пошло не так после небольшого точечного изменения, откатить его или найти причину заметно проще, чем разбираться, какая из сотен строк в огромном коммите сломала систему.
Привычка резать большую задачу на небольшие последовательные шаги — само по себе полезный навык планирования, который пригодится далеко за пределами одних только пул-реквестов.
- Проще и быстрее проверяется на код-ревью
- Снижает цену ошибки и упрощает откат при проблеме
- Развивает полезный навык декомпозиции задач
- Требует более частых циклов ревью вместо одного большого
- Не всегда просто разбить на маленькие шаги взаимосвязанную задачу
- Может казаться медленнее на старте, особенно под давлением сроков
снижает цену ошибки на каждом шаге · оценка 9,0
Писать тесты
не ради отчётности, а как способ зафиксировать ожидаемое поведение
Тесты часто воспринимают как дополнительную нагрузку, которая замедляет разработку. На короткой дистанции это отчасти верно, но на дистанции нескольких месяцев верно обратное: тесты позволяют менять код, не боясь незаметно сломать то, что уже работало.
Хороший тест — это ещё и документация того, как код должен себя вести. Он фиксирует не только очевидный сценарий, но и граничные случаи, о которых иначе пришлось бы вспоминать каждый раз заново или узнавать заново через баг в проде.
Не обязательно стремиться к покрытию тестами абсолютно всего кода — разумнее сосредоточиться на самой рискованной и часто изменяемой логике, а не на тривиальных участках, где вероятность ошибки минимальна.
- Позволяет менять код без страха незаметно что-то сломать
- Фиксирует граничные случаи как часть документации поведения
- Ускоряет обнаружение проблем до того, как их увидит пользователь
- Требует времени, которое не всегда закладывается в сроки задачи
- Плохо написанные тесты создают ложное чувство безопасности
- Не заменяет ручную проверку в действительно нетипичных сценариях
окупается на дистанции нескольких месяцев · оценка 8,8
Спрашивать, когда застрял
час самостоятельного тупика редко экономит время по сравнению с одним точным вопросом
Разработчики нередко воспринимают вопрос коллеге как признание собственной некомпетентности, хотя на практике всё ровно наоборот: умение вовремя распознать, что дальнейшие самостоятельные попытки не продуктивны, и обратиться за помощью — зрелый профессиональный навык, а не его отсутствие.
Хороший вопрос экономит время не только спрашивающему, но и всей команде, ведь застрявшая задача рано или поздно всё равно потребует чьего-то участия — но уже под давлением сорванного срока, а не в спокойном рабочем темпе.
Разумная привычка — сначала честно попробовать разобраться самостоятельно разумное время, а затем задать конкретный вопрос с описанием уже предпринятых шагов, а не растягивать самостоятельные попытки на весь день.
- Экономит часы, потраченные на самостоятельные тупиковые попытки
- Помогает команде обнаружить проблему раньше, а не в момент дедлайна
- Формирует атмосферу, где задавать вопросы нормально для всех
- Требует преодолеть страх показаться недостаточно компетентным
- Слишком частые вопросы без самостоятельной попытки утомляют коллег
- Не в каждой команде культура вопросов одинаково развита
зрелость, а не признак слабости · оценка 8,6
Вести заметки
память ненадёжна, особенно для решений, которые принимались месяцы назад
«Почему мы вообще выбрали именно этот подход?» — вопрос, на который через полгода без заметок ответить бывает удивительно сложно, даже если решение принимали вы сами. Личный журнал решений, разобранных багов и заметок по проекту решает эту проблему дёшево и просто.
Заметки полезны не только для команды, но и для себя самого в будущем. Разобранный один раз сложный баг, записанный в паре предложений, экономит время, если что-то похожее повторится через несколько месяцев — вместо того чтобы заново проходить весь путь расследования.
Формат не так важен, как сама привычка: подойдёт простой текстовый файл, личная база знаний или комментарии в системе управления задачами — главное, чтобы записи действительно велись, а не оставались благим намерением.
- Экономит время при повторении похожих проблем в будущем
- Помогает объяснить прошлые решения себе и команде
- Не требует специальных инструментов — подходит любой простой формат
- Легко забросить без сознательного напоминания себе
- Польза заметна не сразу, а спустя месяцы
- Требует времени на ведение, пусть и небольшого
малозаметная привычка с накопительным эффектом · оценка 8,3
Сравнение по главному
| Привычка | Эффект заметен | Кому помогает в первую очередь |
|---|---|---|
| Читать документацию | в нетипичных случаях | себе в моменте |
| Писать понятно | при следующем чтении кода | команде в будущем |
| Маленькие изменения | на код-ревью | рецензенту и автору |
| Писать тесты | при следующих изменениях | всей команде |
| Спрашивать | сразу, при затруднении | себе и команде |
| Вести заметки | спустя месяцы | себе в будущем |
Как внедрить это в ежедневную работу
Не пытайтесь освоить все шесть привычек одновременно. Возьмите одну, доведите до автоматизма на протяжении нескольких недель, затем добавляйте следующую — резкая смена сразу всех рабочих привычек обычно не приживается.
Начните с той привычки, которая ближе всего к вашей текущей боли. Если чаще всего страдаете от непонятного отклика на код-ревью — начните с маленьких изменений и понятного кода. Если постоянно натыкаетесь на одни и те же баги — с заметок и тестов.
Многие из этих привычек особенно заметны именно на код-ревью — как своём, так и чужом: подробнее о том, что делает ревью полезным, а не формальным, в материале про правила полезного код-ревью.
Частые вопросы
Какая из шести привычек самая важная?
Однозначного ответа нет — они работают вместе, а не по отдельности. Но чаще всего первой заметной становится привычка писать код понятно для других: её эффект виден уже на ближайшем код-ревью, а не только через месяцы.
Не мешают ли тесты и заметки скорости разработки?
На короткой дистанции — да, они требуют дополнительного времени. На дистанции нескольких месяцев обычно наоборот: меньше времени уходит на исправление незамеченных багов и повторное разбирательство в уже решённых проблемах.
Как научиться делать код-ревью маленькими частями, если задача большая?
Попробуйте разбить задачу на этапы ещё до начала работы: например, отдельно инфраструктурные изменения, отдельно основная логика, отдельно тесты. Не каждую задачу можно разбить идеально, но чаще это возможно, чем кажется на первый взгляд.
Что делать, если в команде не принято задавать вопросы?
Можно начать с себя: формулировать конкретные вопросы с описанием уже предпринятых шагов — такие вопросы обычно воспринимаются нормально даже в сдержанной культуре команды. Если реакция стабильно негативна даже на такие вопросы, это скорее сигнал о культуре конкретной команды.
Итог
Ни одна из шести привычек не работает как разовое волшебное решение — все они дают эффект на дистанции, через повторение. Читать документацию и писать понятный код проще всего начать уже сегодня, без изменений в процессах команды.
Маленькие изменения и тесты чуть сильнее завязаны на договорённости с командой, а спрашивать и вести заметки — личные привычки, которые можно начать применять уже на следующей задаче, независимо от того, что делают остальные.
Комментарии
0Будьте первым, кто ответит автору.