اکنون در دسترس! پژوهش تلگرام ۲۰۲۵ — مهمترین بینشهای سال 
S0ER
رفتن به کانال در Telegram
Архитектура | Программирование | Профессиональное развитие Соер.Клуб - https://t.me/soer_live По всем вопросам писать на @soerdev
نمایش بیشتر📈 تحلیل کانال تلگرام S0ER
کانال S0ER (@softwareengineervlog) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 10 511 مشترک است و جایگاه 11 614 را در دسته فناوری و برنامهها و رتبه 61 742 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 10 511 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 29 ژوئن, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر -52 و در ۲۴ ساعت گذشته برابر 0 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 25.18% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 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 |
