<p>В этом видео Александр Шевчук расскажет о компонентах проектирования, эвристическом принципе проектирования, а также о том, как использовать данный принцип. В обзоре рассмотрен пункт 5.3 главы 5 книги &laquo;Совершенный код&raquo; Стива Макконнелла.</p>

В этом видео Александр Шевчук расскажет о компонентах проектирования, эвристическом принципе проектирования, а также о том, как использовать данный принцип. В обзоре рассмотрен пункт 5.3 главы 5 книги «Совершенный код» Стива Макконнелла.

Александр Шевчук в данном обзоре рассмотрит основные концепции проектирования, главный технический императив разработки ПО, уровни проектирования. Этот видеоролик – обзор пункта 5.2 главы 5 книги «Совершенный код» Стива Макконнелла.

Сертифицированный тренер Microsoft Александр Шевчук расскажет о проблемах, связанных с проектированием ПО, а также почему проектирование ПО – «грязная проблема» Данное видео – обзор пункта 5.1 главы 5 книги «Совершенный код» Стива Макконнелла.

Новости Microsoft. Visual Studio 2015 | WinJS 4.0 | UWP | .NET Native | ASP.NET 5

Карьерный путь сегодня выглядит совсем иначе, чем десять лет назад. Рынок труда меняется быстрее, чем мы успеваем обновлять резюме. Новые профессии появляются каждый год, компании сокращают штаты или перестраивают процессы, а конкуренция за хорошие вакансии растёт. В таких условиях даже опытные специалисты иногда теряются — не понимают, в каком направлении двигаться, как выгодно подать себя или как вернуть уверенность после неудач. Именно здесь появляется карьерный консультант — специалист, который помогает разобраться в профессиональных целях, выстроить стратегию развития и сформировать сильное позиционирование на рынке. Когда стоит обратиться к карьерному консультанту Карьерная консультация — это не только для тех, кто «не знает, кем быть».Она полезна на любом этапе профессионального пути. 1. Если вы студент или джун, который делает первые шаги Вы закончили курсы, получили базовые навыки, но не понимаете, как попасть на первую работу? Карьерный консультант поможет: составить резюме, которое действительно читают рекрутеры, правильно оформить профили на джоб-бордах и LinkedIn, понять, какие навыки нужно прокачать в первую очередь, подготовиться к собеседованию без стресса и паники. 💡 Результат: вы не тратите месяцы на безуспешные отклики, а быстрее получаете приглашения и первый оффер. 2. Если вы хотите перейти в IT из другой сферы Карьера-свитч — это смелый шаг, но без стратегии легко застрять. Карьерный консультант поможет превратить ваш предыдущий опыт в преимущество, а не в «пустое место» в резюме. Он покажет, как грамотно объяснить, почему ваш прошлый опыт ценен, даже если он не связан с технологией напрямую. 💬 Пример: Бухгалтер, переходящий в тестирование, может подать себя как внимательного аналитика с высоким уровнем ответственности. Учитель, ставший фронтенд-разработчиком, — как человека, умеющего структурировать информацию и объяснять сложное простыми словами. Карьерный консультант поможет найти именно эту историю. 3. Если вы уже работаете, но хотите карьерного роста Часто специалисты годами остаются на одной позиции не потому, что не заслуживают повышения, а потому что не умеют заявить о себе. Консультант поможет проанализировать ваши достижения, выстроить аргументацию для повышения или подготовить стратегию перехода на новый уровень (Middle → Senior, Senior → Team Lead). 💡 Вы получите: чёткую стратегию развития, план по обучению и развитию soft skills, новое видение рынка и своих возможностей. 4. Если вы ищете работу после перерыва После декрета, релокации, переезда или профессионального выгорания сложно восстановить уверенность и понять, с чего начать.  Карьерный консультант поможет: обновить резюме и профили, определить актуальный уровень знаний, найти подходящие вакансии, вернуть уверенность в диалоге с рекрутерами. 🎯 Особенно это важно в IT, где технологии обновляются каждый год, и нужен взгляд со стороны, чтобы оценить, как вернуться в профессию. 5. Если вы не понимаете, чего хотите дальше Даже опытные специалисты порой теряются в вопросе «что дальше?».  Карьерный консультант не даст готового ответа, но поможет найти собственные ориентиры: понять, в чём ваша профессиональная ценность, какой формат работы вам подходит (офис, remote, фриланс), что вас действительно мотивирует. После консультации вы перестаёте действовать хаотично — и начинаете двигаться осознанно. Как карьерный консультант экономит ваше время и деньги На первый взгляд может показаться, что консультация — это дополнительные расходы. Но на деле — это инвестиция, которая возвращается в виде ускорения результата. 1. Экономия времени Консультант помогает избежать месяцев хаотичного поиска.Он уже знает, как работает рынок, где искать вакансии, как общаться с рекрутерами и что действительно ценится. Вместо того чтобы теряться в десятках сайтов, вы получаете чёткую дорожную карту. 💬 Например: Без стратегии можно рассылать резюме полгода и не получить ни одного ответа. С консультантом вы понимаете, какие позиции вам подходят, как адаптировать резюме под каждую — и получаете обратную связь уже через пару недель. 2. Экономия денег Карьерная консультация часто стоит меньше, чем один месяц безуспешного поиска. Но она помогает вам: получить высшую зарплату благодаря правильно построенной самопрезентации, избежать неправильного выбора (курсов, направлений, компаний), не тратить деньги на бессмысленные тренинги и сертификаты. 💡 Консультант подскажет, куда действительно стоит вложить ресурсы, а что не принесёт пользы именно вам. 3. Объективный взгляд со стороны Мы часто недооцениваем собственные достижения.  Карьерный консультант помогает оценить себя глазами работодателя, найти сильные стороны и убедительно их показать. В IT, где много похожих кандидатов, это критично — важно уметь выделиться. 4. Стратегический эффект Консультация — это не разовая услуга. Это стратегия. После неё вы понимаете, куда движетесь, какие шаги нужны для следующего уровня и как выстроить карьеру надолго. Это не просто поиск работы — это управление своим профессиональным развитием. 🔹 Вывод Карьерный консультант — это не «психолог по работе», а партнёр, который помогает увидеть свои сильные стороны и превратить опыт в возможности. Он не ищет вакансии за вас — он учит вас делать это осознанно и эффективно. Помощь консультанта нужна не только новичкам, но и тем, кто хочет роста, смены направления или ясности в будущем. Главное, что вы получаете после такой работы, — это чёткое понимание: кто вы, куда идёте и как туда попасть. Если посчитать, сколько времени, нервов и ресурсов тратят люди, ищущие работу без системы, — становится ясно: консультация карьерного эксперта — это не расход, а разумная инвестиция в себя. 💬 Помните: одна правильная консультация может сэкономить вам месяцы поиска — и привести к работе, которая действительно изменит жизнь.

Поиск работы в IT — это процесс, который часто кажется марафоном без финиша. Ты рассылаешь десятки резюме, проходишь собеседования, выполняешь тестовые — и вдруг получаешь сухое сообщение: «К сожалению, вы нам не подходите». Почему именно? Ведь ты учился, был мотивирован, выполнил задание. Ответ прост: на каждом этапе рекрутингового процесса работодатель ищет не просто знания, а сигналы — о твоем мышлении, готовности к работе, поведении и даже об энергии, которую ты передаешь. Разберем подробно каждый этап и то, как избежать типичных ошибок. 🔹 Этап 1. Отказ после отправки резюме Это самый распространенный и болезненный момент: ты отправляешь десятки откликов и получаешь тишину. Что происходит на самом деле Рекрутер тратит на одно резюме от 7 до 15 секунд. За это время он решает, стоит ли читать дальше. Если твой документ выглядит неструктурированно, без конкретики, без GitHub или портфолио — он просто теряется среди сотен других. ⚠️ Типичные ошибки Заголовок “Junior Developer” без уточнения направления. Нужно конкретнее: “Junior Python Developer”, “QA Manual”. Описание в стиле “изучал HTML/CSS/JS, имею базовые знания SQL”. Это выглядит как список из шпаргалки. Отсутствие результатов. Даже на этапе обучения стоит показать, что ты уже сделал: pet-проекты, сертификаты, дипломные задания. Неадаптированное резюме. Если ты рассылаешь одно и то же всем — видно, что ты не читал описание вакансии. ✅ Как сделать лучше Начни резюме с короткого профиля: кто ты, что умеешь и чем можешь быть полезен. Добавь результаты обучения: проекты, технологии, которые использовал, ссылки. Вместо фразы “Хочу развиваться в IT” напиши: “Хочу присоединиться к команде, где смогу работать над продуктом, совершенствуя свой код и процессы тестирования.” 💡 Резюме — это не твоя биография, а первая презентация твоей профессиональной ценности. Этап 2. Отказ после разговора с рекрутером Если тебя пригласили на первую беседу — резюме заинтересовало. Но теперь важно закрепить впечатление. Как думает рекрутер HR оценивает не твои знания кода, а твою мотивацию, эмоциональный интеллект, коммуникативность и соответствие культуре компании. Кандидаты часто забывают: это не формальность, а тест на зрелость. ⚠️ Типичные причины отказа Ты не можешь четко объяснить, почему именно IT и почему это направление. Ты не рассказываешь, что уже делал, а только подчеркиваешь, чего не знаешь. Ты выглядишь пассивным или неуверенным, не задаешь вопросов и не проявляешь интерес к компании. Ты обесцениваешь прошлый опыт: “это не важно, я теперь в IT”. ✅ Как действовать Подготовь четкую историю перехода: кто ты был, почему решил сменить сферу, что сделал для этого и каких результатов достиг. Говори о своем прошлом как о силе, а не как о балласте. “Раньше я работал в финансах, поэтому внимательность к деталям помогает мне как тестировщику.” Задавай вопросы: “Как проходит адаптация новичков в вашей компании?”, “Какие возможности роста предусмотрены?” 💬 Рекрутер ищет людей, которые хотят не просто работу, а развитие. Этап 3. Отказ после тестового задания Этот этап показывает, как ты думаешь и как относишься к работе. Как думает тимлид Тестовое — это не про «идеальный код». Это про ответственность, логику и отношение к задаче.  Даже если решение не идеально, но аккуратное, понятное и объясненное — это плюс. ⚠️ Типичные причины отказа Просрочка выполнения без предупреждения. Отсутствие комментариев. Тимлид не понимает твоих решений. Игнорирование требований. Например, просили адаптивный интерфейс, а ты сделал только десктоп. Плагиат или шаблонные решения. Опытные разработчики замечают это мгновенно. ✅ Как действовать Если не успеваешь — предупреди заранее. Это профессионально. Добавь короткий README: какие технологии использовал, почему именно так, с какими трудностями столкнулся. Не бойся показать процесс: лучше объяснить логику, чем прислать «идеальный, но непонятный код». 💡 Тестовое задание — это твой шанс показать не идеальность, а потенциал сотрудничества. Этап 4. Отказ после технического собеседования Это этап, где “вылетают” даже самые подготовленные.  Здесь важно не просто знать, а уметь рассуждать вслух. 💥 Что оценивает тимлид Понимаешь ли ты принципы, а не просто определения. Как реагируешь на сложные или незнакомые вопросы. Как рассуждаешь под давлением. Насколько комфортно с тобой взаимодействовать как с коллегой. ⚠️ Типичные ошибки Ответы “из учебника”, без понимания контекста. Агрессивная реакция на фидбек или оправдания: “Меня так учили.” Молчание, когда не знаешь ответа. Отсутствие вопросов о команде, продукте, технологиях. ✅ Как действовать Если не знаешь — скажи: “Я не сталкивался с этим на практике, но предполагаю, что…” Не бойся рассуждать: тимлид хочет услышать ход мыслей, а не угадывание. В конце обязательно спроси: “Могли бы вы дать обратную связь, что улучшить?” — это производит впечатление зрелости. 💬 Техническое собеседование — это не проверка, а диалог. Этап 5. Отказ после финального этапа Иногда ты прошел все: тест, техническое, финальную беседу — и всё равно получаешь отказ. 💥 Возможные причины Компания выбрала кандидата с чуть большим опытом. Ты не подошел под “культурный фит”: стиль общения, темп работы, энергетика. Твоя коммуникация была слишком формальной или, наоборот, чрезмерно эмоциональной. Это не значит, что ты “плохой”. Часто это просто несовпадение среды, и оно взаимное. ✅ Как реагировать Поблагодари за возможность. Спроси, можно ли получить короткий фидбек. Не воспринимай это как поражение, а как источник информации для роста. 💡 Иногда “нет” сейчас — это “да” через несколько месяцев, когда появится подходящая позиция. Вывод Каждый отказ — это зеркало. Оно показывает не то, что ты “недостаточно хорош”, а то, где именно стоит расти. Никто не строит карьеру без отказов. Но те, кто анализирует, делает выводы и совершенствует себя после каждого этапа — в итоге получают не просто работу, а уверенность в своей профессиональности. Не бойся фразы «мы выбрали другого кандидата». Бойся одного — не сделать выводы и не использовать шанс стать лучше.

Смена профессии — это всегда вызов, и если вы решили перейти в ИТ из другой сферы, вас ждёт ряд испытаний. Но самый сложный этап — это первое собеседование. Часто свитчеры (career switchers) волнуются: «Что сказать о себе, если у меня нет коммерческого опыта? Будет ли мой предыдущий бэкграунд полезен в новой сфере?». На самом деле правильная самопрезентация может стать вашим главным козырем. Почему самопрезентация критически важна Рекрутер или техлид во время знакомства оценивают не только ваши знания. Они хотят понять, как вы мыслите, видите ли свою ценность и сможете ли встроиться в команду. Если вы сами сомневаетесь в себе — это будет заметно. Но если умело подать свой прошлый опыт и обучение, вы получите плюс даже там, где ещё не хватает технических навыков. Типичные ошибки свитчеров Обесценивание прошлого опыта  ❌ «Я работал бухгалтером, но это неважно, потому что теперь хочу в ИТ».  — Так вы показываете, что не умеете интегрировать прошлые знания в новый контекст. Слишком общие ответы  ❌ «Я выучил JavaScript и хочу развиваться».  — Это звучит одинаково у десятков кандидатов, без индивидуальности. Излишний акцент на отсутствии опыта  ❌ «Я ещё не работал в ИТ, поэтому могу быть не очень компетентным».  — Такая фраза сразу снижает доверие. Успешные примеры самопрезентации 🔹 Пример 1. Переход из финансов в тестирование (QA) «Я более 5 лет работал в финансовой сфере, где отвечал за анализ больших объёмов данных и точность отчётности. Эта работа научила меня внимательности к деталям, ответственности и структурному мышлению. Во время обучения на курсах QA я увидел, что эти навыки напрямую применимы в тестировании: нахождение ошибок, проверка соответствия результатов ожиданиям, составление понятной документации.  Сейчас у меня есть несколько собственных проектов на GitHub, где я создавал тест-кейсы и проводил ручное и автоматизированное тестирование. Я стремлюсь применять эти навыки в профессиональной команде, помогая повышать качество продукта и развиваться как специалист». 👉 Почему это работает? Кандидат не отбрасывает прошлый опыт, а показывает его как сильную базу. Он доказывает, что аналитичность и точность из финансов отлично превращаются в ценность для QA. 🔹 Пример 2. Переход из образования во FrontEnd «Я 7 лет работала преподавателем английского языка. Моя работа была связана с тем, чтобы сложное делать простым: объяснять грамматику, строить понятные примеры, помогать студентам не теряться в деталях. Когда я начала изучать веб-разработку, поняла, что эти навыки напрямую помогают создавать удобный интерфейс — когда пользователь быстро понимает, как работает сайт или приложение.  За последние полгода я освоила HTML, CSS и JavaScript, создала несколько pet-проектов: сайт-визитку, блог и небольшой интернет-магазин. В процессе я научилась работать с Git и базовыми инструментами командной работы. Сейчас хочу стать частью команды, где смогу расти как FrontEnd-разработчик и создавать продукты, которыми удобно пользоваться людям». 👉 Почему это работает? Кандидатка подчёркивает soft skills из прошлой профессии (умение объяснять сложное, работа с людьми), а также демонстрирует уже сделанные шаги в ИТ (технологии, проекты). Это создаёт образ человека, который учится и уже приносит пользу. 🔹 Пример 3. Переход из продаж в Python-разработку «В течение 4 лет я работал в сфере продаж, где ежедневно общался с клиентами, искал решения их проблем и договаривался о результатах. Этот опыт дал мне сильные навыки коммуникации, работы под давлением и достижения целей. Когда я начал изучать Python, понял, что такой подход помогает и в разработке: нужно анализировать задачу, находить оптимальный путь и предлагать решение.  За последний год я прошёл несколько курсов, создал чат-бота, веб-приложение и систему для сбора данных. Все проекты выложил на GitHub. Мне нравится решать задачи, которые делают жизнь людей проще, и я хочу применить свои технические навыки и коммуникационный опыт в продуктовой команде». 👉 Почему это работает? Кандидат показывает, что опыт в продажах дал ему soft skills, которые делают разработчика сильнее: умение слушать клиента, достигать результата и работать под давлением. При этом он подтверждает техническую подготовку собственными проектами. Как строить свой ответ Используйте простую формулу: Прошлое — чем вы занимались раньше и какие навыки можно перенести в ИТ. Настоящее — что вы уже сделали для перехода: курсы, проекты, сертификаты. Будущее — чего хотите достичь и почему именно эта компания вам интересна. Пример: «В прошлом я работал в продажах и развивал коммуникативные навыки. Это помогает мне сейчас в работе с командой и клиентами. В течение последнего года я изучал Python, создал несколько проектов (чат-бот, веб-приложение), выложил их на GitHub. В будущем хочу стать частью продуктовой команды, где можно расти до роли мидла и участвовать в создании сложных сервисов». Что оценивает рекрутер и техлид Рекрутер смотрит на вашу мотивацию, способность учиться, коммуникабельность. Ему важно, чтобы вы вписались в культуру компании.   Техлид больше интересуется вашими техническими знаниями и логикой мышления. Но если вы сможете показать структурность, внимательность и желание расти, это будет огромным плюсом даже на начальном уровне. Практические советы Подготовьте 2–3 примера из прошлого опыта, которые можно «перепаковать» в ИТ-контекст (аналитика, работа с людьми, управление проектами, точность).   Обязательно покажите pet-проекты: сайт, приложение, бота, тесты. Это доказательство, что вы не только учились, но и практиковались.   Отработайте самопрезентацию вслух. Запишите себя на видео — вы сразу увидите, где звучите неуверенно.   Добавьте немного личной мотивации: «Я сознательно выбрал ИТ, потому что люблю решать задачи и создавать продукты, которыми пользуются люди». Не бойтесь, что ваш путь «необычный». Именно это и делает вас интересным кандидатом. Во многих ИТ-командах ценят разнообразие бэкграунда: кто-то пришёл из педагогики, кто-то из юриспруденции или медицины — и каждый приносит в команду новую перспективу. Ваша задача — не скрывать прошлый опыт, а показать его как преимущество. Помните: ИТ — это не только про код, но и про умение мыслить, коммуницировать, работать в команде. ✨ Правильная самопрезентация — это мост между вашей предыдущей сферой и новой профессией. Если вы верите в свой путь и умеете это донести, работодатель тоже в вас поверит.

Когда мы слышим слово «программист», представляется человек, который сидит за компьютером и пишет сотни строк кода. И кажется, что главное для него — знать синтаксис языков, владеть алгоритмами и разбираться во фреймворках. Именно технические знания воспринимаются как главный критерий успеха. Но на практике этого недостаточно. Представьте двух разработчиков с примерно одинаковым уровнем hard skills. Один закрывает задачи, но молчит на митингах и не умеет объяснить свою идею заказчику. Другой — не только пишет код, но и умеет донести сложные вещи простыми словами, сотрудничать с коллегами и находить решения в стрессовых ситуациях. Кого быстрее заметят менеджеры? Кого пригласят в сложные проекты? Кто станет тимлидом через несколько лет? Именно мягкие навыки (soft skills) определяют, кто останется «обычным исполнителем», а кто превратится в настоящего профессионала, с которым хотят работать и коллеги, и заказчики. Это то, что отличает хорошего разработчика от просто технически грамотного. 1. Умение объяснить сложное простыми словами Представьте ситуацию: джуниор-разработчик столкнулся с ошибкой и боится подойти к тимлиду, потому что «будет выглядеть глупо». Хороший разработчик поступает иначе — он формулирует вопрос так, чтобы коллега понял контекст и быстро помог. 👉 Почему это важно? Коммуникация экономит время команды. Тот, кто умеет описать проблему в двух предложениях, помогает двигать проект вперёд, вместо недель хаотичных попыток. 2. Культура обратной связи Многие программисты воспринимают code review как «критику». Но сильный специалист видит в этом способ расти. Он не защищается фразой «это ведь тоже работает», а анализирует, почему коллега советует иначе. 👉 Пример из практики: один девелопер постоянно оправдывался во время ревью, и его код часто оставался сырым. Другой — внимательно слушал комментарии, даже если не соглашался. Через полгода второй получил повышение, потому что показал способность учиться. 3. Приоритизация вместо «я сделаю всё» Новички часто хотят взять максимум задач и показать, что они быстрые. Результат — сорванные дедлайны и падающее качество кода. 👉 Что делает хороший разработчик? Он оценивает, что действительно критично, договаривается с менеджером и честно говорит: «Это я сделаю сегодня, это завтра, а здесь нужна помощь». Такой подход строит доверие. 4. Адаптивность к изменениям Фреймворк, с которым вы работали год, завтра может устареть. Компания может перейти из офиса на remote, а команда — сменить стек. 👉 Реальный пример: разработчик, который отказался освоить новый инструмент CI/CD, остался на «второстепенных задачах». Его коллега, который сказал «я не знаю, но научусь», через полгода уже настраивал пайплайны для всей команды. 5. Эмоциональная зрелость Представьте горячий дедлайн: менеджер давит, клиент нервничает, а баг не находится. Обычный разработчик может разозлиться, замкнуться или обвинить других. Хороший — выдыхает, структурирует проблему и спокойно предлагает варианты. 👉 Почему это решающе? Именно в кризисные моменты становится понятно, кто тянет команду вниз, а кто помогает держать баланс. 6. Желание обучать и делиться Настоящие профессионалы не боятся, что их «сделают лишними». Они делятся знаниями с джунами, проводят внутренние мини-лекции, пишут документацию. 👉 Результат: команда становится сильнее, а сам человек получает репутацию эксперта. Это прямой путь к роли тимлида или архитектора. Как прокачать soft skills разработчику - практический чек-лист. 🔹 Коммуникация Объясняйте свои мысли «языком человека с улицы» — если бабушка поняла, то и заказчик поймёт. Тренируйтесь формулировать проблему в формате: «Что происходит → Почему это проблема → Что нужно». Ведите заметки после митингов, чтобы избежать недопониманий. 🔹 Обратная связь Просите коллег во время code review не только о замечаниях, но и о сильных сторонах вашего кода. Привыкайте спрашивать: «Что я могу сделать лучше в следующий раз?» вместо «Почему ты критикуешь?». Попробуйте раз в неделю давать конструктивный фидбек кому-то из команды. 🔹 Тайм-менеджмент и приоритизация Каждый день начинайте с топ-3 самых важных задач. Используйте метод «Pomodoro» — 25 минут работы, 5 минут отдыха. Всегда предупреждайте менеджера о риске задержки, не дожидаясь дедлайна. 🔹 Адаптивность Раз в квартал изучайте новый инструмент или библиотеку (даже вне основного стека). Участвуйте во внутренних экспериментах: новый процесс, методология, инструмент. Тренируйте «гибкость мышления»: вместо «это не работает» говорите «как это можно сделать иначе?». 🔹 Эмоциональная зрелость Перед тем как ответить в стрессовой ситуации, сделайте паузу на 5 секунд. Используйте техники управления стрессом: дыхательные упражнения, короткие прогулки. Учитесь отделять личное от рабочего: критикуют код, а не вас. 🔹 Обучение и менторство Раз в месяц делайте мини-презентацию для коллег («фишки из проекта», «новый инструмент»). Помогайте джунам с задачами: обучение других закрепляет ваши знания. Документируйте решения — это навык, который ценит любая команда. Вывод Хорошего разработчика отличает не только то, как он пишет код, но и то, как он взаимодействует с людьми. Можно знать десятки языков программирования, строить сложные архитектуры и блестяще проходить технические тесты — но без развитых soft skills карьера часто останавливается на уровне «исполнителя». Soft skills — это про доверие, зрелость и способность делать больше, чем просто нажимать клавиши. Это то, что позволяет слышать и быть услышанным, строить здоровую атмосферу в команде, принимать вызовы и эффективно выходить из сложных ситуаций. 👨‍💻 Тот, кто развивает эти навыки, быстрее получает интересные проекты, легче проходит собеседования, становится заметным для руководства и постепенно выстраивает карьеру, в которой ценят не только «что ты умеешь», но и «каким коллегой ты являешься». Именно это и делает разницу между обычным программистом и тем, кого считают незаменимым специалистом.

План: 1. Різниця між синхронним та асинхронним кодом 2. Багатозадачність процеси й потоки, у чому різниця 3. Особливості багатозадачності в JavaScript 4. Асинхронні операції на практиці HTTP-запит як найпоширеніший кейс 5. Підходи до написання асинхронного коду: Promise    Async/Await Observable 6. Практичні поради Різниця між синхронним та асинхронним кодом Для початку давайте визначимо ці два терміни: Синхронний код - це код, який виконується послідовно, функція за функцією. Асинхронний код - код, який може виконуватися паралельно: наступна функція запускається, не чекаючи завершення попередньої. Щоб провести аналогію з реального життя, уявімо кухаря. Якщо кухар працює синхронно, то поки він не завершить приготування однієї страви, не переходить до наступної. Але це неефективно й призводить до втрати часу. Якщо ж кухар діє асинхронно, то поки м’ясо запікається в духовці, а на плиті закипає вода, він нарізає овочі. Тобто він один, але не стоїть без діла - виконує інші задачі, поки щось готується саме. Уявімо, що кухар - це процесор. А запікання м’яса в духовці - це завантаження файлу з мережі. Кухар може просто стояти й дивитись, як м’ясо готується. А може нарізати овочі, перевіряти, чи не з’явились нові замовлення, або скролити стрічку в соцмережі. Так само і з програмами: поки мережева карта завантажує файл, процесор не мусить чекати - він може малювати інтерфейс, оновлювати прогрес-бар чи виконувати обчислення у фоні. Але для цього потрібно правильно написати код - так, щоб він міг працювати асинхронно. Код який виконується синхронно ```js console.log("Початок"); console.log("Дія"); сonsole.log("Кінець"); ``` Результат: Початок Дія Кінець   Код який виконується асинхронно. і ``js console.log("Початок"); setTimeout(() => { // за допомогою setTimeout ми відкладаємо запуск коду на певний час   console.log("Дія через 2 секунди"); }, 2000); сonsole.log("Кінець"); ``` Результат: Початок Кінець Дія через 2 секунди Це не та багатозадачність, як у деяких інших мовах програмування. Тут не використовуються додаткові потоки, а все працює завдяки механізму подій. Але про це детальніше дал Багатозадачність: процеси й потоки, у чому різниця Багатозадачність в операційній системі - це можливість запускати та керувати кількома задачами одночасно. Наприклад, працювати в браузері, слухати музику, завантажувати файл і паралельно редагувати код у Visual Studio. На практиці процесор дуже швидко перемикається між усіма цими задачами, створюючи ілюзію одночасного виконання. Якщо процесор багатоядерний - деякі задачі справді можуть виконуватись паралельно. Багатозадачність тісно пов'язана з двома важливими поняттями - процесами та потоками. Процес (process) - це окремий екземпляр програми у пам'яті, який має власні ресурси: виділену область оперативної пам'яті, дескриптори файлів, змінні оточення тощо.  Потік (thread) - це одиниця виконання всередині процесу. Потоки одного процесу працюють незалежно, але мають спільний доступ до пам'яті та ресурсів процесу. Процеси дозволяють запускати різні програми одночасно - наприклад, Google Chrome, Visual Studio Code і т.д.  Потоки дають змогу виконувати кілька задач усередині однієї програми. Наприклад, у Visual Studio Code один потік відповідає за оновлення інтерфейсу, інший перевіряє помилки в коді, ще один формує підказки під час написання. Це, звісно, спрощений приклад - у реальності VS Code використовує ще й окремі процеси для розширень і мовних серверів. Операційна система керує як процесами, так і потоками. Вона розподіляє процесорний час між ними, ставить у чергу, може призупиняти виконання або відновлювати його за потреби. Давайте трохи адаптуємо наш приклад з кухарем із попереднього посту. Уявімо, що процес - це ресторан, а потік - це кухар. Ресторан має все необхідне для приготування їжі: кухонне приладдя, продукти, рецепти (це можна розглядати як пам’ять і доступ до інших ресурсів). Кухар читає рецепт і, використовуючи ресурси ресторану, готує страву - так само, як потік виконує інструкції нашої програми, використовуючи ресурси процесу. Якщо ресторан хоче готувати кілька страв одночасно, йому потрібно більше кухарів, які працюють паралельно на одній кухні. Аналогічно, якщо програма повинна виконувати кілька задач одночасно - завантажувати файли, обробляти введення, оновлювати інтерфейс - вона може використовувати кілька потоків. Коли ми створюємо програму і хочемо зробити її зручною для користувача, а також ефективною з точки зору використання ресурсів, які виділяє операційна система на процес, ми іноді починаємо використовувати потоки та прийоми багатопотокового програмування. Це велика окрема тема, і ми її зараз чіпати не будемо. Одна з причин - у JavaScript немає прямого доступу до потоків. Уточнення. Якщо ви хочете використовувати JavaScript і все ж таки працювати з потоками - у вас є Web Workers:  https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers  А якщо JavaScript виконується не в браузері (наприклад, у Node.js), тоді можна використовувати модуль `worker_threads`. Але варто розуміти, що це не частина стандарту мови, а можливість середовища виконання. Додаткові корисні ресурси по цій темі: https://www.youtube.com/@CoreDumpped - канал з короткими відео про те як працює комп'ютер. Modern Operating System by Andrew Tanenbaum - принцип побудови та роботи операційних систем (може бути викликом для новачка, але нормально як для технічної книжки) Особливості багатозадачності в JavaScript JavaScript працює в одному потоці - це означає, що в будь-який момент часу виконується лише один фрагмент коду. Увесь код, який ми пишемо, виконується у call stack: це структура, в яку потрапляють усі функції, що викликаються. Якщо одна з функцій виконується довго (наприклад, важке обчислення), усі інші задачі - включно з обробкою кліків, рендерингом чи відповідями від сервера - будуть чекати, поки call stack не звільниться. Щоб не блокувати цей єдиний потік, браузер надає асинхронні API (setTimeout, fetch, Web API). Коли ми викликаємо, скажімо, fetch(), у стек додається лише короткий виклик цієї функції. Власне мережевий запит виконується в окремому потоці, який створює браузер. Тобто, один потік виконує задачі які є у call stack, а інший потік чекає поки відповідь поверне сервер. Але асинхронна операція колись завершиться і треба механізм який віддасть нашому головному потоку результат роботи іншого потоку. Коли це стається колбек або проміс‑резолвер не додається одразу у call stack. Спершу він потрапляє до черги подій (task queue). За роботою черги стежить event loop. Його правило просте - поки стек порожній дістати першу задачу із черги і покласти у стек. Так ми досягаємо псевдобагатозадачності: основний потік виконує короткі шматки коду послідовно, а довгі операції «живуть» поза стеком. Коли довгі операції завершуються вони формують чергу задач, які треба виконати а event loop ці задачі закидає до стеку, коли call stack стає порожнім. Це максимально спрощене пояснення, і без візуалізації може здатися складним. Якщо хочете краще зрозуміти, дуже раджу подивитись відео Jake Archibald — "In The Loop" на YouTube (англійською).  https://www.youtube.com/watch?v=8aGhZQkoFbQ Або приходьте на мій курс JavaScript Поглиблений, де ми розбираємо це на практиці.  Також корисна стаття на MDN, де ці процеси описані докладніше. Асинхронні операції на практиці: HTTP-запит як найпоширеніший кейс Один з прикладів асинхронної операції - це запит на сервер через HTTP-протокол. Якщо організовувати запит через JavaScript у браузері без використання React, Angular або Vue.js, то це можна зробити за допомогою: fetch XMLHttpRequest Спеціалізована бібліотека, наприклад, Axios Ось так буде виглядати простий код написаний на fetch ```js fetch('https://jsonplaceholder.typicode.com/users')   .then(res => res.json())   .then(data => console.log(data)); ``` А так на axios (axios одразу повертає розпарсений JSON як response.data, на відміну від fetch, де потрібно викликати .json() вручну) ```js axios.get('https://jsonplaceholder.typicode.com/users')   .then(response => console.log(response.data)); ``` Якщо розглянути саме fetch то ось що відбулося під капотом: fetch створює HTTP запит вказавши HTTP метод, заголовки, тіло тощо Цей запит передається у вбудовану систему Web API - окрему від JavaScript середу, яка працює в іншому потоці. JavaScript не чекає відповіді - основний потік продовжує виконувати інший код fetch повертає Promise - об'єкт, що представляє асинхронну операцію, результат якої з’явиться пізніше Коли відповідь від сервера приходить, Web API кладе callback в чергу. Event Loop перевіряє, чи call stack порожній, і виконує цю мікрозадачу. Така поведінка дозволяє браузеру одночасно виконувати інші задачі, не чекаючи завершення запиту. Про використання асинхронного коду в JavaScript є [безкоштовний урок на YouTube](https://www.youtube.com/watch?v=cvR1EQ1R0EQ) Також більше про синтаксис Promise можна дізнатися в уроці [Асинхронний код. Promise](https://itvdn.com/ua/video/javascript-essential-ua/js-promise-ua) на ITVDN, а детальніше про варіанти організації такого коду буде написано далі. Підходи до написання асинхронного коду Складність роботи з асинхронним кодом полягає в тому, що обробка результату операції відбувається не відразу, а через певний час після її запуску. Ми ініціюємо асинхронну операцію й можемо виконувати інші завдання, але все одно маємо якось дізнатися про її завершення та обробити результат. Проблема в тому, що в цей момент програма вже виконує інші дії. Тому для обробки асинхронних операцій використовується push-модель взаємодії: отримувача даних (наш код) викликає провайдер даних - окремий механізм, який керує асинхронною операцією. По суті, розробнику потрібно відреагувати на подію завершення асинхронної операції. Для цього існує кілька підходів: callback-функція Promise async/await (синтаксичний цукор над Promise) Observables Використання функцій зворотнього виклику (callback) Почнемо з callback-функцій. Це найпростіший підхід, але він може призвести до заплутаного коду, особливо коли одна асинхронна операція запускає іншу, і так утворюється ланцюг. Уявімо, що маємо функцію downloadImage(url, callback), яка завантажує зображення асинхронно, не блокуючи основний потік. Перший параметр - це адреса зображення, яке потрібно завантажити, а другий - функція, яку буде викликано після завершення завантаження. При цьому саме зображення буде передане як параметр у callback. Приклад використання: ```js downloadImage(url1, image => document.body.append(image)) ``` На перший погляд усе просто. Але якщо потрібно завантажити кілька зображень послідовно, код стає менш зрозумілим: ```js downloadImage(url1, image => {             document.body.append(image);             downloadImage(url2, image => {                         document.body.append(image);                         downloadImage(url3, image => {                                     document.body.append(image);                         })             }) }); ``` Така вкладена структура швидко ускладнюється, особливо якщо замість одного рядка з DOM-змінами з’являється додаткова логіка. Подібний стиль називають "Pyramid of Doom", і його краще уникати. Один зі способів спростити обробку асинхронних викликів - це використання Promise. Використання Promise Promise - це об’єкт, який представляє асинхронну операцію. У перекладі з англійської promise означає «обіцянка». Можна уявити, що це обіцянка від браузера надати в майбутньому або результат операції, або помилку, пов’язану з її виконанням. Приклад використання: перепишемо попередню функцію downloadImage, щоб вона повертала Promise. ```js let promise = downloadImage(url1); promise.then(image => document.body.append(image)); ``` Тут ми все одно використовуємо callback-функцію, але передаємо її вже в метод .then() об’єкта promise. Це важливий момент: тепер асинхронна операція має об’єктне представлення, яке можна передавати як параметр у різні частини коду; можна будувати ланцюжки промісів, позбуваючись вкладеності, яка виникала з callback. Приклад: ```js downloadImage(url1)                          // отримуємо проміс .then(image => {                             // вказуємо що робити коли promise перейде в стан resolved             document.body.append(image);             return downloadImage(url2);                // виконуємо метод, який повертає promise }) .then(image => {                             // результат роботи попереднього промісу передається як значення             document.body.append(image);             return downloadImage(url3); }) .then(image => {             document.body.append(image); }); ``` Тепер код виглядає лінійним і набагато зручнішим для супроводу. У прикладах вище ми не розглядали, як саме створюється Promise, адже важливо зрозуміти мотивацію використання цих об’єктів. Тим більше, що більшість API браузера вже повертають готові проміси. Наприклад: ```js fetch('<https://jsonplaceholder.typicode.com/users>')   .then(res => res.json()); ``` Якщо хочете детальніше розібратися зі створенням Promise вручну - перегляньте документацію на MDN або мій відео урок на ITVDN. Async/await Супроводжувати синхронний код завжди простіше, ніж асинхронний. У 2012 році в мові C# з’явився синтаксичний цукор, який значно спростив роботу з асинхронними операціями: замість вкладених callback можна було використовувати послідовний синтаксис з новими ключовими словами async та await. Згодом цю концепцію перейняли й інші мови програмування, зокрема Python та JavaScript. В JavaScript підтримку async/await додали у 2017 році. Призначення ключових слів async - додається до функції та вказує, що вона завжди повертає Promise. await - використовується перед об’єктом-промісом, щоб "дочекатися" результату перед виконанням наступних рядків коду. Перепишемо попередній приклад із завантаженням зображень, використовуючи async/await: ```js let image = null;   image = await downloadImage(url1); document.body.append(image);   image = await downloadImage(url2); document.body.append(image);   image = await downloadImage(url3); document.body.append(image); ``` Тепер код виглядає як звичайний синхронний: немає вкладених callback, усе читається рядок за рядком. Можна подумати, що await "зупиняє" виконання, очікуючи на результат промісу. Насправді ж код не блокує основний потік - під капотом він перетворюється на машину станів, де кожен стан описує дію до або після await. Ще одна перевага async/await - знайомий синтаксис для обробки помилок: ```js try {             let image = null;               image = await downloadImage(url1);             document.body.append(image);               image = await downloadImage(url2);             document.body.append(image);               image = await downloadImage(url3);             document.body.append(image); } catch (ex) { // обробка помилки } ``` У результаті асинхронний код виглядає так само зрозуміло, як і синхронний, що значно спрощує його супровід. Observable Observable - це ще один підхід до організації асинхронного коду. Назва походить від однойменного патерна проєктування (Observer pattern), який описує створення об’єктів, за якими можна «спостерігати», отримуючи від них сповіщення. Тобто це реалізація подієвої моделі за допомогою ООП. У сучасному JavaScript ця ідея пішла далі й стала основою реактивного програмування та бібліотеки RxJS. Якщо Promise представляє одне майбутнє значення (успішне або помилкове), то Observable - це потік значень, які можуть з’являтися з часом. Можна уявити: Promise - це одна посилка, яку ви отримаєте в майбутньому; Observable - це підписка на журнал, нові випуски якого надходитимуть регулярно. Щоб створити Observable, використовують конструктор або готові оператори RxJS. Наприклад, функція downloadImages(urls) може завантажувати кілька картинок і відправляти їх «у потік» по мірі завантаження: ```js import { Observable } from 'rxjs';   function downloadImages(urls) {   return new Observable(subscriber => {     urls.forEach(url => {       downloadImage(url, image => {         subscriber.next(image); // надсилаємо картинку у потік       });     });     subscriber.complete(); // повідомляємо, що потік завершено   }); } ``` Щоб використати Observable, на нього треба підписатися за допомогою subscribe: ```js downloadImages([url1, url2, url3])   .subscribe({     next: image => document.body.append(image), // що робити з новим значенням     error: err => console.error(err),           // обробка помилок   }); ``` Переваги Observable працюють із потоком даних, а не з одним результатом; підтримують підключення операторів трансформації (фільтрація, мапінг, комбінування потоків); можна легко скасувати виконання (відписатися від потоку). Нижче приклад обробки даних через оператори. В RxJS оператори підключаються через метод pipe: ```js import { filter, map } from 'rxjs/operators'; downloadImages([url1, url2, url3])   .pipe(     filter(image => image.width > 100), // пропускаємо лише великі картинки     map(image => {       image.classList.add('highlight');       return image;     })   )   .subscribe({     next: image => document.body.append(image),     error: err => console.error(err),     complete: () => console.log('Готово')   }); ``` Таким чином, як і у випадку з Promise, можна будувати ланцюжки обробки. Але Observable значно гнучкіші: вони дозволяють працювати не лише з одним значенням, а з динамічною послідовністю даних у часі. Для глибшого занурення рекомендую офіційний гайд Observable на RxJS.dev. та відео уроки Observables. Частина 1, та Observables. Частина 2[1]  Практичні поради по работі за асинхроним кодом Не змішуйте підходи без потреби Якщо почали писати з async/await, не вставляйте всередину .then() без особливої причини. Це ускладнює читання. Обробляйте помилки Використовуйте try/catch для async/await або .catch() для Promise. У випадку Observable завжди додавайте обробку error у subscribe(). Скасовуйте непотрібні операції Для Observable використовуйте unsubscribe(), коли потік більше не потрібен. Для fetch можна застосувати AbortController, щоб зменшити навантаження й уникнути витоків пам’яті. Уникайте "Pyramid of Doom" Замість вкладених callback застосовуйте Promise, async/await або Observable. Використовуйте паралельне виконання Якщо операції незалежні, запускайте їх одночасно через Promise.all(). Ізолюйте логіку обробки Розділяйте завантаження даних та маніпуляції з DOM. Це спростить тестування й повторне використання коду. Логуйте стан і помилки Під час розробки виводьте у консоль ключові події асинхронних операцій, щоб відстежувати їх послідовність. Пам’ятайте про event loop Розуміння різниці між мікрозадачами й макрозадачами допоможе прогнозувати порядок виконання коду. Перевіряйте сумісність середовища Деякі API можуть бути відсутні у певних середовищах (наприклад, fetch у Node.js доступний лише починаючи з версії 18).