Fatigue Driven Development (FDD)

Привет, меня зовут 👨🏻 Давид Шекунц 👴🏿 и я устал от ночного дебага, я устал от неподдерживаемого кода, я устал от технологий, которые ломаются. Поэтому я пишу эти правила, которые помогают мне больше отдыхать. Надеюсь, и вам тоже помогут.

📖 Словарь

• “Источник данных” – база данных, кэш, сторонний API, короче все, откуда мы достаем или куда отправляем данные.

• Application Interface (API) – способ взаимодействия с запущенным приложением (stdin, stdout, TCP, UDP, )

• “Ручка” (endpoint) – один из методов API (например HTTP API URL, описание команды в gRPC, мутация / запрос / подписка в GQL, etc.)

• Message Broker (MB) – возможность публиковать сообщения (чаще всего по “топикам”) и подписаться на их появление

• Message Queue (MQ) – тоже самое, что и MB, но гарантирует последовательность доставки

• Event Driven Architecture (EDA) – выкидываем “События” (id, название в прошедшем совершенном времени, данные) и потребляем любым числом сервисов.

• CI / CD – автоматизированные процессы, требующиеся для сборки и раскрытия сервисов

• “Инфра” – базы данных, CI/CD, сервера, оркестрация, нетворк и все, все, все

• Orphan data (данные-сироты) – данные, которые имели смысл только при существовании данных, к которым они были привязаны (условно, любые данные на которые мы хотим сделать ON DELETE CASCADE)

• “Проекция” (projection) – readonly данные, высчитанные на основе других данных. Например, мы сохраняем все сообщения с устройства в одну таблицу, а потом из них считаем проекции его текущих и исторических показателей температуры / состояния батареи / местоположения / etc.

• Деградация системы – когда новый функционал ломает старый, считается одним из самых страшных видов ошибок.

• Фича-флаг – булевое значение (true | false), которое вы пробрасываете в код (через env) и в зависимости от того, включено оно или нет, вы включаете или выключаете функционал

• Real-time – системы, предполагающие, обработку и ответ в миллисекундах (максимум в 1-3 секунды)

• Приложение (app) – код, запущенный, как процесс

• Инстанс (instance) – единица запущенного приложения

🍔 App structure

i. Монорепозитори

1. Атомарные деплои – на прод выгрузиться сразу и бэк, и фронт, и код инфры

2. Все в одном месте – даже на 5 репозиториях начинаются проблемы с поиском нужных вещей

3. Shared код – возможность без публикации использовать локальный код между сервисами

1. Development и staging средами, чтобы в первой велась разработка, а во вторую попадали изменения, которые потом пойдут в production

2. Если вам нужно публиковать библиотеки, то обязательно добавьте в CI/CD stage с ручным управлением для их сборки и публикации (из main выпускается основная версия, из development beta, из других веток alfa)

ii. Монолит

1. Одна большая кодовая база

2. Запускается +- в 1 инстансе

1. Позволяет избежать проблем распределенности (кросс-коммуникация и синхронизации состояния)

2. Быстрый деплой

3. Меньше мороки с Инфрой

4. Легче дебажить

1. Все плюсы сверху работают до определенного размера, а после полностью сходят на нет

2. Сложность горизонтального масштабирования

3. Единая точка отказа

4. При отсутствии правил написания кода, превращается в лапшу

iii. Микросервисы

1. Кодовая база отделена друг от друга

2. Уменьшение конкуренции

1. Можно выделить кодовую базу в отдельное место (безопасность, управление)

2. Максимальное горизонтальное масштабирование

1. Ошибка границ ответственности микросервисов намного хуже любого самого жирного монолита

2. Сложность коммуникации и синхронизации состояния в максимуме

3. Сложно деплоить

4. Сложно следить за инфрой

iv. Модульный монолит

1. Переиспользуем туже самую кодовую базу, но запускаем в разных инстансах

2. Используем теже источники данных

1. Все преимущества монолитов, без точки необратимой жирности

2. Все преимущества микросервисов, минус сложность кросс-коммуникации и синхронизации состояния

1. Шеринг ресурсов (например, запросов к БД) может вызвать их перегрузку

2. Сложнее деплоить и поддерживать, чем монолит

3. При отсутствии правил написания кода, превращается в лапшу

v. Что выбрать?

1. Начинайте с модульного монолита, стараясь максимально избегать кросс-сервисной коммуникации

2. Выделяйте что-то в микросервисы по НЕОБХОДИМОСТИ, то есть вы просто увидите, что по-другому вообще никак, тогда выделяете что-то в микросервисы (такой точки может даже не наступить)

vi. FALS – лучшая структура проекта

1. Features – код с бизнес-логикой приложения, разделенная по доменам.

2. Apps – код, запускающий приложение в разных конфигурациях.

3. Libs – код, который мог бы стать приватными или публичными библиотеками.

4. Scripts – код, который нам время от времени хочется запускать с локалки из CI/CD.

/features
	/auth
		login.ts
		register.ts
	/user-management
		get-user.ts
		delete-user.ts

/apps
	/main-http
		/http-api
			schema.ts
		config.ts
		index.ts
	/cron
		index.ts

/libs
	/@my-company
		/specific-lib
			index.ts
	/logger
		index.ts

/scripts
	/inactivate-stale-user
		index.ts

vii. Graceful-shutdown

1. Запустите таймер, который убьет приложение, даже если оно не успело завершиться

2. Закройте API (HTTP, MQ, etc.)

3. Выключите все кроны и интервалы

4. Дождитесь окончания текущих процессов бизнес-логики

5. Закройте внешние соединения (БД, MQ, etc.)

viii. Separate your Cron

🎛️ API

i. RPC

// # Request
{
	id: string
	name: "GetUser",
	params: {
		userId: string
	},
	meta: {
		ts: Date
		requesterId: UUID
		traceId: UUID
	}
}

// # Success Response
{
	id: string // такойже как и в request
	result: {
		case: "success",
		success: {
			email: string
			avatar: string
		}
	}
}

// # Failure Response
{
	id: string // такойже как и в request
	result: {
		case: "failure",
		failure: {
			code: number
			message: string
		}
	}
}

{
	id: string
	name: "UserCreated",
	payload: {
		userId: string
	},
	meta: {
		ts: Date
		requesterId: UUID
		traceId: UUID
	}
}

ii. CQRS

1. Если вы возвращаете данные вы не имеете право менять состояние системы (писать что-либо в БД, кэш, изменять значения переменных)

2. Если вы изменяете состояние системы, вы можете ответить только “ОК” или “Ошибка”

iii. (a)Sync Communication

iv. Schema

1. OpenAPI или GQL для HTTP / MQ / MB / WS

2. Protobuf для gRPC / MQ / MB / WS

v. Push | Pull

vi. Создавайте ID на клиенте

1. Это позволяет в случае получения успеха клиенту самостоятельно запросить нужные данные

2. Легче реализовать потоковые / real-time коммуникацию

3. Позволяет использовать Eventual Consistency

4. Уникальный идентификатор будет также выступать в роли ключа идемпонентности

5. На бэке можно создать сущности, связывать их этим UUID и только после этого записывать в БД (вместо того, чтобы делать запись, получать SERIAL и только после этого создавать следующую связанную сущность)

👴🏿 Типизируй

i. Branded & Nominal Types и валидация на типах

Функционально Ориентированное Программирование (ФОП)

Функционально Ориентированное Программирование (ФОП) – функциональная альтернатива ООП.

https://fop.davidshekunts.ru/#d04ae9b9e8e24f3ab46144f1e8816fc2

ii. Algebraic Data Types (ADT) и Инварианты

Функционально Ориентированное Программирование (ФОП)

Функционально Ориентированное Программирование (ФОП) – функциональная альтернатива ООП.

https://fop.davidshekunts.ru/#d04ae9b9e8e24f3ab46144f1e8816fc2

iii. implements – невероятное зло

// business-logic/some-fn.ts

interface User {
	id: string
	email: string
}

interface UserDataSource {
	getUserById(id: string): User
}

function someLogic(uds: UserDataSource) {
	// ...
}

// databases/pgsql.ts

interface UserTable = {
	id: UUID
	email: string
}

const UserTableService = (conn: PgConnection) => {
	return {
		getUserById(id: string): UserTable => {
			// ...
		}
	}
}

// app/main.ts

const pg = PgConnection()
const userTable = UserTableService(pg)
someLogic(userTable)

iv. I префикс – зло

1. Это семантическая ошибка – вы же не именуете все классы с префиксом C или все цифры с постфиксом Int

2. Таким неймингом вы связываете интерфейс с реализацией, а суть интерфейса именно в том, чтобы отвязать один от другого

interface IPaymentService {
	// ...
}

function extendSubscription(ps: IPaymentService) {
	// ...
}

class User {
	constructor(
	public id: string,
	public email: string
	) {}
}

// Когда вы используете класс User в типизации, на самом деле, вы используете
// его интерфейс
const someFn = (user: User) => {
	// ...
}

// То есть, на деле, класс User состоит из 2-х частей:

// 1. Тип класса
interface User {
	id: string
	email: string
}

// 2. Рантайм класса(условное)
const User = {
	new(id: string, email: string): User => {
		return {id, email }
	}
} 

interface UserRepository = {
	insert(user: User) => void
}

// Реализация на PSQL
class UserRepositoryPostgreSQL {
	insert(user: User): void {}
}

// Реализация на Mongo
class UserRepositoryMongoDB {
	insert(user: User): void {}
}

🐞 Error Handling

i. Classified Errors

// . Сначала базовую ошибку

type BaseError = {
	_isBaseError: true // для простой проверки
	statusCode: number // всегда используйте HTTP Status Code
	type: string // уникальные ключи словаря ошибок (об этом ниже)
	message: string // внутренее описание ошибки
	data: JSON // доп данные
}

// . Первый слой обычно про то доступны ли они внутри или снаружи

type InternalError = BaseError & {
		_isInternalError: true
}

type PublicError = BaseError & {
		_isPublicError: true
		publicMessage: string // вот эту ошибку будем показывать пользователям
}

// . Далее стандартные типы

type ForbiddenError = PublicError & {
	_isForbiddenError: true
	statusCode: 403
}

type NotFoundError = PublicError & {
	_isNotFoundError: true
	statusCode: 404
}

// и так далее

// . Потом ваши специфичные

type SubscriptionEndedError = ForbiddenError & {
	_isSubscriptionEndedError: true
	publicMessage: "Your susbscription ended"
}

type PostsNotFoundError = NotFoundError & {
	_isPostsNotFoundError: true
	publicMessage: "No posts"
}

const errorHandler = (request: Request, error: Error) => {
	if (error._isBaseError) {
		if (error._isPublicError) {
			return request.status(error.statusCode).message(error.publicMessage)
		} else {
			return request.status(500)message("Internal error")
		}
	}
}

ii. Error Dictionary

// errors.json
{
	// ключ – уникальный, а значение любая +- понятная строка
	"user_email_validation_error": "Email is incorrect",
	"value_to_long": "Value too long: ",
	"you_are_not_owner": "You are not owner"
}

iii. Return, not throw

1. Очевидность программы увеличивается в 10-ки раз

2. Можно типизировать возвращающиеся ошибки

3. Упрощается дебагинг

4. Код при обработки ошибок выглядит чище

5. Сложнее забыть обработать все нужные кейсы

🧠 Архитектура

i. Функционально Ориентированное Программирование (ФОП)

ФОП - Функционально Ориентированное Программирование

Функциональная альтернатива ООП ФОП - парадигма программирования, основанная на Процедурном программировании с использованием техник Функционального программирования, разработанная для мультипарадигмальных языков. Для работы с ФОП в вашем языке должно быть всего 2 сущности: Описание структуры данных - описание структур с которыми будут работать наши функции.

https://fop.davidshekunts.ru/101ffcdcef71463c81c9ecf20130d74b

ii. Data Oriented Architecture

Data Oriented Architecture

Функционально Ориентированное Программирование (ФОП) – функциональная альтернатива ООП.

https://fop.davidshekunts.ru/data-oriented-architecture

iii. Dirty vs Clean Architecture

1. Любыми абстракциями бизнес-логики вы увеличиваете Искусственную сложность (ссылочка), а в CA и DDD это возведено в максимум.

2. Код – это слуга данных (БД), а не наоборот, поэтому чем меньше абстракций над данными в вашем коде, тем легче вам будет с ним работать (ссылочка)

3. Если вы создаете программу, так, чтобы можно было поменять условно PG на MongoDB, то ваша программа будет работать хуево, как с одной, так и со второй базой

4. Абстракция над БД сразу предполагает то, что (1) вы не сможете использовать важные фичи конкретной БД, (2) вы не сможете оптимизировать под конкретную БД, (3) вы будете работать неоптимизировано и очень быстро достигнете потолка нужных вам ресурсов

5. Чем больше переиспользуемого кода (например слой Entities) тем больше опасности при добавлении новой фичи / изменении старой, сломать что-то работающее (со временем эта вероятность достигает 100%)

iv. Vertical Slices

1. Мы получаем настоящую независимость кодовых баз, а шансов изменениями в фиче задеть что-то стороннее стремится к нулю

2. Логика, относящаяся к конкретной фиче не загрязняет общую кодовую базу, а находится там, где нужна, а это невероятно помогает в осознании кодовой базы

3. Тестировать такой код намного проще

4. Мы можем легко включать / выключать / переносить фичи в любое место

5. Каждая фича может использовать свои технологии (можно даже поменять Query builder, БД, библиотеку, etc.)

1. Держать 1000 фич в одной папке неудобно, поэтому папки с фичами стоит распределять по папкам доменой области (auth, shop, reports, blog-system, etc.)

2. В рамках доменной области можно иметь переиспользуемые в этой доменной области код

3. А общий переиспользуймый код (например, схема БД) всегда можно оформить как “библиотеку” / SDK, которую будут использовать отдельные фичи

v. Event Driven Architecture (EDA)

1. Event состоит из
1. id: uuid
2. name: string – в прошедшей совершенной форме (UserRegistered , PostCreated, etc.)
3. payload: JSON – содержимое
4. timestamp: UnixTimestamp – время создания
5. traceId: uuid – идентификатор проходящий с самого первого вызова и через все вызовы и события, чтобы собрать картину целиком

2. У событий есть размер
1. S – название + id сущности
2. M – название + полезные данные
3. L – название + все данные
4. XL – название + новые и старые данные

3. В каждом отдельном случае походит свой “размер”, эксперементируйте

4. Если какие-то данные, влияющие на событие или обработчики могут измениться со временем, то засовывайте их в event

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

6. Используйте системы очередей с гарантией доставки и репликацией (например, Kafka)

7. Лучше, если ивенты персистятся (например, как в Kafka), чтобы их можно было перечитать

8. Выучите паттерн Transaction Outbox для очень сложных и опасных операций

9. Для синхронизации состояния используйте Saga или Оркестратор на событиях

10. Никогда не рассчитывайте что событие исполнится в константное время

vi. Say “NO” to master-master

1. Данных слишком много?
1. Попробуйте выделить cold и hot данные, где cold вы архивируете и скидываете на будущее
2. Если данные нужны только для проекции, то скиньте в горизонтально масштабирующиеся OLAP БД (Clickhouse) и удалите из основной БД

2. Не хватает скорости INSERT? Используйте слои батчинга, например, Kafka, в которую скидываете все записи, которые потом будут забатчены и засунуты в итоговые хранилища

3. Слишком долгие UPDATE? Часто можно изменить UPDATE на INSERT или же воспользоваться Event Sourcing / EDA – сохраняем события об изменении, с другого конца аггрегируем и считаем проекции

4. Слишком долгие DELETE? Помечайте данные для удаления (deletedAt) и чистите их 1 раз по крону

vii. Say “yes” to master-slave

viii. Horizontal scaling

1. Потребуется внешнее хранилище для синхронизации состояний (Redis-like)

2. Абсолютно все процессы становятся конкурентными, а значит нужно или уметь распределять (пример, round-robin на очередях) или уметь лочить (Redis-like / etcd-like)

3. Проблема могут возникать только на части интсансов, поэтому в мониторинге ресурсов надо разделять каждый отдельный инстанс

💾 Базы Данных

i. ORM or not

ii. Migration first

1. Написали миграции

2. Накатили на БД

3. Сделали интроспекцию – выгрузка схемы таблиц в типизацию вашего языка и констант (название таблиц, название колонок, etc.)

iii. Optimistic & Pessimistic Concurrency Control

iv. Transactions

1. Read uncommited – читаем данные, которые еще незакомичены (максимальная скорость, минимальная надежность, подходит когда данные которые мы читаем не могут не записаться, например, поскольку у них нет никаких Contraints)

2. Read commited – читаем только закомиченные данные (надежно, просто, работает)

3. Repeatable read – в рамках транзакции при чтении всегда получим теже данные, как если бы читали из snapshot (сложнее, но частых кейс, как например при использовании sub query)

4. Serializable – выстраиваем все транзакции в очередь (минимальная скорость, максимальная надежность, готовимся к дедлокам)

1. Стройте архитектуру так, чтобы минимизировать или не использовать транзакции (а если и использовать то не выше Repeatable read). И да, архитектурные решения способны позволить работать без транзакций.

2. Никогда не задерживайте транзакции – замедление 1 транзакции может привести к каскадному росту и ошибкам во всей системе.

3. Если вам пришлось использовать Serializable, то скорее всего, вы просто поленились / не имеете времени сделать по-другому.

v. Distributed Transactions

vi. Drop Relations

1. ON DELETE CASCADE невероятно опасная конструкция, которая (1) может удалить нужные данные, (2) очень сильно тормозит БД, (3) очень сложно контроллируется и дебажиться. Его можно использовать только при one-to-one, в остальных случаях лучше удалять orphan данные кроном в моменты пониженной нагрузки.

2. Еще чаще вы заметите, что при удалении данных вам не деле не нужно и наоборот вредно удалять связанные с ними данные, тогда ON DELETE CASCADE вообще теряет смысл.

3. ON DELETE / UPDATE … является переносом бизнес-логики на БД, что черевато тонной дебагинга и непонимания “почему это не работает”.

4. FOREIGN KEY для проверки наличия сущности очень часто бесмысленный – если вы получили какой-то id, то чаще всего вам или придется заранее проверить его существование или он точно существует. А даже если нет, то крон из первого пункта в последствии удалит эти данные.

5. Orphan данные чаще всего не будут мешать в ваших выборках, потому что если мы удалили связующие данные, то в стандартных выборках они просто перестанут попадаться (возможно только коллизии в OLAP выборках, но там так и так надо следить за множеством аспектов)

6. Рано или поздно вам придется хранить часть данных в одной БД, а часть в другой и в этот момент вы уже потеряете реляции. А если вы в первую очередь откажитесь от них, то сможете использовать сколько угодно разных баз и в 100 раз проще горизонтально масштабировать свои хранилища.

vii. Drop Constraints

viii. Как выбрать БД

1. Выдержит ли нужный QPS

2. Посмотрите нужные уровни транзакций и атомарности

3. Поверь кол-во доступных коннектов

4. Поверь наличие репликации

5. Проверь подходит ли она для множества маленьких или только большие Insert

6. Есть ли Update

7. Есть ли Upsert

8. Есть ли методы массовой загрузки (например COPY в PG)

9. Как устроен MVCC и GC (чтобы понимать сложность Insert / Update / Delete, а также причины пауз)

10. Какие механизмы дают Optimitic / Pessimistic Concurrency Control

11. Проверь типы чисел, дат, массивов и наличие JSON / неструктурированных типов, а также разные методы работы с ними

12. Поверь наличие нормальных библиотек: адаптер, query builder, мигратор и интроспекция

13. Строковая или колоночная

14. OLAP или OLTP

15. Есть ли CDC

16. Eventual или Strong consistency

17. Если master-master то какой алгоритм консенсуса

18. Требуется ли что-то дополнительное для кластеризация (например, zookeeper, etcd)

ix. Используйте UUID

1. Можно подготавливать множество сущностей в коде, которые связаны друг с другом по id и разом вставлять их в БД (в случае serial, вам пришлось бы вставлять, получать id и только после этого вставлять следующую сущность)

2. Позволяет клиенту отправлять id сущности и после успеха операции запрашивать его отдельными ручками / механизмами (например, получать его из WS)

3. Позволяет использовать отложенную вставку (например, если вы хотите батчить сущности и вставлять их потом, но связанные с ними сущности уже могут появится в БД)

4. Если просуммировать 3 верхних пункта: позволяет строить Eventual Consistency системы

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

x. INSERT-s / UPDATE-s / DELETE-s must be batched

1. Если не персисть сообщения в сторонней системе (например, Kafka) их можно потерять

2. Забатченные сообщения не будут доступны в момент их реального появления

xi. “Хранилища, как луковицы”

1. Установка connection – устанавливаем соединение с клиентом

2. Выделение процессора – выделяем некую единицу, которая будет обрабатывать запрос (процесс в PG, thread в Mysql, goroutine в CockroachDB, thread per core в RedPanda).

3. Процессинг запросов – разобрать присланное сообщение на логические шаги (например, разобрать SQL)

4. Валидация по схеме – проверить, что присланные данные соотносятся со схемой

5. Планирование исполнения – можно ли, в какой последовательности, откуда доставать данные

6. Индексы
1. Проверка – не нарушаем ли мы текущие индексы
2. Создание – создаем новые (особенно стоит отметить атомарность UNIQUE индексов)

7. Конкурентный доступ – например MVCC (создание новых версий записей или rollback журнала)

8. Транзакции – управление транзакциями

9. Commit – утверждение, что операция пройдет успешно вне зависимости от обстоятельств (например, WAL запись или RAFT commit)

10. Ответить мета-данными – иногда требуется заранее ответить клиенту мета-данными, например, о типе возвращаемых данных

11. Персистенция
1. Коммуникация со слоем хранения – иногда это часть инстанса процессинга (PG), а иногда существует отдельно (YDB, TiDB)
2. Компрессия – сжимаем данные
3. Оптимизация хранения – позволяет
4. Батчинг – агрегация данных в памяти, для дальнейшего flush
5. Flush – выгрузка из памяти на диск

12. Чистка – в большинстве систем хранения будет тот или иной механизм очистки, например, VACUUM в PG или удаление секторов в Kafka

13. Кластеризация
1. Membership – обнаружение и присоеденение к кластеру
2. Leadership – определиние лидеров
3. Health-checks – проверка доступности компонент кластера
4. Anti split-brain – предотвращение Split-brain
5. Recovery – восстановление после отделения от кластера
6. Rehydration – восстановление данных до нужного уровня
7. Синхронизация конфигурации – синхронизация итогового состояния конфигурации кластера и отдельных узлов
8. Синхронизация индексов – синхронизируем индексы
9. Синхронизация данных – синхронизируем сами данные
10. Master-Slave репликация – реплицируем данные для дальнейшего чтения

14. Партицирование
1. Локальное – разделяем большие master таблицы на более маленькие по ключу в рамках 1 инстанса для оптимизации работы с IO
2. Шардирование – разделение и хранение master таблиц на разных инстансах

15. Бэкапы – некоторые хранилища умеют в автоматический бэкап горячих / холодных данных, например, в S3 (TimescaleDB, Redpanda)

xii. Event bus

1. Практически всегда в первую очередь вам нужно будет персистентное хранилище наподобие Kafka:
1. Это дает возможность обрабатывать сообщения батчами
2. Перечитывать сообщения при необходимости инвалидации
3. Писать за среднестатистически константное время
4. Иметь горизонтальное масштабирование

2. Если же вы готовы пожертвовать надежностью доставки и персистенцией во имя скорости, то используйте Message Broker (NATS.io / EMQX)

🔎 Тестирование

i. Общее

1. Бизнес-логику тестируем абсолютно всегда, все остальное по желанию

2. Если функция не использует инфру, то пишем юнит тесты

3. Во всех остальных случаях всегда пишем интеграционные тесты

4. Тесты – это просто (надо только научиться их разворачивать)

5. Тесты – это дополнительный час кодинга, сохранивший тебе 10 часов сна

6. Сколько тестов нужно написать на функцию? Один, дальше по желанию

7. Когда нашли баг, напиши сначала тест, чтобы его воспроизвести, потом решай баг

ii. Юнит, Интеграционные, E2E тесты

1. Юнит тесты – тестируем без окружения (БД, кэшей, API, etc.), то есть все интеграции заменяем на моки, тесты являются частью кода.

2. Интеграционные тесты – раскрываем интеграции (БД, кэшей, API, etc.) под тесты, тесты являются частью кода.

3. E2E – раскрываем полное приложение со всеми интеграциями и дергаем его API, тесты являются отдельной кодовой базой.

iii. Интеграционные тесты

1. Скрипт запуска можно написать в Makefile

2. Перед запуском тестов поднимите локальное окружение (лучше через docker-compose)

3. Дождитесь запуска

4. Накатите миграции и фикстуры

5. Перед каждым тестом делайте снепшот БД

6. На каждый тест делайте отдельное соединение

7. После каждого удаляйте снепшот и закрывайте соединение

8. В конце тестов НЕ закрывайте окружение

🌎 Логгирование, метрики, трейсинг

i. Метрики – ваше паучье чутью, Тресы – ваша карта, Логи – ваши глаза

1. На большом объеме единственный способ видеть, что все (не)ок – только метрики

2. Второстепенным инструментом является трейсинг

3. И только в последнюю очередь для уточнения деталей мы используем логгирование

ii. Мета-инфа логов

1. Добавляйте commit hash

2. Level

3. Название сервиса

4. Уникальный id

5. Время старта сервиса

6. Стэк вызова функций

7. ID запроса

8. Trace ID

iii. Техническое

1. Используете логгеры с нулевыми аллокациями

2. Пишите в stdout

3. Проверьте что логгер пишет асснихронно

👨‍👧‍👦 Leading

i. Триптих – идеальная структура тех. команды

• Team lead (уши и рот) – единая входная точка для бизнеса, которая отвечает за сроки поставки решений и технический бэклог и состояние команды, создает условия для работы Senior и Middle

• Senior (мозг) – отвечает за качество и работоспособность всей системы, а значит: принимает технические решения, имеет право вето, тушит пожары, создает технические условия для работы Middle

• Middle (руки) – отвественный за работоспособность, написанного им кода: согласует решения с Senior, пилит фичи и проверяет что они работают

• Я назвал их "Team lead", "Senior" и "Middle", потому что нет более подходящих слов (кроме тех, что в скобочках), на самом деле на роли "Middle" может быть человек уровня "Senior"

• Это РОЛИ, а значит их может в себе совмещать в себе один и тот же человек

• При этом Team Lead и Senior должно быть максимум по одному, а вот Middle может быть много, но в идеале в пределах 10-ти

• Team Lead может не иметь технических навыков (таких я назыаю PM, но это не снимает с них ответственности, описанной выше)

• Я намеренно не включал QA, DevOps, CTO, Архитектор, etc. потому что это или может переиспользовать написанное выше, или более гипербализированная версия (например, CTO это Team Lead, только который еще и за ФОТ отвечает)

• Решения ставновятся (не)правильными только после того, как вы их применили, поэтому кто-то должен просто брать на себя ответственность за то, чтобы выбрать какой-то путь и ждать результата. Если такое решение будут пытаться утвердить несколько человек, то у них возникнут большие проблемы, соответственно, капитан (Senior) должен быть всего один.

• Коммуникация с бизнесом – боль. Ее бывает невероятно много. Причем как и на вход в команду, так и на выход. Одновременно с этим, бизнес очень часто не умеет общаться с разрабами и наоборот, поэтому пускать их друг к другу на постоянной основе точно не стоит. Их можно знакомить и оставлять на какое-то время (создание фичи), но вся коммуникация и ответственность должна быть в одних руках (Team Lead)

• Senior дополняют Middle, а Middle дополняют Senior: Middle может получить все нужные ему знания, Senior может реализовать себя как "сенсей" и при этом сам научиться, структурировав свои знания во время передачи их Middle разработчику. Такой Уроборос позволяют им обоим расти и получать от этого удовольтвие. Два Senior разработчика могут (для начала, разосраться, но это я выше писал, поэтому в данной ситуации) задавать друг другу слишом мало вопросов (например, из-за стеснения) и пилить какую-нибудь невероятную херь просто потому что не решились ее заранее обсудить (это в целом про зрелось, но это отдельный топик)

• Открыто и явно проговорить кто какую роль на себя берет и чтобы Senior явно передали права на решения по бизнес-части Team Lead, а Middle явно передали права за технические решения Senior

• Установить хорошую, открытую и постоянную коммуникацию между всеми этими звеньями

• Дать возможность Senior делать технические решения и нанимать людей в соответствии с ними

• Если у Team Lead плохо прокачаны Soft skills и нет "стальных яиц" с умением говорить "нет" как разрабам, так и бизнесу, все будут выгорать, будет страдать бизнес и начнется текучка

• Если выбрать плохого Senior, то он поведет всю команду в бездну, при этом если не дать Senior право принимать опасные решения, то хороший Senior тоже ничего не способен будет сделать

• Если Senior не готовы слушать Middle-ов или Middle-ы соглашаться с итоговыми решениями Senior схема не сработает, поэтому именно Senior должен собирать команду

💻 Программирование

i. Абсолютно все конкурентно

ii. Избегай Mutex

iii. Программируй так, как будто все уже сломалось

1. Если у вас есть state-machine, не забудьте написать крон, который будет доводить подвисшие state-machine до какого-либо состояния.

2. Если есть набор данных, которые должны быть записаны вместе или не записаны вообще, то используйте (1) заранее проведите все операции над сущностями и в конце запишите одной атомарной операцией, (2) объедините эти данные в одну таблицу / сообщение в очередь (и если надо будет их разъеденять, делайте это отдельным процессом), (3) создайте и запустить state-machine (рано или поздно она сделает то, что нужно), (4) используйте транзакции.

3. Если вам нужны данные в моменте времени, то пишите их как только смогли собрать воедино, НО озаботьтесь, чтобы запись была идемпонентна (то есть, если в этуже логику кода попадут теже самые входные данные, она не сделала двойной записи)

4. Вам может повезти и приложение будет падать с SIGINT или SIGTERM, поэтому озаботьтесь написанием graceful-shutdown.

iv. И многое, многое другое

(λ) Функционально Ориентированное Программирование (ФОП)

Функционально Ориентированное Программирование (ФОП) – функциональная альтернатива ООП.

https://fop.davidshekunts.ru/#dd250ed82406451f9dc45525d34b045a

👨🏻 Об авторе

 

Привет! Меня зовут Давид Шекунц и я Full-Stack Tech Lead на JS & Go (рассказываю про разработку в 🦾 IT-Качалке 💪)

 

Сайт: about-me.davidshekunts.ru

Тг: t.me/davidshekunts