8 ошибок начинающих разработчиков
Рассмотрим типичную историю начинающего разработчика👶
Чтобы стать программистом, он долго учился. Прошёл много курсов, писал учебные проекты. У них маленькая кодовая база, один пользователь, а главная задача — отработать алгоритм или попробовать фреймворк.
В этих условиях у стажёра сформировался стиль написания кода.
После собеседования стажёр начинает работать в крупном проекте вместе с другими разработчиками. И здесь очень важно перестроиться: многие паттерны, нормальные в учебных проектах, уже не подходят.
В этом посте опишу 8 таких паттернов на простых примерах.
1️⃣ Процедурный стиль
Задача: получить список заказов пользователя. Новичок скорее всего напишет такой код:
Во входной параметр
В системах со сложной бизнес-логикой такой подход усложняет чтение, тестирование и возможную параллелизацию.
Как лучше: использовать выходные параметры, не менять входные данные, давать осмысленные имена методам:
2️⃣ Сложные универсальные методы
Задача: по-разному считать скидку для новых пользователей и пользователей с картами лояльности.
Новички часто используют принцип Don't Repeat Yourself на максималках и пишут универсальный метод с кучей параметров и десятком if внутри:
Как лучше: сфокусированные методы для разных ситуаций
3️⃣ Длинные методы
Сложно читать и тестировать, страшно менять.
4️⃣ Любовь к статическим методам
Как лучше: небольшие методы, связанные с конкретным классом. Связность ниже, ошибок меньше.
5️⃣ Сложное проектирование
Задача: завести три типа пользователей: новые, обычные и VIP. Новички скорее всего сделают интерфейс, 3 класса и статический класс с фабричными методами и билдером.
Как лучше: как можно проще. Например, один класс пользователя с полем Тип. Усложнять при реальной необходимости
PS Все "как лучше" не всегда лучше. Но думаю, идея понятна.
6️⃣ Нулевое или минимальное покрытие тестами
как следствие больших сложных методов и недостаточной инкапсуляции.
7️⃣ Низкий уровень ответственности
Пункт не относится к разработке, но очень актуален для начинающих. Проявляется в двух формах:
🔸 Непонятно, что происходит. Человек сидит и молчит до последнего, пока не спросишь статус задачи или про возможные трудности. Он умалчивает проблемы или переносит на других:
— Что с задачей, которую я тебе дала 3 дня назад?
— Я не понял, куда смотреть, потом меня HR позвал бумаги подписывать, потом я настраивал гит, увидел другую задачу и переключился на неё.
🔸 Код не решает проблему, а заметает симптомы:
— Приходил пустой параметр, и я выставил дефолтный. Тесты мешали сделать пул-реквест, и я их отключил.
8️⃣ Слабые коммуникативные навыки
— Как ты починил баг с расчётом ставки?
— Там через геттер фабричный метод нашёл, и потом докер с постгрёй поднял посмотреть, в логах был фильтр урезанный, я письмо отправил тебе в цц, но вроде скоуп не тот или тот, короче, запушил
— В чём была ошибка?
— Там два двоеточия вылезло
— Где?
— В дебаге
— 🤯
Эти ошибки ожидаемы в начале работы, я тоже их совершала🙂 Чем быстрее вы перестроитесь на командный стиль разработки, тем вероятнее пройдёте испытательный срок и быстрее вольётесь в проект.
Рассмотрим типичную историю начинающего разработчика👶
Чтобы стать программистом, он долго учился. Прошёл много курсов, писал учебные проекты. У них маленькая кодовая база, один пользователь, а главная задача — отработать алгоритм или попробовать фреймворк.
В этих условиях у стажёра сформировался стиль написания кода.
После собеседования стажёр начинает работать в крупном проекте вместе с другими разработчиками. И здесь очень важно перестроиться: многие паттерны, нормальные в учебных проектах, уже не подходят.
В этом посте опишу 8 таких паттернов на простых примерах.
1️⃣ Процедурный стиль
Задача: получить список заказов пользователя. Новичок скорее всего напишет такой код:
List list = new ArrayList();
process(user, list);
Во входной параметр
list потом запишется результат. Такой стиль часто идёт из учебных заданий по алгоритмам, где экономится каждый бит и максимально сокращается количество объектов.В системах со сложной бизнес-логикой такой подход усложняет чтение, тестирование и возможную параллелизацию.
Как лучше: использовать выходные параметры, не менять входные данные, давать осмысленные имена методам:
List orders = getOrders(user);
2️⃣ Сложные универсальные методы
Задача: по-разному считать скидку для новых пользователей и пользователей с картами лояльности.
Новички часто используют принцип Don't Repeat Yourself на максималках и пишут универсальный метод с кучей параметров и десятком if внутри:
getDiscount(user, true, true, limit, true)
Как лучше: сфокусированные методы для разных ситуаций
getDiscountNew(user);
getDiscountLoyal(user, limit)
3️⃣ Длинные методы
Сложно читать и тестировать, страшно менять.
4️⃣ Любовь к статическим методам
Как лучше: небольшие методы, связанные с конкретным классом. Связность ниже, ошибок меньше.
5️⃣ Сложное проектирование
Задача: завести три типа пользователей: новые, обычные и VIP. Новички скорее всего сделают интерфейс, 3 класса и статический класс с фабричными методами и билдером.
Как лучше: как можно проще. Например, один класс пользователя с полем Тип. Усложнять при реальной необходимости
PS Все "как лучше" не всегда лучше. Но думаю, идея понятна.
6️⃣ Нулевое или минимальное покрытие тестами
как следствие больших сложных методов и недостаточной инкапсуляции.
7️⃣ Низкий уровень ответственности
Пункт не относится к разработке, но очень актуален для начинающих. Проявляется в двух формах:
🔸 Непонятно, что происходит. Человек сидит и молчит до последнего, пока не спросишь статус задачи или про возможные трудности. Он умалчивает проблемы или переносит на других:
— Что с задачей, которую я тебе дала 3 дня назад?
— Я не понял, куда смотреть, потом меня HR позвал бумаги подписывать, потом я настраивал гит, увидел другую задачу и переключился на неё.
🔸 Код не решает проблему, а заметает симптомы:
— Приходил пустой параметр, и я выставил дефолтный. Тесты мешали сделать пул-реквест, и я их отключил.
8️⃣ Слабые коммуникативные навыки
— Как ты починил баг с расчётом ставки?
— Там через геттер фабричный метод нашёл, и потом докер с постгрёй поднял посмотреть, в логах был фильтр урезанный, я письмо отправил тебе в цц, но вроде скоуп не тот или тот, короче, запушил
— В чём была ошибка?
— Там два двоеточия вылезло
— Где?
— В дебаге
— 🤯
Эти ошибки ожидаемы в начале работы, я тоже их совершала🙂 Чем быстрее вы перестроитесь на командный стиль разработки, тем вероятнее пройдёте испытательный срок и быстрее вольётесь в проект.