8 ошибок начинающих разработчиков Рассмотрим типичную историю | Java: fill the gaps

8 ошибок начинающих разработчиков

Рассмотрим типичную историю начинающего разработчика или стажёра.

Чтобы стать программистом, стажёр долго учился. Прошёл курсы и сделал несколько учебных проектов. У них маленькая кодовая база, один пользователь, а главная задача - отработать алгоритм или попробовать фреймворк.

В этих условиях у стажёра сформировался стиль написания кода.

После собеседования стажёр начинает работать в крупном проекте вместе с другими разработчиками. Ему нужно перестроиться: многие паттерны, нормальные в учебных проектах, уже не подходят.

В этом посте я опишу 8 таких паттернов на простых примерах.

Изменение входных параметров

Задача: получить список заказов пользователя. Новичок скорее всего напишет такой код:

List list = new ArrayList();
process(user, list);

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

В системах со сложной бизнес-логикой такой подход усложняет чтение кода, тестирование и возможную параллелизацию.

Как лучше: использовать выходные параметры, не менять входные данные, давать осмысленные имена методам:

List orders = getOrders(user);

Сложные универсальные методы

Задача: по-разному считать скидку для новых пользователей и пользователей с картами лояльности.

Новички часто используют принцип Don't Repeat Yourself на максималках и пишут универсальный метод с кучей параметров и десятком if внутри:

getDiscount(user, true, true, limit, true)

Как лучше: сфокусированные методы для разных ситуаций

getDiscountNew(user)
getDiscountLoyal(user)

К ситуациям выше в комплекте идут

Длинные методы
Любовь к статическим методам

Как лучше: небольшие методы, связанные с конкретным классом. Связность ниже, ошибок меньше.

Сложное проектирование

Задача: завести три типа пользователей - новые, обычные и привилегированные. Новички скорее всего сделают интерфейс, 3 класса и статический класс с фабричными методами и билдером.

Как лучше: как можно проще. Например, один класс пользователя с полем Тип.

PS Все предложенные "как лучше" не всегда лучше. Но думаю, вы поняли идею.

Нулевое или минимальное покрытие тестами
как следствие больших сложных методов и недостаточной инкапсуляции.

Низкий уровень ответственности

Пункт не относится к разработке, но очень актуален для начинающих. Проявляется в двух формах:

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

— Что с задачей, которую я тебе дала 3 дня назад?
— Я не понял, куда смотреть, потом меня HR позвал бумаги подписывать, потом я настраивал гит, увидел другую задачу и переключился на неё.

Код не решает проблему, а заметает симптомы:

— Тесты мешали сделать пул-реквест, так что я их отключил.

Слабые коммуникативные навыки

— Как ты починил баг с расчётом ставки?
— Там через геттер фабричный метод нашёл, и потом докер с постгрёй поднял посмотреть, в логах был фильтр урезанный, я письмо отправил тебе в цц, но вроде скоуп не тот или тот, короче, запушил
— В чём была ошибка?
— Там два двоеточия вылезло
— Где?
— В дебаге

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