TGM в Fintech. Go, архитектура, backend, управление командами и реальные кейсы.
Аналитик и тимлид тащат проект в две каски.
Аналитик собирает функциональные требования (ФТ) и нефункциональные требования (НФТ), проектирует интеграции, ведёт проект и согласует ожидаемый результат. Когда перестаёт вывозить, НФТ и интеграции забирает тимлид.
Ты уже устал, но ещё можешь поработать. Этого почему-то хватает, чтобы снова отложить отдых.
Закрыть ноутбук неудобно: у разработчика вопрос, задача почти готова, завтра спросят результат. А прогулку перенести легко. Сон тоже.
Пусть в памяти есть миллион строк. Уникальных — тысяч десять. Остальное — одни и те же значения, которые ты хранишь снова и снова. В Go для таких случаев есть пакет unique, который многие разработчики почему-то игнорируют.
«Переписать сервис», «попробовать новую БД», «почитать книгу». Свалил всё в список задач, расставил сроки. Теперь ругаешь себя, что ничего не успеваешь.
Тебя тоже бесит, когда аналитик или менеджер ставит задачу так, что ничего не понятно? Вот решил поразмышлять о постановке задач. И начать с неприятного: проверь свои тикеты. Возможно, коллеги читают их с тем же выражением лица.
Допустим, в Jira прилетает «Доработать возвраты». Ты полез в API, менеджер ждёт кнопку в админке. До демо оба довол…
Открываешь задачи на день. Посмотреть PR, подготовить 1:1, разобраться с таймаутами, согласовать архитектуру. Ещё в чате просят «быстро глянуть».
Выглядит нелогично: процессор свободен, а приложение стоит. Но для контейнера этого CPU уже нет — он исчерпал заданный ему лимит.
Сейчас можно открыть Cursor, Claude Code или ChatGPT, написать:
Можно идеально разложить миллиард ключей по 100 Redis-нодам и всё равно получить деградацию из-за одного merchant:123. Если один клиент внезапно начинает генерировать 500 000 RPS, средняя загрузка кластера может выглядеть прекрасно ровно до того момента, когда один shard упрётся в CPU и сеть.
На самом деле для этого не нужен ни запасной чемоданчик, ни человек с ключом под матрасом. Есть алгоритм, который позволяет разделить один секрет между несколькими людьми так, чтобы для его восстановления понадобилась только определённая часть из них.