Немного о том, что значит быть сеньором

В начале апреля мы провели митап [из Middle в Senior]. После основной программы Павел Вейник и Светлана Семёнова еще час отвечали на вопросы участников. Публикуем некоторые из ответов:

❓Как сеньору брать ответственность?

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

Сеньоры — это промежуточное звено между бизнесом и разработкой, командами. Чаще эту роль выполняют техлиды, но и сеньоры тоже.

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

❓Что важнее: знания о том, как все работает под капотом, или понимание архитектуры и структуры приложения?

Нет противопоставления между знанием, как всё работает (фреймворк или база данных), и пониманием архитектуры, потому что архитектура одна, принципы одни и те же и в фреймворке, и в приложении. Например, когда я думаю про фреймворк и знаю, какие задачи он исполняет, я могу представить, как бы я это реализовал, а затем удостовериться, что в документации фреймворка это примерно так и описано.

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

Архитектура фреймворков или баз данных органически вписывается в структуру и архитектуру всего приложения.

❓Как находить время на профессиональное развитие, при этом соблюдая нормальный work/life balance?

Я рекомендую совмещать какие-то дела. Среди моих друзей и коллег распространена практика: куда-то идут — включают что-то фоном и слушают; занимаются на беговой дорожке или в тренажёрном зале в наушниках; вечером, занимаясь бытовыми делами, также параллельно слушают полезные материалы. Это уже движение в сторону роста, как минимум.

А как максимум — это реально брать и несколько раз в неделю, два-три раза, без насилия над собой выделять время на обучение.

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

❓Почему бы сеньору не стать бизнесменом?

Сеньоры вполне могут стать основателями своих компаний или стартапов, и становятся. Ошибаются, зарабатывают, возвращаются снова в работу сеньора. Сеньор — это специалист по техническим вопросам, который умеет работать в команде и организации.

У сеньора уже достаточно технических навыков, чтобы делать свои pet-проекты, публиковать их в сторы, пробовать запускать их и привлекать пользователей.

Если что-то получается и "выстреливает", тогда они становятся бизнесменами. Если нет — продолжают комфортно работать на найме. В первую очередь сеньоры — это технари, и они не занимаются организационными вопросами. Более того, обычно сеньорам это не нравится, и они предпочитают перекладывать такие задачи на тимлидов.

Event Sourcing: что это, зачем нужно и когда применять?

Это выдержка из очень крутого доклада Димы Королева, который он представил в рамках Software Craftsmanship Meetup #24 в прошлом году. Если еще не видели – запись вы найдете у нас на YouTube. Там ещё много интересного – подписывайтесь!

Event Sourcing — это архитектурный подход, при котором состояние приложения сохраняется не в виде итоговых данных, а в виде последовательности неизменяемых событий (events).

Вместо того чтобы изменять записи в базе данных напрямую, каждое изменение фиксируется как отдельное событие в журнале событий (Event Log). Таким образом, текущее состояние системы можно восстановить, последовательно проиграв все события из этого журнала, начиная с самого первого.

Зачем нужен Event Sourcing?

Event Sourcing помогает решать проблемы консистентности данных в распределенных системах. Особенно это актуально в микросервисной архитектуре, когда множество независимых сервисов взаимодействуют друг с другом и необходимо поддерживать логическую согласованность данных. Такой подход обеспечивает:

👉 Полную прослеживаемость изменений состояния (auditability).
👉 Возможность восстановления состояния на любой момент времени (time travel).
👉 Гарантии согласованности данных между различными сервисами.
👉 Простоту интеграции с аналитическими системами и построения сложных отчетов.
👉 Удобство масштабирования, так как разделяются операции чтения и записи (CQRS).

Когда стоит применять Event Sourcing, а когда лучше обойтись без него?

Event Sourcing стоит применять, когда:

✅ У вас сложная распределенная система с высокими требованиями к согласованности и надежности данных.
✅ Крайне важна прослеживаемость и история изменений.
✅ Необходимо легко масштабировать нагрузку на чтение и запись.
✅ Требуются сложные компенсационные транзакции (например, при финансовых операциях).

Лучше обойтись без Event Sourcing, когда:

❌ Система простая, монолитная и не требует строгих гарантий консистентности.
❌ Объемы данных небольшие, и требования к аудиту изменений минимальны.
❌Компания не готова к значительным изменениям в организации разработки и подходах к работе с данными.

Что лучше применять, если организация еще не доросла до Event Sourcing?

Если организация еще не готова к переходу на Event Sourcing, лучше использовать подходы, которые проще реализовать и поддерживать, но при этом помогут обеспечить достаточный уровень консистентности данных:

🔸 Реляционные базы данных (RDBMS):
Хорошо подходят, если транзакции ограничены рамками одной базы данных. Гарантии атомарности и транзакционности помогают избежать значительных проблем с консистентностью.

🔸 Компенсирующие транзакции (саги):
Можно использовать для поддержания приемлемого уровня консистентности в распределенных системах без полной перестройки архитектуры. Однако следует помнить, что это более сложный и подверженный ошибкам подход.

🔸 CDC (Change Data Capture):
Позволяет использовать текущие системы и минимально изменять архитектуру, сохраняя возможность отслеживать изменения данных. Хорошо подходит, когда требуется синхронизировать данные между несколькими сервисами или базами без кардинального изменения инфраструктуры.