Ошибки, которые совершают junior-разработчики
Выпуск работающего кода — это лишь необходимый минимум. Это не конечная цель.
Однажды я проверял pull request, на понимание которого ушло 45 минут. Логика была верной. Тесты проходили. Но код был написан так, будто его будет читать только сам автор.
Когда я дал обратную связь, разработчик ответил: «Но ведь оно работает».
Он был прав. Оно работало. В этом и заключалась проблема.
Junior-разработчики часто фокусируются на технических навыках. Но основные пробелы обычно кроются в привычках и мышлении.
Вот тонкие ошибки, которые замедляют ваш прогресс:
Писать для себя, а не для других Код читают гораздо чаще, чем пишут. Функцией, которую вы написали сегодня, за два года могут воспользоваться три разных человека. Если посторонний не может понять ваш код за 30 секунд — вы не справились.
Копирование кода без понимания сути Использовать Stack Overflow — это нормально. Копировать регулярное выражение (regex), не понимая, как оно работает, — опасно. Вы создаете «черный ящик» в кодовой базе. Вы не сможете его отладить, когда он сломается.
Добавление ненужной сложности Junior-разработчики часто приравнивают сложность к мастерству. Они применяют паттерны проектирования к простым задачам. Излишняя абстракция усложняет отладку и внесение изменений. Добавляйте абстракцию только тогда, когда почувствуете, что её отсутствие причиняет боль.
Игнорирование сообщений об ошибках Сообщения об ошибках — это бесплатная документация. Не спешите бежать в Google, как только увидели stack trace. Прочитайте сообщение целиком. Часто в нем точно указано, какая строка вызвала ошибку и почему.
Слишком ранние или слишком поздние просьбы о помощи Не тратьте три часа на решение задачи, которая занимает 10 минут. Это неэффективно. Но и не пингуйте senior-разработчика, присылая просто скриншот без контекста. Используйте «правило 20 минут»: потратьте 20 минут на попытку решить проблему самостоятельно. Зафиксируйте, что именно вы пробовали сделать. И только после этого просите помощи, приложив этот список.
Переизобретение существующего Прежде чем писать новую утилиту, поищите по кодовой базе. Скорее всего, ваша команда уже решила эту задачу.
Плохие сообщения к коммитам Сообщение вроде «fix bug» ничего не говорит вашей команде. Объясняйте, что именно изменилось и почему. Относитесь к истории Git как к документации.
Восприятие требований как непреложного закона В требованиях часто упускаются граничные случаи (edge cases). Не просто реализуйте то, что вам сказали. Спрашивайте, что произойдет, если что-то пойдет не так.
Остановка на кнопке «Merged» Ответственность не заканчивается в момент слияния вашего PR. Проследите за своей фичей в QA. Следите за ней в продакшене. Читайте отчеты об ошибках.
Самый большой пробел — это ответственность. Senior-разработчики не просто пишут код. Они решают проблемы, не создавая новых.
Перестаньте оптимизировать процесс ради статуса «готово». Начните оптимизировать его ради «качества».