Endi mavjud! Telegram Tadqiqoti 2025 — yilning asosiy insaytlari 
S0ER
Kanalga Telegram’da o‘tish
Архитектура | Программирование | Профессиональное развитие Соер.Клуб - https://t.me/soer_live По всем вопросам писать на @soerdev
Ko'proq ko'rsatish📈 Telegram kanali S0ER analitikasi
S0ER (@softwareengineervlog) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 10 511 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 11 614-o'rinni va Rossiya mintaqasida 61 742-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 10 511 obunachiga ega bo‘ldi.
29 Iyun, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni -52 ga, so‘nggi 24 soatda esa 0 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 25.18% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining N/A% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 2 647 marta ko‘riladi; birinchi sutkada odatda 0 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 56 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent rbp, архитектура, callme, mov, указатель kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Архитектура | Программирование | Профессиональное развитие
Соер.Клуб - https://t.me/soer_live
По всем вопросам писать на @soerdev”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 30 Iyun, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
10 511
Obunachilar
Ma'lumot yo'q24 soatlar
-137 kunlar
-5230 kunlar
Ma'lumot yuklanmoqda...
O'xshash kanallar
Taglar buluti
Kirish va chiqish esdaliklari
---
---
---
---
---
---
Obunachilarni jalb qilish
Iyun '26
Iyun '26
+23
0 kanalda
May '26
+77
0 kanalda
Get PRO
Aprel '26
+41
0 kanalda
Get PRO
Mart '26
+127
0 kanalda
Get PRO
Fevral '26
+159
2 kanalda
Get PRO
Yanvar '26
+42
0 kanalda
Get PRO
Dekabr '25
+37
2 kanalda
Get PRO
Noyabr '25
+27
0 kanalda
Get PRO
Oktabr '25
+31
0 kanalda
Get PRO
Sentabr '25
+37
0 kanalda
Get PRO
Avgust '25
+53
3 kanalda
Get PRO
Iyul '25
+51
3 kanalda
Get PRO
Iyun '25
+48
0 kanalda
Get PRO
May '25
+41
2 kanalda
Get PRO
Aprel '25
+54
0 kanalda
Get PRO
Mart '25
+108
1 kanalda
Get PRO
Fevral '25
+110
0 kanalda
Get PRO
Yanvar '25
+56
1 kanalda
Get PRO
Dekabr '24
+151
5 kanalda
Get PRO
Noyabr '24
+203
4 kanalda
Get PRO
Oktabr '24
+81
0 kanalda
Get PRO
Sentabr '24
+125
2 kanalda
Get PRO
Avgust '24
+171
2 kanalda
Get PRO
Iyul '24
+244
5 kanalda
Get PRO
Iyun '24
+164
5 kanalda
Get PRO
May '24
+245
4 kanalda
Get PRO
Aprel '24
+198
5 kanalda
Get PRO
Mart '24
+211
5 kanalda
Get PRO
Fevral '24
+307
2 kanalda
Get PRO
Yanvar '24
+323
4 kanalda
Get PRO
Dekabr '23
+907
4 kanalda
Get PRO
Noyabr '23
+190
3 kanalda
Get PRO
Oktabr '23
+218
2 kanalda
Get PRO
Sentabr '23
+173
0 kanalda
Get PRO
Avgust '23
+247
0 kanalda
Get PRO
Iyul '23
+273
0 kanalda
Get PRO
Iyun '23
+195
0 kanalda
Get PRO
May '23
+2 925
0 kanalda
Get PRO
Aprel '23
+397
0 kanalda
Get PRO
Mart '23
+321
0 kanalda
Get PRO
Fevral '23
+221
0 kanalda
Get PRO
Yanvar '23
+798
0 kanalda
Get PRO
Dekabr '22
+385
0 kanalda
Get PRO
Noyabr '22
+229
0 kanalda
Get PRO
Oktabr '22
+645
0 kanalda
Get PRO
Sentabr '22
+208
0 kanalda
Get PRO
Avgust '22
+153
0 kanalda
Get PRO
Iyul '22
+186
0 kanalda
Get PRO
Iyun '22
+241
0 kanalda
Get PRO
May '22
+402
0 kanalda
Get PRO
Aprel '22
+1 176
0 kanalda
Get PRO
Mart '22
+2 018
0 kanalda
Get PRO
Fevral '22
+25
0 kanalda
Get PRO
Yanvar '22
+41
0 kanalda
Get PRO
Dekabr '21
+60
0 kanalda
Get PRO
Noyabr '21
+26
0 kanalda
Get PRO
Oktabr '21
+63
0 kanalda
Get PRO
Sentabr '21
+375
0 kanalda
Get PRO
Avgust '21
+185
0 kanalda
Get PRO
Iyul '21
+122
0 kanalda
Get PRO
Iyun '21
+20
0 kanalda
Get PRO
May '21
+35
0 kanalda
Get PRO
Aprel '21
+61
0 kanalda
Get PRO
Mart '21
+40
0 kanalda
Get PRO
Fevral '21
+39
0 kanalda
Get PRO
Yanvar '21
+41
0 kanalda
Get PRO
Dekabr '20
+1 613
0 kanalda
| Sana | Obunachilarni jalb qilish | Esdaliklar | Kanallar | |
| 30 Iyun | 0 | |||
| 29 Iyun | +1 | |||
| 28 Iyun | 0 | |||
| 27 Iyun | 0 | |||
| 26 Iyun | 0 | |||
| 25 Iyun | +1 | |||
| 24 Iyun | 0 | |||
| 23 Iyun | 0 | |||
| 22 Iyun | +2 | |||
| 21 Iyun | 0 | |||
| 20 Iyun | +2 | |||
| 19 Iyun | +1 | |||
| 18 Iyun | +2 | |||
| 17 Iyun | +1 | |||
| 16 Iyun | +1 | |||
| 15 Iyun | 0 | |||
| 14 Iyun | +1 | |||
| 13 Iyun | +1 | |||
| 12 Iyun | +1 | |||
| 11 Iyun | +2 | |||
| 10 Iyun | +1 | |||
| 09 Iyun | 0 | |||
| 08 Iyun | 0 | |||
| 07 Iyun | 0 | |||
| 06 Iyun | +1 | |||
| 05 Iyun | +3 | |||
| 04 Iyun | +2 | |||
| 03 Iyun | 0 | |||
| 02 Iyun | 0 | |||
| 01 Iyun | 0 |
Kanal postlari
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 |
