Минусы:

• Долгая первая загрузка (Time to Interactive)Долгая первая загрузка (Time to Interactive)

• Плохо для SEO — боты видят пустой HTML

• Требует хорошего интернета у пользователя

Главная проблема CSR — поисковые боты. Googlebot умеет выполнять JavaScript, но делает это с задержкой и не всегда корректно. Яндекс справляется хуже. В итоге страницы индексируются медленнее и хуже.

Когда CSR — правильный выбор:

•  Дашборды и админки за авторизацией — SEO не нужен

•  SPA с богатой интерактивностью: редакторы, конструкторы, таблицы

•  Внутренние инструменты компании

•  Приложения, где пользователь авторизован и контент персональный

SSR — Server-Side Rendering

При каждом запросе сервер генерирует готовый HTML с данными и отдаёт его браузеру. Пользователь сразу видит контент — не надо ждать, пока выполнится JavaScript.

Плюсы:

• Отличный SEO — боты видят готовый HTML

• Актуальные данные на каждый запрос

Минусы:

• Нагрузка на сервер при каждом запросе

• Медленнее навигация, чем CSR

• Нужен сервер — хостинг дороже

SSR — лучший выбор для SEO-важных страниц. Поисковик получает готовый HTML с контентом, мета-тегами и структурированными данными. Индексация быстрее и надёжнее, чем при CSR.

Когда SSR — правильный выбор:

•  Интернет-магазины — карточки товаров должны индексироваться

•  Новостные сайты и блоги с часто меняющимся контентом

•  Страницы с персонализированным контентом (лента, рекомендации)

•  Любые публичные страницы, где важен SEO и актуальность данных

SSG — Static Site Generation

HTML генерируется один раз — во время сборки проекта. Готовые файлы раздаются с CDN без участия сервера. Это самый быстрый способ доставить контент пользователю.

Плюсы:

• Максимальная скорость

• Отличный SEO

• Дешёвый хостинг — просто файлы

• Высокая надёжность — нет сервера

Минусы:

• Данные могут быть устаревшими

• Долгая сборка при большом числе страниц

• Не подходит для часто меняющихся данных

Когда SSG — правильный выбор:

•  Лендинги и маркетинговые сайты

•  Документация и справочники

•  Блоги и портфолио

•  Сайты, где контент меняется редко или по расписанию

Главное про SEO

SEO — это часто решающий фактор при выборе рендеринга. Вот простое правило:

•  Страница публичная и должна находиться в поиске → SSR или SSG

•  Страница за авторизацией или контент персональный → CSR

•  Контент меняется часто → SSR

•  Контент меняется редко → SSG

Отдельно про Core Web Vitals — Google учитывает LCP, FID и CLS в ранжировании. SSG и SSR дают лучшие показатели, чем CSR по умолчанию, но и CSR можно оптимизировать через lazy loading, code splitting и prefetching.

Хорошая новость: Next.js позволяет миксовать все подходы в одном проекте. Лендинг — SSG, карточка товара — SSR, личный кабинет — CSR. Именно поэтому он стал стандартом индустрии.

Больше материалов про разработку и запуск своих продуктов — в Telegram-канале @deep_in_prod

Часть живёт на сервере: рендеринг, подготовка данных, проверка прав. Часть - в браузере: интерактивность, ввод, мгновенная обратная связь. Часть - в кэше: CDN, query cache, prefetch, service worker. А часть вообще не выглядит как Frontend: она в контракте API, в схеме данных, в дизайн-системе, в правилах релиза.

Когда всё работает, пользователь видит простую вещь: страница открылась, кнопка нажалась, действие сохранилось. Когда ломается, выясняется, что «кнопка» была последним звеном в длинной цепочке решений.

Кнопка не просто вызывает onClick. Она может запускать optimistic update, инвалидировать кэш, отправлять событие аналитики, менять URL, зависеть от прав пользователя, показывать pending-состояние, откатывать UI после ошибки или повторять запрос.

Это уже не «покрасить кнопку». Это проектирование поведения системы в условиях неопределённости.

Компоненты не спасают архитектуру

Когда Frontend стал сложнее, мы нашли удобный ответ - компонентную модель. Разбей интерфейс на части, переиспользуй их, собери экран из маленьких элементов. Сильная идея, но без неё современные интерфейсы было бы трудно поддерживать.

Но компонентная модель хорошо описывает форму интерфейса и плохо описывает поведение продукта. Компонент может быть маленьким, типизированным и красивым, а архитектура всё равно слабой, потому что настоящая сложность живёт между компонентами.

Самая частая ошибка - смешать UI-состояние, серверные данные, процесс сохранения, ошибки и производные значения в одном месте. Тогда форма знает про API, кнопка - про бизнес-правила, таблица - про инвалидирование кэша, а страница хранит копию данных из query cache «на всякий случай». Дальше начинаются исключения, быстрые фиксы, дублирование, страх менять экран и фраза «проще переписать».

Redux, Zustand, React Query, SWR, Signals, Context - ни один инструмент не решит за команду главный вопрос: где источник правды.

Если правда на сервере, Frontend должен уважать сервер и не показывать пользователю фантомное состояние. Если правда в пользовательском вводе, нельзя терять его после refetch. Если правда в URL, состояние должно переживать перезагрузку и передаваться ссылкой. Плохая архитектура начинается там, где источник не выбран: сервер говорит одно, кэш помнит другое, форма хранит третье, URL показывает четвёртое, а компонент делает пятое, потому что «так быстрее».

Где должна жить логика

Главный вопрос: кто за что отвечает, и что произойдёт, когда что-то пойдёт не так.

Возьмём простой сценарий - пользователь переименовывает проект.

Слабая версия: Пользователь жмёт «Сохранить». Форма отправляет PATCH, показывает спиннер. Через 800 мс ответ приходит, спиннер исчезает, имя в форме обновляется. Хорошо. Но в сайдбаре имя меняется ещё через секунду, потому что список проектов перезапрашивается отдельно. А в соседней вкладке, открытой час назад, имя вообще старое. Пользователь видит три разных состояния одной сущности и не понимает, какому верить.

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

Из этого вытекает несколько практических правил.

Источник правды - один на каждое значение. Если правда на сервере, Frontend читает её оттуда и не хранит копий «на всякий случай». Если правда в URL - фильтры, поиск, выбранная вкладка, она переживает перезагрузку и передаётся ссылкой. Если правда во вводе пользователя, её нельзя потерять при refetch. Дублирование источников - это не ускорение, это будущий баг.

Frontend не решает то, за что не отвечает. Он может скрыть кнопку под роль пользователя, но не должен сам определять, разрешено ли действие. Это решает сервер. Frontend может показать бизнес-правило и объяснить его, но само правило живёт в домене, а не в компоненте. Если правило про деньги, права или статусы случайно осело в JSX, его рано или поздно нарушат.

Кэш это договор, а не оптимизация. Когда мы держим данные в query cache, мы говорим пользователю: «верь этому, пока я не скажу обратное». У договора должны быть условия: сколько данным можно верить, кто их обновляет, когда инвалидировать, что показывать, если они устарели. Быстрый интерфейс не должен быстро врать.

Производительность и ошибки

Производительность часто сводят к Lighthouse, Core Web Vitals и размеру бандла. Метрики полезны, но не объясняют главного.

Пользователь не обязан ждать. Медленный Frontend почти всегда - сумма решений: слишком много клиентского кода, тяжёлая дизайн-система, водопад запросов, дорогой рендер, небрежная гидратация. Это нельзя починить в конце. Это проектируется в начале: что отдать с сервера, что загрузить заранее, что отложить, какой экран остаётся полезным при частичном отказе.

С ошибками то же самое. В продакшене сеть медленная, API отвечает не сразу, сессия истекает, пользователь кликает быстро, данные меняются в другой вкладке. Ошибка валидации должна жить рядом с формой. Ошибка прав - приходить от сервера. Ошибка сети - объяснять, можно ли повторить действие. Ошибка бизнес-правила должно быть написана по-человечески: не «400 Bad Request», а «Нельзя удалить проект, пока в нём есть активные задачи».

Надёжность Frontend - это не отсутствие ошибок в консоли. Это способность интерфейса вести себя предсказуемо, когда мир вокруг неидеален.

Что отличает сильного Frontend-инженера

Не количество выученных хуков и не скорость написания компонентов. Он понимает границы: где заканчивается серверное состояние и начинается клиентское, где данные можно кэшировать, где нужна мгновенная реакция, а где честный loading, где типы помогают, а где нужна runtime-проверка, где абстракция снижает стоимость изменений, а где делает код мутным.

Он проектирует не только компоненты, но и договоры: между клиентом и сервером, между страницей и компонентом, между системой и пользователем.

Плохая архитектура почти всегда выглядит нормально в первый месяц. Потом она начинает требовать всё больше энергии за всё меньший результат. Переписывать приходится не потому, что React плохой или Vue плохой. Чаще всего в начале никто не ответил на скучные вопросы: что является источником правды, какие данные могут устареть, что пользователь увидит при медленной сети, что произойдёт, если запрос выполнится дважды, какая логика принадлежит домену, а какая - интерфейсу.

Заключение

Frontend больше не тонкая оболочка вокруг API. Он стал местом, где техническая архитектура встречается с человеческим ожиданием. Пользователь не видит server components, query cache, hydration и source of truth. Он видит другое: страница открылась или нет, действие сохранилось или потерялось, ошибка объяснена или спрятана, интерфейс помогает или заставляет сомневаться.

Frontend - это слой доверия. Он отвечает за договор между человеком и системой: нажал - увидел реакцию, сохранил - понял результат, ошибся - понял, как исправить, вернулся - попал туда, где ожидал быть. Хорошая архитектура не убирает сложность. Она кладёт её туда, где её можно понять.

Этой вводной статьёй я хотел поделиться мыслями и начать этот блог. Всем спокойных релизов и поменьше багов в продакшене ❤

Мы добавили в приложение следующее:

1. Рассылка кодов авторизации

2. Поиск серверных чатов

3. Подписка у пользователя в сообщениях какая это роль

4. Переработали дизайн тредов, теперь у него больше настроек

5. Сохранение сообщений

Поиск общих чатов

Не есть что конечно, слизано с приложения Discord, но мое виденье его внутри компании немного другого формата.

В чем вообще задумка его для корпоративного мессенджера? Для начала легко найти чаты внутри команд или структур. Группировка - это настраиваемые элементы, мы вывели их в отдельный конфиг, так что поправить под компанию - 5 минут. Настраивается из настроек чата.

Подписка у пользователя в сообщениях какая это роль

Представим что к вам пришел новый сотрудник, а в команде 50 человек. И вот ему надо привыкнуть еще к тому кто разработчик, кто тестировщик, кто стрим лид и тп, а еще же ведь и правильных людей тегать. Эту проблему и позволяет решить данная приписка.

Переработали дизайн тредов, теперь у него больше настроек

Вот тут наверное самое важное, то что плохо реализовано в корпоративных тредах. Долго думали что же нам не хватает и как попытаться уместить все в обычную форму.

1. Мы расширили настройки на создание тредов

Теперь кроме названия треда и иконки можно:

• Проставить теги

• Написать нормальное описание

После создания тредов теперь мы можем не только посмотреть их список, но и так же:

• Отфильтровать по названию, даже по одному слову в середине текста названия или описания

• Отфильтровать по тегам, идет сортировка по часто используемым

• Закрепить тред (все закрепленные всегда будут вверху, только потом будут идти не закрепленные, даже при поступлении в них новых сообщений)

Возможно, предвижу, кому-то удобнее прям внутри сообщений писать, тем самым создавая обсуждения. Потом мы добавим такое, но не в рамки обсуждения, а в рамках внутренних комментариев.

Рассылка кодов авторизации

Инфраструктура под это дело заложена в сервис авторизации. При регистрации или авторизации сервис будет отправлять на почту пользователя сообщение в формате HTML.

Пока еще не заводили отдельную почту для нашего сервиса.

Рефакторинг back-end сервисов

• Мы изменили логику проверки прав, она стала более замудренная, но в тоже время и более правильная.

Теперь Gateway (основной сервис который либо пропускает запрос, либо нет) - подключен к redis pub/sub, инвалидирует версию прав и бит маску. Если не было события изменения - берет из мемори, если была - обновляет свой кеш. Кеш одного пользователя занимает 600.B. что не является слишком много. Для тяжелых прав на 2000 пользователей в одном сервер чате это около 4.5мб. В целом - пойдет.

Кеш хранимый в gateway:

• Сервис топиков тоже потерпел изменения. теперь он не ходит в Permission сервис что бы уточнить права пользователя на просмотр, а Gateway: ProxyRouter приклеивает заголовки:

А сервис топиков их начинает парсить:

На выход топик сервис уже отдает отфильтрованные темы которые соответствуют правам пользователя внутри его роли:

• Наконец то вынесли все коллекции сервис в отдельные базы. Раньше была одна общая БД, делалось для быстрого написания кода, но пораждало много зависимостей и хождений в чужие коллекции. Теперь все сервисы имеют свою БД со своими коллециями. Отдельный инстанс имеет только сервис сообщений.

• 50% сервисов перевели в режим публикации событий. Т.е. раньше было много HTTP вызовов между ними, что пораждало лишние задержки в 1-4мс. Мелочь, но в рамках 1000 или 10000 пользователей это уже существенная нагрузка. Теперь HTTP вызовы служат только для получения информации от другого сервиса, все события которые раньше были - переложены на Redis. Пример: Пользователь зашел в новый чат. Сервис чата сформирует событие что у него появился новый memories, сервис прав подхватит это событие и присвоит ему права и положит их в Redis, сервис Gateway увидит новые данные и заберет их к себе.

  • Мы работаем над переводом остальных сервисов, но не все так быстро))

Удаление легаси кода

При создании проекта, я вообще ничего не знал о методах разработки фронтенда. Сейчас когда нас несколько уже и мы отходим от AI разработки - начинаем сталкиваться с проблемами. Например тогдлы переключения - так как фронт писал ИИ, он в каждую форму где есть тогл - делал новый стилевый файл, и таких файлов скопилось 15+ ед. Мы перевели их на shared и пере-используем. И таких компонентов было очень много. В итоге нам получилось подчистить примерно 2к стилевых строк кода, сократить в JSX около 150 строк, потому что теперь это общие подключения.

Выделили отдельные сервисы кеша. Тонкие обёртки над универсальным key-value store для кэширования. Не хранят данные сами — только формирует ключи и инкапсулирует логику работы с одним конкретным namespace. Пример ниже:

Аналогично сделали и с WS сервисом, вынесли все WS действия в отдельные сервисы, для сообщений, топиков, прав, тредов и тп. Раньше это были одни монолитные файлы.

Большую часть действующих фронт сервисов перевели на isMobile проверку. Например анимации фона на мобилке - не нужны, мы их не грузим и в сборку они так же не попадут.

Изменения в UI

Часть изменений и доработок написал выше.

Изменение в тулбаре голосовой комнаты:

Добавили выбор устройства на ПК:

Тоглам кнопкам добавили плавный переход при нажатии, на фото это не будет видно.

Для мобильной версии сделали 2 вида тапа.

Короткий: Открывает меню взаимодействия с сообщениями

Длинный: позволяет выбрать несколько сообщений сразу. Удалить, переслать или ответить

Итог

За 25 дней мы проделали огромную работу над проектом. Работали порой и до часу ночи. Все прошлые выходные провели с утра до ночи в нашем проекте.

Сейчас у нас:

16 микросервисов бэка + 5 инфраструктурных

137 микрофронтенд сервисов. Да и кажется что "Как-то много" - действительно так, много логики.

Что сейчас:

Наши инфраструктурные сервисы готовы. Мы начинаем фазу тестирования. Активно ищем сервер в аренду с простой поддержкой и не очень дорогой. Хотели 20.04 уже запуститься, но не успели, мысли приходили на лету и где то правили, где-то дорабатывали. Плюс еще потратили кучу времени на обучение RNNoise модели. Вроде теперь давит шумы хорошо, не уровень Krisp конечно.

Спасибо за то что прочитали! Задавайте вопросы если интересно. Готовы версии для PC, IOS, Android. Они на WebWiev, но мы старались мобильные версии оптимизировать.

P.s. Если есть небольшая компания со своими мощностями в которую можно запустить тест для сотрудников не Free основе - напиши в ТГ: AN_Cayo. Настроем под вас наши конфиги и поможем расскатиться) (Ну мало ли повезет и найдется такая возможность. Без буллинга плиз)

Upd. Мессенджер не только для корпоративного общения. Для общего с функциями друзья, черные списки, E2E шифрования лс - будет чуть позже.

• Умная регистрация: Каскадные списки (выбор города подтягивает нужные школы из БД).

• Система тестирования: Тесты по Алгебре, Геометрии и др. с активным таймером обратного отсчета и автозавершением.

• ИИ-разбор: Интеграция с нейросетью для разбора ошибок.

• Сложные рейтинги: Глобальный топ учеников и сложные SQL-запросы для рейтинга по школам.

• Геймификация (Дуэли): Асинхронная система дуэлей 1 на 1.

Я делаю всё сам: архитектуру БД, бэкенд и фронтенд.

Мой вопрос: 50-60 тысяч рублей — это справедливая цена за такой объем работы для соло-фрилансера, или я сильно демпингую? Но хотел бы услышать ваши мысли о соотношении объема работы и оплаты. Спасибо!

В какой то момент у каждому подростку задают вопрос- "куда пойдешь учиться после школы?". Я долго не думал. IT индустрия нравилась с детства, компы ковыряю, в свободное время смотрю видосы этой же теме посвященные, куда ещё идти как не на программиста?(ну-ну, ведь ковыряние компов и программирование одно и то же-_-)

Поступил.

И вот я поступил в колледж на специальность "техник-программист". На одной из первых пар ко мне подсел новоиспеченный одногруппник, и начал со мной разговаривать, я повернулся к нему и выпалил "я вообще то сюда учиться пришел". Он тогда с меня посмеялся(потом мы к слову стали очень хорошими друзьями). А теперь смеюсь и я(на самом плакать хочется от своей глупости), ведь по итогу я как и наверное большинство студентов на учебе - занимался всем чем угодно кроме самой собственно говоря учебы. Не делайте так.

Не сбывшиеся ожидания.

Многие наверное проходили тот момент когда ты поступил в учебное заведение, отучился уже больше половины, а потом до тебя дошло что это не совсем то чего ты ожидал. Это было именно то что я переживал в конце второго курса. В тот момент я не мог придумать темы для PET проектов, не мог придумать идею которая заставила бы меня сесть и писать код, делать то что меня увлекает. Даже тему для курсовых мне по итогу придумывала преподаватель. Из за этого ООП меня не сильно заинтересовало, а веб разработку мы толком не проходили. За то было много предметов которые я искренне не понимал где мне пригодятся. И я решил что программирование это не моё.

Реабилитация. Может я всё же могу?

Реабилитировался только к концу 3 курса, когда уже было грубо говоря поздновато. На 4 курсе уже кроме разработки дипломного проекта ничего толком и не было. Если ранее я говорил что я не могу придумать тему для PET-ника, и тему для курсового, то с дипломом было всё иначе. У моего папы было ИП, и ему нужно было ПО для учета и автоматизированного составления актов. Вот тут то я и загорелся. У меня была цель, был интерес. Я выбрал далеко не ту среду разработки что стоило бы(я использовал те инструменты которыми обладал), у меня дико не хватало знаний, но у самурая нет цели, только путь.:)

По итогу из за неподходящей среды я переписывал проект с нуля около 8 раз, до тех пор пока он меня не удовлетворял. Но какое же это было наслаждение... Была цель, был интерес, я горел проектом. По защите диплома в итоге я оказался лучшим в группе, хоть и не с самой высокой оценкой. И вот тогда проскользнула мысль- может я всё же могу в разработку?

Отказ от профессии.

Мои мысли размазал по ветру призывной колокол. Армия забрала 3 года жизни, а так же изъяла из моей головы мысль о том что я могу стать программистом, ведь все 4 года учебы в нас вбивали- если в IT пропустил 1 год, наверстывать будешь в течении 3.

Приход с армии ознаменовал начало полной неразберихи в моей голове. Надо было работать, но где? Неуверенность в своих силах и незнание рынка закинули работу по профессии в самый дальний угол. Как я могу быть программистом если я ничего не знаю? Кому я там нужен?

Работать там, куда берут?

Работать там, куда берут. С такими убеждениями в голове я пошёл туда где брали- электромонтёр. Учиться мне хотелось, без разницы чему, главное что бы деньги приносило(направил бы я ещё своё упорство в нужное русло...). Я достаточно быстро усваиваю и учусь новому. Спустя пол года работы я освоил всё что было необходимо для кап ремонта небольшого 4 этажного 2 подъездного дома самому. Меня назначили мастером, наняв мне работников. Ещё спустя пол года работы я уволился:)

Нет, это место не было плохим. Платили мне нормально, условия труда были удовлетворительными, да и я был сам себе начальник. Но...

Не на своём месте.

Чувство что ты не на своём месте. Я начал выгорать. Мне не была интересна эта отрасль. Совсем. Те кто выгорали понимают что это за чувство . В эти моменты тебя уже не волнует насколько у тебя большая зарплата, не волнует будущее в котором ты шагнёшь в неизвестность, тебе хочется освободиться. И в этот момент в моей голове наконец появилась та самая мысль- если ты смог обучиться полностью неизвестной тебе профессии, почему ты не сможешь обучиться тому что тебе правда интересно? Я боялся ступить туда откуда ушёл, боялся что всё что я узнал за 4 года в колледже уже не актуально, что всё будет трудно и непонятно. А если точнее я просто находил внутри себя оправдания почему я не буду начинать, оправдания своим страхам. Только вот...

Помните ту фразу "если в IT пропустил 1 год, наверстывать будешь в течении 3"? Обидно что до меня не дошло сразу после армии что если у тебя в голове нет знаний, то и наверстывать тебе нечего:)

Кошка рожает!?

И вот он я- безработный, с беременной женой, и мечтой- заниматься тем что тебе интересно.

Брат моей жены работает в сфере WEB разработки уже несколько лет. Он пару раз пытался меня втянуть, заинтересовать на обучение, но у меня была куча отговорок- устаю после работы, нет времени, ремонт, кошка рожает:)

И в тот момент я понял- настало его время. Он скинул мне курс по React от IT-KAMASUTRA, путь самурая. Я начал курс, из 100 уроков прошёл 30 и бросил- "денег в запасе нет, нужно работать" сказал я сам себе.

Свободное время?

Дальнейший год прошёл в сменах работы. Где-то платили мало, где то было ужасное руководство(работал я только на частников, маленькие предприятия). Моё обучение не продвинулось ни на миллиметр. Я "столкнулся" с ещё одной "стенкой"- свободное время. Его тупо не было(а правда ли его не было?). Домой с работы приходишь поздно, нужно делать домашние дела. Жена родила и ей нужна помощь, первый ребёнок, у нас нет опыта.

Отговорки.

Это всё были лишь отговорки. Что же происходило на самом деле внутри меня? Снова страх. На самом деле когда я начал учиться и прошёл 30 уроков, начал интересоваться рынком труда. А тот меня жёстко обломал. В РБ на hh любая всплывающая вакансия в сфере разработки в течении пары минут была завалена 200+ откликами. Опять те же вопросы- кому я там нужен со своими курсами? Неуверенность очень сильно ломает, обламывает крылья ещё до того как они толком успеют расправиться. И вот я ушёл снова туда "где берут".

Настоящее.

И вот мы пришли к настоящему времени. Если вы помните, то это дневник. И это первый пост. А это значит что тут пока(!) нет хэппи энда, где у меня оффер на 15981357102894 миллиардов долларов и любимая, интересная(!!!) работа. Но прожив всё это я просто поменял своё отношение к работе, учёбе, своему свободному времени. Да, я всё ещё работаю на разных работах, но к этому моменту я уже начал тот самый курс по новой, и почти его закончил. Свободного времени не стало больше, но я его нахожу, а точнее просто перестал искать отговорки, тупить в видосиках на ютубе, и залипать в ленте инсты. У меня появилось много мыслей по поводу нынешнего и дальнейшего обучения, и я буду двигаться вперёд, выкладывая свой путь в виде дневника сюда. Двигаться без ложных ожиданий быстрого и лёгкого успеха, спокойно и планомерно двигаясь вперёд. Я был, да и являюсь нулём в WEB разработке, но верю что спустя время увижу плоды.

Выводы.

Выводы на самом деле достаточно простые. НИКОГДА у вас не будет подходящего времени что бы учиться, если вы не студент. НИКОГДА ничего не получается быстро, особенно осваивание новой профессии. Вы не получите оффер пройдя курс за 2 месяца. В реалиях современного рынка обучение с нуля займет минимум год, до момента когда вы получите шанс на оффер, если вы конечно хотите идти туда специалистом разбирающимся в своём деле, а не вайб-кодером.

Совсем скоро выложу продолжение, но уже по делу. Касаться будет создания плана обучения с участием AI, если вы как и я считаете что составление планов это сложно, и не знаете с чего начать.

Спасибо каждому кто прочитал, и не обосрал меня в комментах, люблю вас❤