Кто знает что такое Temporal и кто использует? Возможно, я скоро Вас приятно удивлю 🔥

Я теперь официально сертифицированный Продакт 🔥

Кто сегодня на pycon, делитесь инсайдами 🔥

🚀 Полный список 12 практик экстремального программирования (XP) из книги Кента Бека "Экстремальное программирование:

1️⃣ Тестирование (Testing)
➖ Автоматизированные модульные тесты (TDD).
➖ Приемочные тесты (заказчиком).
2️⃣ Парное программирование (Pair Programming)
➖ Два программиста за одним компьютером: один пишет код ("водитель"), другой анализирует ("наблюдатель").
3️⃣ Непрерывная интеграция (Continuous Integration)
➖ Частое слияние кода в основную ветку (несколько раз в день) с запуском всех тестов.
4️⃣ Рефакторинг (Refactoring)
➖ Постоянное улучшение внутренней структуры кода без изменения внешнего поведения.
5️⃣ Простота дизайна (Simple Design)
➖ Дизайн системы должен быть максимально простым для текущих требований (без избыточности).
6️⃣ Коллективное владение кодом (Collective Code Ownership)
➖ Любой член команды может изменять любой код в проекте в любое время.
7️⃣ Планирование игр (Planning Game)
➖ Короткие итеративные встречи команды и заказчика для оценки, приоритизации задач и планирования релизов.
8️⃣ Короткие циклы выпуска (Small Releases)
➖ Частые поставки работающей системы заказчику (каждые 1–3 недели), начиная с самого ценного функционала.
9️⃣ Метафора системы (System Metaphor)
➖ Общее, простое описание архитектуры системы (например, "конвейер", "магазин"), упрощающее коммуникацию.
🔟 40-часовая рабочая неделя (Sustainable Pace)
➖ Отказ от переработок для поддержания постоянной продуктивности и избежания выгорания.
1️⃣1️⃣ Заказчик рядом (On-Site Customer)
➖ Постоянное присутствие реального представителя заказчика в команде для уточнения требований и приоритетов.
1️⃣2️⃣ Стандарты кодирования (Coding Standards)
➖ Единые, согласованные правила оформления кода, чтобы любой код выглядел так, словно его писал один человек.

🚀Если вы думаете как делать тесты, вот вам простой жизненный совет:
1️⃣ Пишем интеграционные - больше покрытие, тестируем работу API или UseCases.
2️⃣ Что не захватывается интеграционными, пишем UnitTest’ы
3️⃣ В библиотеках, если они у вас есть - пишем только UnitTest’ы
4️⃣ Тестируем вход-выход, а не состояние системы.
5️⃣ Ничего не мокаем, кроме http вызовов в другие сервисы (мокаем https.request), репозиторий не мокаем
6️⃣ Контракты с другими внешними системами не тестируем
7️⃣ Хрупкий тест - плохой тест
8️⃣ Каждый тест должен быть идеимпотентный
9️⃣ Если у вас много сервисов и все они одинаковые, нужно делать общий тулинг для тестов как pytest_plugins

Ну, а вообще, систему без ошибок не написать, но есть и другое правило: нормально делай, нормально будет :)
Каждая новая доработка стремиться замедлить и загасить систему, тесты позволяют этого не допустить 🙏