现已上线！2025 年 Telegram 研究 — 年度关键洞察 
S0ER
前往频道在 Telegram
Архитектура | Программирование | Профессиональное развитие Соер.Клуб - https://t.me/soer_live По всем вопросам писать на @soerdev
显示更多📈 Telegram 频道 S0ER 的分析概览
频道 S0ER (@softwareengineervlog) 俄语 语言赛道中的 是活跃参与者。目前社区聚集了 10 511 名订阅者，在 技术与应用 类别中位列第 11 614，并在 俄罗斯 地区排名第 61 742 位。
📊 受众指标与增长动态
自 невідомо 创建以来，项目保持高速增长，吸引了 10 511 名订阅者。
根据 29 六月, 2026 的最新数据，频道保持稳定运转。过去 30 天订阅人数变化为 -52，过去 24 小时变化为 0，整体触达仍然可观。
- 认证状态： 未认证
- 互动率 (ER)： 平均受众互动率为 25.18%。内容发布后 24 小时内通常能获得 N/A% 的反应，占订阅者总量。
- 帖子覆盖： 每篇帖子平均可获得 2 647 次浏览，首日通常累积 0 次浏览。
- 互动与反馈： 受众积极参与，单帖平均反应数为 56。
- 主题关注点： 内容集中在 rbp, архитектура, callme, mov, указатель 等核心主题上。
📝 描述与内容策略
作者将该频道定位为表达主观观点的平台：
“Архитектура | Программирование | Профессиональное развитие
Соер.Клуб - https://t.me/soer_live
По всем вопросам писать на @soerdev”
凭借高频更新（最新数据采集于 30 六月, 2026），频道始终保持新鲜度与高覆盖。分析显示受众积极互动，使其成为 技术与应用 类别中的关键影响点。
10 511
订阅者
无数据24 小时
-137 天
-5230 天
数据加载中...
相似频道
标签云
进出提及
---
---
---
---
---
---
吸引订阅者
六月 '26
六月 '26
+23
在0个频道中
五月 '26
+77
在0个频道中
Get PRO
四月 '26
+41
在0个频道中
Get PRO
三月 '26
+127
在0个频道中
Get PRO
二月 '26
+159
在2个频道中
Get PRO
一月 '26
+42
在0个频道中
Get PRO
十二月 '25
+37
在2个频道中
Get PRO
十一月 '25
+27
在0个频道中
Get PRO
十月 '25
+31
在0个频道中
Get PRO
九月 '25
+37
在0个频道中
Get PRO
八月 '25
+53
在3个频道中
Get PRO
七月 '25
+51
在3个频道中
Get PRO
六月 '25
+48
在0个频道中
Get PRO
五月 '25
+41
在2个频道中
Get PRO
四月 '25
+54
在0个频道中
Get PRO
三月 '25
+108
在1个频道中
Get PRO
二月 '25
+110
在0个频道中
Get PRO
一月 '25
+56
在1个频道中
Get PRO
十二月 '24
+151
在5个频道中
Get PRO
十一月 '24
+203
在4个频道中
Get PRO
十月 '24
+81
在0个频道中
Get PRO
九月 '24
+125
在2个频道中
Get PRO
八月 '24
+171
在2个频道中
Get PRO
七月 '24
+244
在5个频道中
Get PRO
六月 '24
+164
在5个频道中
Get PRO
五月 '24
+245
在4个频道中
Get PRO
四月 '24
+198
在5个频道中
Get PRO
三月 '24
+211
在5个频道中
Get PRO
二月 '24
+307
在2个频道中
Get PRO
一月 '24
+323
在4个频道中
Get PRO
十二月 '23
+907
在4个频道中
Get PRO
十一月 '23
+190
在3个频道中
Get PRO
十月 '23
+218
在2个频道中
Get PRO
九月 '23
+173
在0个频道中
Get PRO
八月 '23
+247
在0个频道中
Get PRO
七月 '23
+273
在0个频道中
Get PRO
六月 '23
+195
在0个频道中
Get PRO
五月 '23
+2 925
在0个频道中
Get PRO
四月 '23
+397
在0个频道中
Get PRO
三月 '23
+321
在0个频道中
Get PRO
二月 '23
+221
在0个频道中
Get PRO
一月 '23
+798
在0个频道中
Get PRO
十二月 '22
+385
在0个频道中
Get PRO
十一月 '22
+229
在0个频道中
Get PRO
十月 '22
+645
在0个频道中
Get PRO
九月 '22
+208
在0个频道中
Get PRO
八月 '22
+153
在0个频道中
Get PRO
七月 '22
+186
在0个频道中
Get PRO
六月 '22
+241
在0个频道中
Get PRO
五月 '22
+402
在0个频道中
Get PRO
四月 '22
+1 176
在0个频道中
Get PRO
三月 '22
+2 018
在0个频道中
Get PRO
二月 '22
+25
在0个频道中
Get PRO
一月 '22
+41
在0个频道中
Get PRO
十二月 '21
+60
在0个频道中
Get PRO
十一月 '21
+26
在0个频道中
Get PRO
十月 '21
+63
在0个频道中
Get PRO
九月 '21
+375
在0个频道中
Get PRO
八月 '21
+185
在0个频道中
Get PRO
七月 '21
+122
在0个频道中
Get PRO
六月 '21
+20
在0个频道中
Get PRO
五月 '21
+35
在0个频道中
Get PRO
四月 '21
+61
在0个频道中
Get PRO
三月 '21
+40
在0个频道中
Get PRO
二月 '21
+39
在0个频道中
Get PRO
一月 '21
+41
在0个频道中
Get PRO
十二月 '20
+1 613
在0个频道中
| 日期 | 订阅者增长 | 提及 | 频道 | |
| 30 六月 | 0 | |||
| 29 六月 | +1 | |||
| 28 六月 | 0 | |||
| 27 六月 | 0 | |||
| 26 六月 | 0 | |||
| 25 六月 | +1 | |||
| 24 六月 | 0 | |||
| 23 六月 | 0 | |||
| 22 六月 | +2 | |||
| 21 六月 | 0 | |||
| 20 六月 | +2 | |||
| 19 六月 | +1 | |||
| 18 六月 | +2 | |||
| 17 六月 | +1 | |||
| 16 六月 | +1 | |||
| 15 六月 | 0 | |||
| 14 六月 | +1 | |||
| 13 六月 | +1 | |||
| 12 六月 | +1 | |||
| 11 六月 | +2 | |||
| 10 六月 | +1 | |||
| 09 六月 | 0 | |||
| 08 六月 | 0 | |||
| 07 六月 | 0 | |||
| 06 六月 | +1 | |||
| 05 六月 | +3 | |||
| 04 六月 | +2 | |||
| 03 六月 | 0 | |||
| 02 六月 | 0 | |||
| 01 六月 | 0 |
频道帖子
await this.progressRepository.create({ userId, lessonId, status: "started", startedAt: new Date() })
this.analyticsService.track("lesson_started", { userId, lessonId })
.catch(err => this.logger.error("Analytics failed", err))
}
`
Стал ли код лучше? И да, и нет. Первый вариант по-прежнему остается самым читаемым, понятным и простым. Но на перспективу иметь разделение обязанностей и четкие границы между слоями - это очевидный плюс.
Получается три разных варианта, все рабочие. Но какой из них подойдет в конкретной ситуации - это решение, которое должен принять разработчик. Реальное программирование - это всегда компромисс между надёжностью, универсальностью и простотой.
Важно помнить, что как программисты, мы всегда можем объяснить, какие проблемы есть в коде, какие опасности они создают. Но насколько эти "проблемы" реальны - сказать сложно. И никто не знает, какой выбор нужно сделать. Знаю только, что через год-два открою этот код и не вспомню, почему выбрал именно так. И, скорее всего, нужно будет объяснять проблемы и переписывать... Опять.| 2 | Три варианта. Один выбор.
Допустим, у нас есть задача реализовать user story:
Как пользователь платформы, я хочу начать урок, чтобы продолжить обучение и потратить накопленные токены.
Наивная реализация на TypeScript + NestJS могла бы выглядеть как-то так:
async startLesson(userId: string, lessonId: string) {
const user = await this.userRepository.findById(userId)
const lesson = await this.lessonRepository.findById(lessonId)
const subscription = await this.subscriptionRepository.findActiveByUser(userId)
if (!subscription || subscription.expiresAt < new Date()) {
throw new Error("No active subscription")
}
if (user.tokens < lesson.tokensCost) {
throw new Error("Not enough tokens")
}
await this.userRepository.update(userId, { tokens: user.tokens - lesson.tokensCost })
await this.progressRepository.create({ userId, lessonId, status: "started", startedAt: new Date() })
await this.analyticsService.track("lesson_started", { userId, lessonId })
}
Код рабочий и простой. Но насколько он хорош? Остановитесь на секунду и назовите 2-3 потенциальные проблемы этого кода. Я нашел сразу пять:
- Проверка подписки здесь, хотя должна быть в отдельном слое доступа.
- Списание токенов не атомарное - между проверкой и обновлением токены может списать другой запрос.
- Нет транзакции - если сервер упал между update и create, токены списались, а прогресс не создался.
- Аналитика блокирует основной поток.
- Нет уникального индекса на прогресс.
Учитывая эти моменты, можно сделать более надёжную реализацию:
async startLesson(userId: string, lessonId: string) {
return this.unitOfWork.execute(async (uow) => {
const user = await uow.users.findById(userId)
const lesson = await uow.lessons.findById(lessonId)
if (!user || !lesson) {
throw new Error("User or lesson not found")
}
const accessResult = await this.accessService.checkAccess(user, lesson)
if (!accessResult.allowed) {
throw new Error(accessResult.reason)
}
const updateResult = await uow.users.updateOne(
{ _id: userId, tokens: { $gte: lesson.tokensCost } },
{ $inc: { tokens: -lesson.tokensCost } }
)
if (updateResult.modifiedCount === 0) {
throw new Error("Not enough tokens")
}
return await uow.progress.create({
userId,
lessonId,
status: "started",
startedAt: new Date()
})
})
}
Код стал сложнее и надёжнее: транзакция, атомарность, разделение ответственности.
Но суть в том, что для небольшого проекта с десятком активных пользователей эта сложность чаще всего не нужна. Вероятность race condition стремится к нулю. Если транзакция зависнет - техподдержка поправит токены за пять минут, а вы потратили кучу времени на Unit of Work.
Поэтому из перечисленных проблем, наверное, единственное, что достаточно универсально - это разделение обязанностей. Всё остальное - преждевременная оптимизация.
Итоговый вариант кода с разделением обязанностей выглядел бы так:
`typescript
async startLesson(userId: string, lessonId: string) {
const user = await this.userRepository.findById(userId)
const lesson = await this.lessonRepository.findById(lessonId)
if (!user || !lesson) {
throw new Error("User or lesson not found")
}
const accessResult = await this.accessService.checkAccess(user, lesson)
if (!accessResult.allowed) {
throw new Error(accessResult.reason)
}
if (user.tokens < lesson.tokensCost) {
throw new Error("Not enough tokens")
}
await this.userRepository.update(userId, { tokens: user.tokens - lesson.tokensCost }) | 2 681 |
| 3 | ИИ база
Ну что, дожили до того светлого будущего, когда все больше работодателей интересуются, умеет ли соискатель работать с ИИ. Сразу успокою, пока — это далеко ни каждый первый и даже ни каждый второй, поэтому есть время подготовиться и понять, что вообще могут спросить и как отвечать.
Почему стали проверять знания ИИ?
Тут все просто — строили, строили и наконец построили процессы, которые включают работу агентов как дополнительный инструмент для решения рабочих задач. Раньше джун мог выехать на одном языке и фреймворке, а теперь даже на старте ждут, что ты не просто пишешь код, а понимаешь, как подключить к этому делу LLM.
Лично мне положение дел скорее радует, чем огорчает. Для инженеров (соеров) — это дополнительная возможность карьерного роста, да, снова надо учиться новому и уходить в сторону M-shape, но так было всегда — учись лавировать или уходи из профессии.
Для джунов ситуация стала сложнее — кроме обязательного System Design, появляется "покажи, как ты умеешь с агентами работать". И если по системному дизайну еще можно измерить нагрузку городами и как-то проскочить со словами "ну что вы от меня хотите, я ж только учусь", то по ИИ нужно показать хотя бы базовые практические навыки, и здесь все зависит от желания развиваться, так что шансы есть, особенно если подкачать базу.
Сейчас в приоритете агенты (с постепенным переходом к командам агентов и оркестрации), нужно уметь:
Теория:
- промпт-инжениринг — нужно рассказать про принципы, подходы, техники рассуждений и т.д.
- контекст-инжениринг — нужно объяснить, что такое контекстные окна, «загнивание» контекста, управление вниманием, RAG и т.д.
- обосновать выбор модели под задачу (например, тебя просят разработать небольшую фичу за разумное время и потребление токенов — тут главное не гонять дорогую модельку на задачах, а показать, что ты понимаешь, где проходят «границы возможностей»);
- архитектура агентов (включая команды агентов)
Практика
Например, задача на 20–30 минут, где нужно показать основные моменты разработки с агентами. На собеседовании дается живой кейс с уже настроенным агентом (либо можно взять свой привычный инструмент) и нужно:
- построить структуру проекта c учетом spec-driven development, ADR и т.д.;
- подобрать набор инструментов (в том числе MCP) и скиллов;
- разбить задачу на этапы (планирование, проектирование, реализация, контроль);
- решить проблемы галлюцинаций и в завершение сделать качественное ревью результата (т.е. показать, что именно «вы» будете делать и почему human in the loop так важен).
И для общей статистики предлагаю поставить 💡 если в твоей компании уже просят использовать ИИ или на собесах задают вопросы по ИИ. | 4 690 |
| 4 | Курс по микросервисам стартует 20.04.2026.
Продолжаю создание курсов по теме архитектуры. Ранее в сообществе были созданы коллекции материалов по сервисам и монолитам, и вот настала очередь микросервисов.
О курсе:
❗️ приоритет на проектирование, документирование и анализ (будем разбираться, как проводить границы, формировать требования, распределять обязанности и т.д.)
❗️ изучать можно индивидуально или общаясь в группе
❗️ еженедельные семинары с разбором проблем и консультациями (только для Подписки №3)
❗️ часть созвонов предполагает интерактивный формат круглого стола (например, общая Event Storming сессия)
Важно! Это не формат обучения. Нет никаких обязательных лабораторных работ, программы обучения и прочих вещей. Вместо этого — набор материалов, доступных по подписке, и обмен реальным опытом.
Можно просто смотреть лекции (для этого нужна Подписка №1), можно дополнительно смотреть мастер-классы (подписка №2), а для обратной связи приходить на семинары (подписка №3).
Наибольшая польза достигается за счет участия в семинарах: у нас собрана команда из 10 человек — это специалисты разного уровня, от архитекторов до новичков.
Мы обсуждаем не только информацию из курсов, но и практические вопросы, которые есть у ребят. Поэтому встречи — это отличный способ обменяться опытом, задать вопросы, получить информацию, которая выходит за пределы курса.
Количество участников на семинарах ограничено, сейчас есть 4 места, которые доступны, если вы приобрели подписку №3.
Важный момент! Подписка предусматривает доступ ко всем имеющимся материалам, встречам, созвонам и т.д., в общем, всему тому, что входит в подписку. Поэтому не надо думать, что подписка идет на курс: курс — лишь часть того, что есть в подписке.
Мы реализуем идею поэтапного развития (движения к цели короткими шагами), постоянно шлифуем свои навыки, собираем актуальную информацию, которую можно применять на практике, обмениваемся опытом и т.д., а подписка определяет уровень доступа.
Например, после курса по микросервисам планирую курс по архитектуре агентных систем, дополнительные созвоны, публикацию материалов в ИИ-лаборатории и т.д.
В общем, приобретая подписку, вы получаете не только курс, а участие в нашем сообществе и его активностях. | 0 |
| 5 | Последнее видео по промпт-инженерии далось с особой болью, раньше я бездумно использовал советы из интернета, которые определяли, что нормальный промпт - это когда ты задаешь роль, контекст, задачу, пример (строго в таком порядке) и добавляешь конкретные измеряемые критрии качества.
Я использовал и мне казалось, что "Вау! Это работает". А потом я решил сделать ролик в котором показать "плохие" и "хорошие" промпты.
Оказалось, что "плохие" промпты работают ничуть не хуже чем "хорошие", т.е. все это время я делал промпты не понимая, что делаю "шляпу". В итоге я собрал те моменты, которые реально дают изменения, перестал писать портянки текста, больше фокуса на примеры и техники размышления и вот здесь уже удалось показать разницу.
А знаменитое "представь что ты программист" оказалась не такой полезной штукой, как я думал. | 0 |
| 6 | Сделал видео по созданию промптов, идея была в том, чтобы рассмотреть разные варианты текстов и выделить общие правила, которые опубликовать на soerdev.space в картах знаний.
В итоге получилось очень плотное информативное видео, смотреть можно тут:
YouTube | Vk | RuTube | 0 |
