3.1. Гибкость – важнейшее свойство кода

Цикл проекта

Почему я описываю их отдельно создание и развитие?

Если вы быстро создали систему, которая потом требует дней рефакторинга, чтобы добавить новую фичу, НЕ отвечающую первоначальным требованиям, значит ваша система некачественная (негибкая).

Но как мы можем достичь гибкости?

От “Искусственной сложности” мы можем избавиться, если откажемся от абстракций, группировок и неочевидного поведения.

Как на практике “отказаться от абстракций, группировок и неочевидного поведения”

• Не пытайтесь абстрагироваться от инфраструктуры, если на то нет железобетонных причин. Если вы используете конкретную библиотеку / БД / MQ / etc. не пытайтесь создать поверх них дополнительные интерфейсы, используйте их в тех местах кода так, как вам нужно.

// # Вместо создания абстрактных репозиториев
const changeUserEmail = async (userRepostoty: UserRepository, req: { email: string }) => {
	const user = await userRepository.getByEmail(req.email)
	// ...
}

// # Используйте напрямую в коде вызов адаптера
// или сам язык запросов (например, SQL)
const registerUser = async (pg: PgConnection, req: { email: string }) => {
	const user = await pg.table(UserTableName).where({ email: req.email })
	// ...
}

• Модели должны выглядеть прям так, как лежат в БД. Если в модели не лежит другая модель (например, как jsonb поле PostgreSQL, или вложенный документ MongoDB), то не нужно в описании структуры их вкладывать (просто добавь именно те поля, которые есть в БД), так как это принято во многих ORM. Описывайте все сущности прямо так, как они лежат в БД.

// # Если у вас, например PostgreSQL, то вместо:
type Profile = {
	id: string
	user: User
}

// # пишите прям как в БД
type Profile = {
	id: string
	user_id: string // Потому что там лежит не целый пользователь в виде jsonb, а лишь ссылка на таблицу
}

• Не используйте дополнительных механик работы с зависимостями. Чтобы передавать зависимости в коде, у вас есть аргументы функций / конструктор класса, используйте его, без дополнительной магии типа IoC.

• Минимизируйте side-effects и неочевидное поведение. Например, существуют такие фишки, как preSave, postInsert , preUpdate хуки, так вот, все, что будет происходить внутри них абсолютно неочевидно для разработчика, который не прочитал их содержимое. Это на 100% рано или поздно приведет к очень тяжело отслеживаемым багам и проблемам в сетапе новых разрабов. Достаточно было просто создать функции, которые занимаются созданием / изменением модели и вызывать их, что позволило бы явно видеть, что происходит при вызове этой функции.

• Разделяйте все и полностью. Это очень сложная мысль, но подумайте: если вы разделите свой код на UserController и ProfileController, а потом появится метод, который связан с ними обоими, куда вы его засунете? От этого решения будет очень сильно зависеть вся дальнейшая логика. Хуже, когда такое происходит сразу с тремя сущностями. Поэтому, вместо того, чтобы пытаться делить методы на какие-то группировки, пишите каждый метод отдельно друг от друга, условно: UpdateUserData , SetEmailOnProfile, DeleteUserAndProfile и так далее.

// # Вместо
const ProfileController = {
	setEmail: (req: Request) => {},
	deleteUserAndProfile: (req: Request) => {},
}

// # Разделяем на отдельные ручки
const SetProfileEmail = (req: Request) => {}

const DeleteUserAndProfile = (req: Request) => {}

“Где я своим кодом создаю абстракции, группирую логику или запускаю код без явного его объявления?” – найти эти места и избавиться от них.

Что дальше?