🎓 Мастер-классы: ускоритель карьеры или пустая трата времени?
Я часто слышу: «Зачем куда-то ходить? Всё есть в открытом доступе». И это правда. Теорию, гайды и даже записи выступлений можно найти бесплатно.
Но есть нюанс: мастер-классы могут дать то, чего нет в записи — если правильно их выбирать.

💡 Три главные пользы живых встреч (которые работают не всегда)
1️⃣ Чужие ошибки — вы запоминаете и с меньшей вероятностью наступите на те же грабли.
Честно: это не заменит полгода практики, но сэкономить пару недель — реально.
2️⃣ Ответы на ваши вопросы — в живом общении можно уточнить.
Честно: если в зале 30+ человек, дадут 1–2 коротких ответа. Идите с готовым вопросом.
3️⃣ Нетворкинг — познакомиться с коллегами полезно.
Честно: большинство контактов умирают в забытых чатах. Это бонус, а не стратегия.

🔗 Что реально взять с МК:
✅ Hard skills: конкретные техники, шаблоны, разбор ошибок
⚠️ Soft skills: умение задавать вопросы, аргументация в дискуссиях, за вечер не прокачать — МК может показать направление, но не заменит месяцы практики.

🧠 Личный пример (без иллюзий)
Вчера я сходила на «Холиварные аналитические посиделки». Тема — ИИ и работа системного аналитика, как писать промпты.
Получила пару техник промптов, новых подписчиков (Вас уже больше 1️⃣0️⃣0️⃣) и понимание, как не надо строить диалог с нейросетью. Теорию я знала. Живые кейсы дали ощущение, а не революцию.

🎓 Моё резюме (теперь честное)
Онлайн-видео даёт базу. Мастер-классы — потенциальное ускорение, если:
❇️ У вас уже есть база — иначе будет каша.
❇️ Вы идёте с конкретным вопросом, а не «за вдохновением».
❇️ Формат предполагает практику, а не монолог на 2 часа.
❇️ Вы готовы, что 70% информации уже есть в открытом доступе.
Если эти условия не выполнены — да, мастер-класс будет пустой тратой времени и денег.

↘️Короткий чек-лист перед походом
➖ Я уже знаю теорию по этой теме?
➖ У меня есть конкретная рабочая задача, где я применю результат?
➖ В программе больше 50% практики / разбора кейсов?
Если да — идите. Если нет — лучше почитайте документацию или наймите наставника на час.

А вы ходите на мастер-классы? Что для вас было реально полезно, а что — потерей времени? 👇

#Карьера

📌 Продукт и проект: в чём же разница?
Эти два слова мешают в кучу на собеседованиях, в резюме и в головах. А разница — как между такси и личным автомобилем. Оба довезут, но живут по-разному.

🚀 Проект
Жизненный цикл: начали → сделали → сдали → забыли.
У проекта есть чёткая дата завершения. Команда собралась под задачу. Бюджет выделен на срок. Как только цель достигнута — проект умер. Команда разбежалась. Документация в архиве.
Пример: построить дом, внедрить 1С, сдать отчёт за квартал.

🔄 Продукт
Жизненный цикл: придумали → запустили → растем → зреем → уходим на покой (когда надоели рынку).
У продукта нет дедлайна. Он живёт, пока нужен людям. Команда постоянная. Бюджет — на развитие, а не на одну стройку.
Продукт не «сдают», его релизят. Он умирает сам, когда рынок отворачивается.
Пример: Telegram, ваша CRM-система, мобильное приложение банка.

💡 Почему это важно для вас
— В проекте требования фиксируют в начале и не трогают. Каждое изменение — через боль и комитет.
— В продукте требования живут и меняются. Вы пробуете, ошибаетесь, улучшаете, слушаете пользователей.

⚠️ Если перепутать — вы задушите продукт бюрократией. Или никогда не закончите проект, пытаясь делать его «гибко».

🎯 Моё резюме
Сначала пойми, с чем имеешь дело. Проект — делай и сдавай. Продукт — живи с ним и развивай.

#Термины

😌 Синдром самозванца: когда кажется, что вы тут случайно
Знакомо? Вас повысили, а вы думаете «повезло». Сделали сложный проект, а внутри голос шепчет «просто совпало». Завтра придут и поймут, что вы ничего не умеете.
Это называется синдром самозванца. И в ИТ им болеют.

🔍Как это выглядит
➖ Вас хвалят за отличный анализ, а вы уверены, что просто повезло с задачей.
➖ Коллеги спрашивают совета, а вы боитесь, что сейчас раскроют ваше «незнание».
➖ Любая ошибка подтверждает: «ну вот, я же говорил, я не настоящий специалист».
При этом объективно вы работаете хорошо. Но внутренний критик сильнее цифр и фактов.

👂Почему в ИТ это массово
Технологии меняются каждый год. Вы только выучили что-то — а уже надо переучиваться. Вы только стали мидлом — а сеньоры обсуждают что-то, чего вы не знаете.
Постоянное обучение создаёт вечное чувство: «я не успеваю, я отстаю».
Плюс индустрия полна гениев, которые в 20 лет уже CTO. Сравнивать себя с ними — прямой путь к самозванцу.

🧠Что делать
➖ Признать нормой. Почти у всех есть этот голос. Даже у тех, на кого вы смотрите с восхищением.
➖ Фиксировать победы фактами. Заведите заметку «что я сделал(а)». Не «я молодец», а «закрыл 5 багов», «задеплоил фичу», «помог коллеге». Перечитывайте, когда накатывает.
➖ Не сравнивать своё «внутри» с чужим «снаружи». Вы видите чужие успехи — но не видите их сомнений. Это нечестная игра.
➖ Просить конкретную обратную связь. Не «ну как я вообще?», а «что получилось в задаче X, что нет?». Если не верите себе — поверьте тимлиду, который говорит «вы молодец» на фактах.
➖ Говорить вслух. Обсудить с коллегой или ментором. В ответ часто слышишь: «О, у меня тоже так было». И становится легче.
➖ Действовать до уверенности. Не ждите, когда страх пройдёт. Делайте следующий шаг. Уверенность приходит после действий, а не до.

💡Моё резюме
Синдром самозванца не лечится раз и навсегда. Он будет возвращаться при каждом новом вызове. Но если вы знаете, как он работает, вы перестаёте ему верить.
Вы здесь не случайно.
Вас не обманешь на собеседовании, в проекте, в команде. Вас наняли не за гипотетическое всезнание, а за способность решать задачи. Вы их решаете — значит, вы на своём месте.

#Карьера

🍝 Спагетти-код. Откуда взялся термин и почему он всех бесит
Вы когда-нибудь пробовали распутать тарелку спагетти?
Примерно так же выглядит программа, в которой логика выполнения прыгает как горный козёл: отсюда туда, сюда обратно. Попробуй разберись.
Это и есть спагетти-код.

🔍 Откуда ноги растут (и извиваются)
Точная дата рождения термина неизвестна. Но первое упоминание появилось в 1972 году.
Программист Мартин Хопкинс сказал фразу, которая стала пророческой: «Главная мотивация для устранения оператора goto — надежда, что готовые программы перестанут выглядеть как миска спагетти».
И понеслось. В 1977 году вышла статья с провокационным названием «Макароны лучше спагетти». В 1978-м Ричард Конуэй описывал программы, которые «имеют такую же чистую логическую структуру, как тарелка спагетти». С тех пор метафора прочно засела в ИТ.

🧠 Что это значит
Код называется так, потому что его поток управления напоминает запутанные макароны — извилистый и абсолютно нечитаемый. Полное отсутствие структуры. Логика прыгает с помощью goto, неожиданных исключений или просто «как бог на душу положит».
Страшно поддерживать. Внесение одного изменения ломает всё. Вы никогда не знаете, куда приведёт очередной прыжок.

🍝 Почему это антипаттерн
Спагетти-код — самый знаменитый антипаттерн в программировании. Он возникает по банальным причинам:
➖Частые правки от разных людей без общей архитектуры.
➖Спешка: «Сделай быстро, потом перепишем». «Потом» не наступает никогда.
➖Элементарная нехватка опыта.

💡 Моё резюме
История спагетти-кода учит простой вещи: порядок в голове рождает порядок в коде.
Если логика вашей программы напоминает блюдо итальянской кухни — самое время заняться рефакторингом и структурированием.
А когда ваш коллега в очередной раз начнёт плести такую лапшу, не стесняйтесь спросить: «Мы пишем код или готовим ужин?».

Встречали ли вы в своей практике макаронные изделия в коде или документации? Как с ними боролись? 👇

#Термины

📝 Душнить так душнить. Но вы выбираете тему

В рубрике #Термины мы уже разобрали:

➖ откуда взялись термины
➖ анализ vs аналитика
➖ проект vs продукт
➖ антипаттерн "спагетти код"

Теперь — ваша очередь.

Какая пара терминов вас бесит больше всего? Или может интересна история какого- выражения? Пишите в комментарии 👇

#Термины

🌗 Харизма vs экспертиза: кого на самом деле слушают в команде
В каждой команде есть два типа людей. Первого все любят. Ко второму идут за советом. И это не всегда один и тот же человек.
Давайте честно: харизма открывает двери. Экспертиза — решает задачи.

📗 Что происходит на практике
Харизматичный «добрый малый» отлично входит в доверие. С ним приятно пить кофе, он сглаживает конфликты, его хотят слышать. Но когда проект затягивает болото, а заказчик меняет требования в пятый раз — его слова становятся просто фоновым шумом.
Потому что он не может ответить на главные вопросы:
➖ Как это сделаем?
➖ Какие риски?
➖ Как это повлияет на текущую архитектуру?
Эксперт может быть не самым приятным собеседником. Он жёстко режет «а давайте подумаем», занудно объясняет, почему ваша идея провалится, и сыпет терминами. Но именно его слушают в критический момент. Потому что за ним — решение.

👀 Почему «добрый малый» проигрывает
Потому что харизма без багажа работает до первой серьёзной проблемы.
Когда всё хорошо — все любят харизматика. Когда всё плохо — тянутся к эксперту. Даже если он ворчун.
Я много раз видела это на ретроспективах и разборах полётов. Команда благодарит того, кто приносит печеньки. Но слушает того, кто говорит: «У нас ошибка в архитектуре, и вот почему».

🖋 Что делать, если вы не харизматик
Прокачивайте экспертизу. Это ваше топливо.
Станьте человеком, к которому идут за ответами. Не за улыбкой, а за конкретным: «Смотри, я уже такое решал, вот схема, вот пример, поехали».
Харизма — это ускоритель. Но без экспертизы вы просто быстрая тележка без тормозов. А экспертиза без харизмы — это бетонный блок, который в одиночку с места не сдвинуть.

✒️ Что делать, если у вас есть и то, и другое
Используйте это! Люди будут идти за вами и слушать вас. Но помните: сначала экспертность, потом харизма. Если поменять местами, получится «пустышка с обаянием».

💡 Моё резюме
Не пытайтесь нравиться всем любой ценой. Будьте тем, кто умеет делать свою работу лучше других.

#Карьера

🌍 В этот день кто-то сказал: «Берите бесплатно». И мир изменился
30 апреля 1993 года европейская лаборатория CERN объявила: технологию World Wide Web (WWW) может использовать кто угодно и где угодно. Бесплатно. Без лицензий и отчислений.
До этого интернет существовал. Но был уделом военных, учёных и гиков.

🔬 Кто это сделал
Тим Бернерс-Ли, британский учёный, работавший в CERN. В 1989 году он предложил систему, которая позволяла связывать документы через гиперссылки. В 1990 году сделал первый веб-сервер и первый браузер.
Но главное он сделал в 1993-м: не запатентовал технологию и не стал на ней зарабатывать.
CERN мог стать монополистом. Вместо этого они подписали документ, который отдал WWW человечеству.

⚡️ Что изменилось
До 1993 года, чтобы зайти в интернет, нужно было знать команды, протоколы и адреса серверов.
После — появились браузеры. Люди могли просто кликать на ссылки.
За пару лет родились первые поисковики, Amazon и eBay.
Все эти компании стоят на плечах решения CERN «отдать технологию бесплатно».

🧱 Ирония судьбы: WWW создали в Европе, а развивать поехали в США
Тут есть горькая историческая деталь.
CERN — европейская организация. Но в Европе 90-х не оказалось инвесторов, которые поверили бы в веб. И предпринимателей, которые поняли бы масштаб.
Поэтому первые браузеры, первые поисковики, первая электронная коммерция — всё это уехало в Кремниевую долину.
Европа подарила миру веб. А заработали на нём — американцы.

🚫 А теперь про блокировки
И ещё одна ирония. Изначально веб задумывался как открытая, децентрализованная сеть, где любой может опубликовать что угодно и любой может это прочитать.
Сегодня мы живём в другой реальности.
Страны блокируют сайты. Корпорации собирают наши данные. Государства спорят, кому принадлежит интернет. А в некоторых местах за «неправильную» ссылку можно получить реальный срок.
Тим Бернерс-Ли сам говорит, что разочарован тем, во что превратился его проект.

🎓 Что это значит для вас
30 апреля 1993 года — день, когда интернет перестал быть «штукой для избранных» и стал «для всех». И день, когда началась эра, которую мы сейчас пытаемся делить, блокировать и регулировать.
А вы помните свой первый выход в интернет? Я — да. Это был писк модема и 5 минут на загрузку картинки 😄

#Байки #Инструменты

🔝 Функционал vs функциональность: термины, которые режут слух
Пожалуй, это моя сильная боль.
Студент защищает диплом. Говорит: «Функционал системы включает... Разработан следующий функционал... Основной функционал — это...». Этим грешат не только студенты, но и коллеги...
Я сижу и слышу только это слово. Остальное пролетает мимо ушей.

📖 Что говорят словари
Функционал (математический) — числовая функция, заданная на множестве функций, переменная величина, зависящая от выбора одной или нескольких функций.
Функционал (в сексологии) — одна из пяти групп гомосексуалов, согласно классификации психолога Алана Белла и социолога Мартина Вайнберга.
Функциональность — способность системы выполнять конкретные действия; набор возможностей (функций), которые предоставляет система или устройство.
Теперь представьте лицо разработчика, который читает в ТЗ про «расширенный функционал системы»...

🧠 Про жаргонизмы: где уместны, а где нет
Жаргонизмы — это сленг, понятный внутри группы. В устной речи между «своими» — пожалуйста.
«Сделай функционал такой-то» — нормально в чатике с разрабом. Все поняли. Все ок.
Но в официальной документации, резюме, ТЗ, на собеседовании — нет. Там жаргон делает вас непрофессионалом. Потому что вы общаетесь не с коллегой по курилке, а с людьми, которые ожидают точности.

🩹 Если коллеги возражают?
Бывает и так. Вы начинаете говорить «функциональность», а коллеги закатывают глаза: «Хватит душнить, все же так говорят».
Как же быть в такой ситуации спросите Вы.
1️⃣ Не спорьте в рабочем чате. Толку ноль, все только разозлятся.
2️⃣ Используйте профессиональный язык в документации, резюме, публичных выступлениях. Там ваша зона ответственности. А в устной речи — подстраивайтесь под команду. Это называется «коммуникативная гибкость».
3️⃣ Если вы руководитель или ментор — показывайте пример. Не требуйте, а сами пишите грамотно. Люди подтягиваются незаметно.
Правило простое: умеете говорить профессионально — переходите на сленг когда уместно.

‼️ Запомните
❌ Функционал — оставьте математикам и сексологам.
✅ Функциональность — когда говорите о возможностях системы.
✅ Функция — когда речь об одной конкретной задаче.

🔱 Моё резюме
В русском языке есть слово «функциональность». Оно точное, правильное и профессиональное. Используйте его.
А «функционал» оставьте тем, кому он действительно нужен. Считаю, что в ИТ ему не место. Не исключаю, что этот термин могут узаконить в ИТ, поживём - посмотрим...

#Термины #Карьера

🤬 Травля на работе: когда коллеги — не семья
В ИТ принято говорить «мы команда», «мы семья». Но иногда за красивыми словами прячется обычная травля. И она бывает не только сверху вниз. Руководителя тоже могут травить. Мне повезло с коллективами и там всегда была и есть дружественная атмосфера.

🕷 Травля руководителя → подчинённых
Признаки (не все):
- публичные разносы, крики, унижения
- обесценивание работы: «ты ничего не умеешь»
- завал невыполнимыми задачами без ресурсов
- угрозы увольнением за малейшую ошибку
- изоляция: не зовут на встречи, не дают информацию
Это не «жёсткий стиль управления». Это насилие.

🐀 Травля руководителя ← подчинёнными
Да, такое тоже бывает. И говорить об этом принято ещё меньше.
Признаки (не все):
- игнорирование просьб и поручений («забыл», «не успел»)
- саботаж решений: вроде согласились, но делают по-своему
- сплетни за спиной, подставы, слив информации
- публичное оспаривание авторитета при команде
- «тихий бойкот» — все делают вид, что вас не слышат
Руководитель становится изгоем в собственной команде. Студенты также занимаются травлей преподавателей.

👥 Горизонтальная травля (коллега → коллеге)
Это вообще классика «семейных» чатов.
Признаки (не все):
- постоянные подколы под видом шуток
- исключение из обеда/кофе и рабочих обсуждений
- пассивная агрессия в общих каналах
- присвоение ваших идей и перекладывание ошибок
Эту травлю легче всего замаскировать под «корпоративный юмор».

❓Как понять, что это травля, а не «сложный период»
✅ Системность: не разово, а регулярно.
✅ Неравенство сил: у одной стороны меньше ресурсов для защиты.
✅ Умысел: есть цель уничтожить, а не конструктивно критиковать.
Ошибся → указали на ошибку = работа.
Каждое утро начинается с унижения = травля.

❓Что делать, если Вы жертва
Перебрала сотни советов и поняла, что не могу сформировать список или план действий, он настолько различен в зависимости от ситуации и получается огромное дерево принятия решения. Точно поймите, причина не в Вас, причина в том, кто делает Вас жертвой.

💡Моё резюме
Не терпите травлю. И не участвуйте в ней сами. Даже если «все так делают». Если при Вас кого-то травят, а вы молчите, значит Вы согласны и тоже являетесь соучастником.
Первый шаг — перестать поддерживать молчанием.

#Карьера

🚀 MVP: почему не надо тащить в первую версию всё, что придумали
Термин Minimum Viable Product (MVP) придумал Фрэнк Робинсон, CEO компании SyncDev, ещё в далёком 2001 году. А популяризировали его позже Стив Бланк и Эрик Рис в своих книгах про Lean Startup.

❓ Зачем всё это?
Суть максимально прагматична: не трать годы на создание «идеального» продукта — узнай, чего на самом деле хочет пользователь, как можно раньше.
MVP — это не прототип и не макет. Это самая простая, но работающая версия продукта с минимальным набором функций, способная решить одну-единственную, но реальную проблему.

🧯Но будьте осторожны: MVP бывает разным
Model-View-Presenter (MVP): термин ИТ, архитектурный паттерн для построения пользовательских интерфейсов. Производный паттерн от MVC и призван сделать код чище, а тестирование — проще и приятнее.
Most Valuable Player (MVP): термин спортивного аналитика, самый ценный игрок. Тут всё просто — лучший из лучших в команде или на турнире. Есть и менее известный, но очень милый вариант — Most Valuable Primate (Самый ценный примат) — это звание из одного старого фильма.
Mitral Valve Prolapse (MVP): медицинский термин, который в переводе с латыни означает пролапс митрального клапана (одна из разновидностей порока сердца).
Minimum Viable Population (MVP): из области экологии и биологии, минимально жизнеспособная популяция. Это понятие используют, чтобы определить, сколько особей нужно популяции, чтобы она не вымерла.

🔏 Что можно и нельзя выкатывать в прод под видом MVP
✅ Можно
- одну ключевую функцию, которая решает одну конкретную проблему
- сырой интерфейс, но работающую логику
- костыли, если вы их осознаёте и планируете переписать
❔Возможно, но точно зная, что исправите
- «ручной» бэкенд (например, заказы на почту)
❌ Нельзя
- сырые данные без валидации (финансы, здоровье людей, персональные данные)
- костыли, которые убивают безопасность (пароли в открытом виде, открытые порты)
- недоделанную авторизацию с дырами (пользователи получат чужие аккаунты)
- API с нестабильными ответами для внешних систем
- функции, чья поломка остановит основной бизнес

🍕 Живой пример из жизни
Представьте, вы хотите открыть службу доставки пиццы.
Ошибочный подход: Годами копить деньги на супер-приложение, сайт с визуальным редактором пиццы и автопарк из 10 машин.
MVP как он есть: Сделать лендинг за полдня на коленке, разместить на нём кнопку «Заказать» и свой номер телефона. Первые заказы принимать по звонку и развозить пиццу самому.
Если на вторые сутки вам позвонят хотя бы три человека — гипотеза подтвердилась. Если нет — вы не разорились и можете спокойно придумать новую идею.

🎓 Моё резюме
MVP — это не попытка сэкономить или выпустить недоделку. Это философия бережливого стартапа: учиться быстрее, чем конкуренты, и не тратить деньги на воздух.
MVP — не синоним «сырого куска кода». Это стратегия: быстро получить обратную связь. Не перепутайте прод с песочницей.
А когда коллега скажет «выкатим MVP в прод», спросите: «Какой именно MVP? И проверили ли мы безопасность?».
#Термины

ℹ️ Профстандарты в ИТ: бумажка или нет?
Есть в России такие документы — профессиональные стандарты. В ИТ они тоже есть. И вокруг них ходит много слухов. Кто-то думает, что без них не устроиться на работу. А кто-то вообще не знает, что это такое.
Давайте разберёмся.

❓Что это вообще такое
Профстандарт — это официальный документ, утверждённый Минтрудом, который описывает: как должна называться должность, какое у тебя должно быть образование, сколько опыта и какими навыками ты обязан владеть. Документ призван навести порядок в том, кто, чем и на каком уровне должен заниматься.
Для примера, в ИТ есть профстандарты для «Программиста» и «Системного аналитика». Первый был обновлён в 2022 году и вступил в силу с 1 марта 2023-го. Для системного аналитика он существует с 2014 года, а новый приказ Минтруда вступил в силу 1 сентября 2023 года и будет действовать до 1 сентября 2029 года.

✍️ Кто обязан их соблюдать
Это самый популярный вопрос. И ответ прост: почти никто.
По закону (ст. 195.3 ТК РФ) профстандарты обязательны только в двух случаях:
✅ когда требования к квалификации прямо установлены другими федеральными законами (как для учителей или врачей);
✅ если работа даёт право на льготы или пенсию по вредности.
Во всех остальных случаях они носят рекомендательный характер. Работодатель может ориентироваться на них, а может и нет. Для частных ИТ-компаний это ровным счётом ничего не значит.

🔆 Какая от них польза
➖ Официальный статус профессии. То, что у «Системного аналитика» есть свой профстандарт — это признание того, что вы занимаетесь серьёзным делом, а не придумали себе модную должность.
➖ Ориентир для резюме и развития. Заглянуть в профстандарт хотя бы раз полезно: вдруг вы узнаете, что ваша должность называется совсем не так, как вы думали. Также он может помочь структурировать информацию о своих навыках и своём грейде.

🎓 Моё резюме
Профстандарты — это не пустая бумажка. Но и не закон, который нужно исполнять любой ценой. Это удобный справочник, который государство создало для наведения порядка. Пользуйтесь им и не бойтесь.
#Инструмент #Карьера

👀 Насмотренность: модное слово или рабочий инструмент?
Сейчас это слово на слуху. В дизайне, в маркетинге, в блогах. Но в разработке оно тоже работает. Только смысл немного другой.

👁 Что такое насмотренность в разработке
Не про картинки и референсы из Pinterest. Про паттерны, антипаттерны и типовые решения.
Когда вы в десятый раз видите одну и ту же архитектурную ошибку и говорите: «Стоп, это уже было, так не надо». Или наоборот — сталкиваетесь с задачей и сразу понимаете: «Ага, вот тут нужна очередь сообщений, а не синхронный вызов».
Насмотренность — это база примеров в вашей голове: что работает, а что нет, без необходимости изобретать велосипед каждый раз.

⚡️ Зачем она нужна
✅ Экономия времени. Не надо каждый раз гуглить «как спроектировать X». Вы уже видели три рабочих варианта и один провальный.
✅ Качество решений. Вы опираетесь на чужой опыт, а не на «мне кажется, так будет круто».
✅ Доверие команды. Когда вы говорите «я уже такое видел, давайте не будем наступать на те же грабли», вас слушают.

🪏 Где её брать
Источников много, и делятся они на два типа: пассивные и активные.
📚 Пассивное развитие (потребление)
➖ Книги. Классика: «Мифический человеко-месяц», «Совершенный код», «Чистая архитектура». Или, например, более узкие — про системный анализ, требования, архитектуру.
➖ Статьи и паблики. Хабр, каналы по вашей теме. Даже если читаете по диагонали — откладывайте «узелки на память».
➖ Доклады с конференций и семинаров. Не только вживую, но и в записи. YouTube, VK Видео, Rutube — много бесплатных материалов от лидеров индустрии. Особенно полезны разборы реальных кейсов.
🎤 Активное развитие (выступления)
➖ Самому выступать на конференциях, митапах, в рабочих чатах. Готовя доклад, вы структурируете опыт, ищете чужой материал, учитесь отвечать на вопросы. Это прокачивает насмотренность быстрее, чем прослушивание десятка чужих выступлений.
➖ Участвовать в дискуссиях после докладов. Спросить «а что если?», «а почему не так?» — заставляет мозг искать альтернативы и расширять паттерны.

⚠️ А теперь важное предостережение
Насмотренность без критического мышления превращается в копирование чужого мусора. «А давайте как в том проекте» — не всегда правильный путь. Потому что у того проекта были свои задачи, свои ограничения и свои бюджет. Контекст решает.

🎓 Моё резюме
Насмотренность ускоряет старт. Но не заменяет голову. Насмотренность — это про то, чтобы расширить список вариантов, а не про то, чтобы слепо копировать первый попавшийся. Насматривайтесь. Анализируйте. И всегда спрашивайте: «А подходит ли это решение под мою задачу?»
#Карьера #Инструменты

🤯 Vertical Slice Architecture vs Onion Architecture — не надо выбирать, берите оба
Спойлер: они про разное. И отлично уживаются вместе.

🧅 Луковая архитектура (Onion Architecture)
Придумал Джеффри Палермо в 2008.
Идея: код — как луковица, в центре бизнес-логика, вокруг слои: инфраструктура, API, базы данных.
Главное правило: зависимости только внутрь. Внешние слои знают про центр, центр — не знает про них.
Зачем:
✅ Бизнес‑логика не зависит от технологий
✅ Легко менять базу данных или API
✅ Всё можно протестировать изолированно
Минус: слоёв много. Для простой фичи приходится править файлы в трёх местах.

🍕 Вертикальные срезы/слайсы (Vertical Slice Architecture)
Продвинул Джимми Богард в 2018.
Идея: не делить код на слои (контроллеры, сервисы, репозитории), а группировать по фичам.
В одной папке лежит всё, что нужно для выполнения одного сценария: от запроса до SQL.
Зачем:
✅ Одну фичу может делать один разработчик — не конфликтуют
✅ Фичу легко удалить — просто стереть папку
✅ Не нужно лазить по всему проекту
Минус: если не следить, код дублируется в разных слайсах.

🔥 А теперь главное: как их соединять
Многие думают, что это взаимоисключающие подходы, но это не так
Схема «брак по расчёту»:
На верхнем уровне — вертикальные слайсы.
Делим проект по фичам: Orders, Products, Users. Каждая фича — независимая папка.
Внутри каждой фичи — луковая архитектура.
Свои слои: бизнес‑логика, инфраструктура, API. Зависимости — строго внутрь.
Что получается:
Вертикальные слайсы отвечают на вопрос: Как сгруппировать код, чтобы не мешать друг другу?
Луковая архитектура отвечает на вопрос: Как организовать зависимости, чтобы бизнес‑логика не привязывалась к базе данных?
Внутри одного слайса PlaceOrder вы можете использовать MediatR, CQRS, чёткие слои. Но соседний слайс CancelOrder об этом ничего не знает.

📦 Пример на пальцах

src/
├── Features/
│   ├── Orders/
│   │   ├── PlaceOrder/           # Вертикальный слайс
│   │   │   ├── Domain/           # Луковая архитектура внутри
│   │   │   ├── Application/
│   │   │   ├── Infrastructure/
│   │   │   └── Presentation/
│   │   └── CancelOrder/          # Другой слайс
│   └── Products/

🎓 Моё резюме
Onion защищает бизнес‑логику от внешнего мира.
Vertical Slice защищает разработчиков друг от друга.
Не выбирайте один подход. Берите лучшее от каждого. Архитектура должна работать на проект, а не проект на архитектуру.

#Инструменты #Термины