S0ER
Відкрити в Telegram
Архитектура | Программирование | Профессиональное развитие Соер.Клуб - https://t.me/soer_live По всем вопросам писать на @soerdev
Показати більше📈 Аналітичний огляд Telegram-каналу S0ER
Канал S0ER (@softwareengineervlog) у мовному сегменті Російська є активним учасником. На даний момент спільнота об'єднує 10 461 підписників, посідаючи 11 426 місце в категорії Технології та додатки та 61 087 місце у регіоні Росія.
📊 Показники аудиторії та динаміка
З моменту свого створення невідомо, проект продемонстрував стрімке зростання, зібравши аудиторію у 10 461 підписників.
За останніми даними від 01 вересня, 2026, канал демонструє стабільну активність. Хоча за останні 30 днів спостерігається зміна кількості учасників на 11, а за останні 24 години на 1, загальне охоплення залишається високим.
- Статус верифікації: Не верифікований
- Рівень залученості (ER): Середній показник залученості аудиторії становить 48.29%. Протягом перших 24 годин після публікації контент зазвичай збирає N/A% реакцій від загальної кількості підписників.
- Охоплення публікацій: В середньому кожен допис отримує 0 переглядів. Протягом першої доби публікація в середньому набирає 0 переглядів.
- Реакції та взаємодія: Аудиторія активно підтримує контент: середня кількість реакцій на один пост – 0.
- Тематичні інтереси: Контент зосереджений навколо ключових тем, таких як rbp, архитектура, callme, mov, указатель.
📝 Опис та контентна політика
Автор описує ресурс як майданчик для висловлення суб'єктивної думки:
“Архитектура | Программирование | Профессиональное развитие
Соер.Клуб - https://t.me/soer_live
По всем вопросам писать на @soerdev”
Завдяки високій частоті оновлень (останні дані отримано 02 вересня, 2026), канал підтримує актуальність та високий рівень охоплення публікацій. Аналітика показує, що аудиторія активно взаємодіє з контентом, що робить його важливою точкою впливу в категорії Технології та додатки.
10 461
Підписники
+124 години
+77 днів
+1130 днів
Архів дописів
10 461
Успеха в челендже.
Вчера спросили зачем это надо? Я через три месяца подведу итоги, посмотрим сколько человек справится. Сейчас что-то около 70 человек начали.
А так, это нужно для себя, для собственного кругозора - инвестиции в собственные знания.
10 461
На одном из стримов я уже говорил, что начиная с марта у меня дикая загрузка по консультациям. Многих интересует в чем заключается эта "работа". Большая часть - это анализ технических заданий, выработка ТЭО или ревью уже готовой архитектуры. Почти все из этого - рутинная, условно бумажная (условно, потому что результат в электронном виде) работ. Результатом, как правило, является документ, в котором перечисляется список предложений и замечаний, а так же расчетная часть по основным показателям.
Отмечу, что заметно сложнее стало с выбором технологий и оборудования для реализации АС. Требования поголовно включают импортозамещение и в полной мере данное требование на данный момент не реализуемо. В этой сложности есть своеобразный вызов, который делает работу интереснее, но я по прежнему больше люблю писать код, консультации - это просто способ заработать денег, возвращаться к этой работе на фултайм я не хочу.
На практике использую все те вещи, про которые рассказываю на стримах - декомпозиция, проведение архитектурных границ, распределение обязанностей, выделение абстракций и интерфейсов, управление зависимостями и т.д.
В планах доделать последний отчет, передать ребятам и взять таймаут до сентября. Очень тяжело работать в таком темпе.
10 461
На вскидку и не поймёшь, что это мой новый Now, а не инста. Появятся сторис и вообще топчик будет.
10 461
Ребята, а что вы знаете про АйТи в СССР? У меня, например, отец в СССР работал над системами спутниковой связи, разрабатывал наземные станции, разрабатывал оборудование для георазведки, медицинское оборудование, знакомый моего отца делал начинку для спутников, писал софт для лазерных установок и т.д.
Причем работа для инженеров была везде, от Москвы до Владивостока, с реальными практическими кейсами, которые могли использоваться в реальном секторе экономики, а не просто "купи-продай", который сейчас составляет 90% так называемого АйТи.
Расскажите свои истории. Интересно услышать как вы представляете было в СССР с АйТи.
10 461
Хочется сказать пару слов про планирование. Линейные планы (т.е. такие планы, где не ставится под сомнение успешное завершение каждого пункта и порядок пунктов никогда не меняется, как правило такие планы еще и последовательны) можно построить не для всех задач, к сложным задачам, в которых есть большая доля исследовательской работы, не применяются линейные планы, вместо этого лучшее что можно придумать - дерево принятия решений, при этом глубина такого дерева, естественно, не может быть большой.
Поэтому R&D задачи можно решать только короткими итерациями, определяя канву ближайшего развития. Бюджетные организации не очень любят такие штуки, поэтому скидывают такие задачи на подрядчиков (потому что договорные сметы относятся к "линейным" планам).
Если вы занимаетесь R&D, то попытайтесь донести до своего руководства, что невозможно совместить обычное линейное планирование и R&D. Вроде бы очевидная вещь, но буквально только что закончил общаться с ребятами, которые сделали красивые планы, получили под них деньги, и теперь не знают как выполнить планы, потому что все пошло вообще не так как ожидалось, а заказчик хочет получить результат предусмотренный договором.
10 461
Когда я слышу "ООП - это ошибка" у меня возникают противоречивые чувства. Вот несколько моментов на которые нужно ответить, прежде чем ругать ООП:
1. ООП появилось сильно позже логического и функционального программирования. И появилось оно как раз потому что функциональное программирование "не взлетело". Требовало слишком много вычислительных и умственных ресурсов. Кстати, это до сих пор так. Написать в функциональном стиле программу по прежнему требует довольно много мыслительных усилий. Я остро чувствую разницу когда читаю код в функциональном стиле и ООП.
2. ООП выстрелило не из-за хайпа, все было ровно наоборот - сначала ООП выстрелило, затем появился хайп. И я это тоже наблюдал своими глазами. Я начинал со структурного программирования и на самом деле разделение на структуры и функции неудобно. В реальном мире мы не привыкли разделять данные и их обработку.
3. В реальном мире мы привыкли мыслить категориями объектов - практически все вокруг нас - это объекты. Мы не думаем, скажем, о телефоне как о трех разных сущностях: форме, свойствах, операциями над ним. Для нас свойства порождают те действия, которые можно выполнить над объектом.
Собственно мое глубокое убеждение - убери ООП и вся индсустрия взвоет из-за возросшей сложности разработки. Но у нас модно бороться с мифами. Самый простой способ словить хайп - отменить что-то проверенное временем. Типа "колесо это самая большая ошибка человечества, вместо него надо было изобрести телепорт". Именно так для меня звучит отрицание ООП.
А вы что думаете про ООП? Палец вверх - если согласны, что эта парадигма важна и нужна, все остальное - ООП нужно выкинуть в топку.
10 461
О стратегии наращивании ресурсов. Вопрос о том, что лучше сразу взять больше ресурсов, чем надо, либо наращивать их по мере возникновения необходимости. Как правило, взять сразу обходится дешевле (так как миграция редко бывает zero cost), но брать по мере необходимости - это "отложить" затраты в будущее и тогда можно делать из за счет полученной прибыли.
Я делю так: если ожидается бурный рост проекта (например, у проекта дикий рекламный бюджет), то применяем стратегию "на вырост", т.е. берем сразу с запасом, если рост медленный, то стараемся "откладывать" расширения в будущее.
10 461
Кстати, последний пример это империческое правило, которое реально используется при проектировании "правило 50%": максимальное capacity решения должно быть не мене чем в два раза больше среднего. Среднее можно рассматривать как текущее.
10 461
Довольно легко продемонстрировать, что специалисты всегда думают о "будущем", не буду приводить программерский пример, слишком много условий описывать. Но давайте приведу пример при выборе ресурсов. Представьте что вы покупаете сервер для СУБД, объем данных, который требует хранения 100 Гб, у вас стоит выбор взять сервер с объемом диска 100Гб (представим, что его гарантированно хватит под "текущее" состояние) или сервер с объемом диска 200Гб. Вопрос, какой сервер вы возьмете?
Если с 200 Гб, то палец вверх, если ровно решающий "текущие" требования, то палец вниз. ))))
10 461
Интересный факт - считается, что хороший программист - это прагматик, который решает только текущие проблемы, одновременно с этим хороший программист должен уметь выбирать оптимальные решения, оптимальность которых можно проверить только "в будущем". Т.е. при выборе решения "хороший программист" таки должен уметь заглядывать на пару шагов в "будущее".
Я считаю, что прагматичность текущих решений - это миф, любой хороший разраб всегда прогнозирует вектор развития. Иначе просто будешь собирать все грабли на проекте.
