Список технологий, которые «обязательно нужно знать», обновляется каждый год и вгоняет в тревогу: только освоил один инструмент — вокруг уже обсуждают другой. Полезнее делить знания не по новизне, а по сроку жизни. Одно останется с вами на десятилетия и будет работать в любом стеке, другое устареет за пару лет вместе с модой. Ниже — как мы смотрим на это со стороны студии, которая нанимает разработчиков и передаёт им чужие проекты в поддержку.
Три слоя знаний
| Слой | Что входит | Срок жизни | Что даёт на работе |
|---|---|---|---|
| Основы | HTML и семантика, CSS, JavaScript, протокол HTTP, базы данных и SQL, система контроля версий | Десятилетия | Переносится в любой проект и любой стек |
| Инженерные навыки | Отладка, тестирование, чтение чужого кода, декомпозиция и оценка задач, работа с требованиями | Вся карьера | Отличает того, кому можно доверить задачу целиком |
| Инструменты | Фреймворки, сборщики, библиотеки компонентов, платформы развёртывания | Годы | Скорость здесь и сейчас, на текущем проекте |
Типичная ошибка новичка — начинать с третьего слоя. Фреймворк осваивается за месяц, если под ним есть основы, и не осваивается никогда, если их нет: человек умеет собирать страницу по образцу, но останавливается на первой же ошибке, которой не было в уроке.
Проверить, где вы находитесь, просто. Если при поломке вы открываете панель разработчика и смотрите запрос, ответ и содержимое страницы — основы есть. Если единственный способ починить — перебирать варианты из ответов на форуме, значит, изучен инструмент, а не то, на чём он стоит.
Основы, которые окупаются дольше всего
- Как устроен запрос. Что происходит от ввода адреса до отрисовки: имена, соединение, заголовки, коды ответов, кэширование, куки. Половина «загадочных» ошибок объясняется на этом уровне.
- Семантическая вёрстка и адаптив. Без них любая красота ломается на телефоне, а интерфейс становится недоступным для клавиатуры и программ чтения с экрана.
- JavaScript без обёрток. События, асинхронность, работа с данными, обработка ошибок. Фреймворк прячет это ровно до первой нестандартной задачи.
- Базы данных. Как хранится информация, что такое индекс и почему один запрос выполняется мгновенно, а похожий — минуту. Это знание пригодится на любом языке.
- Система контроля версий. Ветки, слияния, разбор конфликтов, чтение истории. Умение понять, зачем была сделана правка год назад, экономит дни.
- Основы безопасности. Что такое внедрение кода в запрос, почему нельзя доверять данным из формы, где хранить ключи доступа.
Инженерные навыки
Это то, чего почти нет в курсах, но именно по нему видно уровень. На проектах поддержки, где мы получаем чужой код без документации и без автора, ценность этих навыков особенно заметна.
- Отладка по шагам. Сформулировать предположение, проверить его наименьшим действием, отбросить и перейти к следующему. Не «поменяю тут и посмотрю», а сужение области поиска.
- Чтение чужого кода. Понять устройство незнакомого проекта, не переписывая его. Первый порыв — «здесь всё плохо, надо заново» — почти всегда ошибочный и дорогой.
- Тестирование. Хотя бы проверки на критичные сценарии. Их ценность становится очевидной при первом же изменении, которое сломало соседнюю часть системы.
- Оценка задач. Разложить работу на части, назвать, где неопределённость, и не обещать срок, которого не может быть.
- Работа с требованиями. Задать вопросы до начала, а не после сдачи. Большая часть переделок рождается из непроясненной постановки, а не из плохого кода.
Как выбирать инструмент
Не по числу упоминаний в опросах, а по трём вопросам:
- Используют ли его в проектах, которые вам интересны и до которых вы реально можете дотянуться при поиске работы.
- Есть ли внятная документация и живое сообщество: сколько времени займёт поиск ответа на непопулярный вопрос.
- Можно ли на нём сделать что-то полезное за выходные. Если за это время не получается собрать работающую мелочь, порог входа высокий, и учить придётся долго.
Ещё один ориентир — насколько инструмент близок к основам. Тот, что учит вас устройству платформы, окупается дважды: знания останутся и после того, как сам инструмент выйдет из моды. Тот, что прячет платформу целиком, даёт быстрый старт и мало что оставляет после себя.
Искусственный интеллект в ежедневной работе
Помощники на основе языковых моделей действительно ускоряют рутину: набросок функции, объяснение незнакомого куска кода, подготовка тестов, разбор сообщения об ошибке, черновик документации. Отказываться от этого нет смысла — как в своё время не было смысла отказываться от подсветки синтаксиса.
Опасность в другом: принимать сгенерированный код без понимания вдвойне рискованно, потому что искать ошибку всё равно придётся вам, а автора рядом нет. Правило простое — использовать как ускоритель там, где вы способны проверить результат, и не использовать там, где проверить не можете. Отдельно стоит помнить про данные клиента: ключи доступа, персональные данные и содержимое закрытых репозиториев в чужие сервисы не отправляют.
Побочный эффект, который мы наблюдаем: разрыв между теми, у кого есть основы, и теми, у кого их нет, увеличился. Первым помощник экономит часы, вторым — создаёт код, который они не могут ни объяснить, ни починить.
Как учиться, чтобы знания оставались
- Выбрать задачу, а не тему. «Сделать сервис учёта заказов» лучше, чем «изучить фреймворк»: под задачей знания складываются в систему.
- Довести до работающего состояния и выложить. Незаконченный проект не учит завершению, а именно оно оплачивается.
- Разбирать чужой код: открыть небольшую библиотеку и понять, как она устроена внутри.
- Возвращаться к своим старым проектам. Способность увидеть в них ошибки — самая честная линейка роста.
- Записывать решения: короткая заметка о том, как была найдена причина ошибки, экономит время при следующей встрече с ней.
- Просить проверку кода у более опытного коллеги и относиться к замечаниям как к бесплатному обучению.
На что смотрим мы, когда берём человека в команду
Ни в одном проекте не пригождается весь список технологий из резюме. Гораздо важнее другое: как человек рассуждает о незнакомой задаче, задаёт ли уточняющие вопросы, умеет ли объяснить своё решение и признать, чего не знает. Разработчик, который честно говорит «не работал с этим, но разберусь за столько-то и вот с чего начну», надёжнее того, кто перечислил двадцать инструментов и не может рассказать ни про один.
Второй критерий — умение довести до конца. Работающая мелочь, доделанная и запущенная, говорит больше, чем незавершённое сложное начинание.
Как не выгореть от объёма
Всё знать невозможно, и это нормальное состояние отрасли, а не ваш личный пробел. Разумная стратегия — глубоко в одном направлении и поверхностно в смежных: настолько, чтобы понимать коллег и не бояться заглянуть в незнакомую часть проекта. Полезно раз в несколько месяцев пересматривать список того, что «надо выучить», и вычёркивать оттуда пункты, добавленные из тревоги, а не из потребности.
И последнее: скорость появления новых инструментов выше, чем скорость их закрепления. Многое из того, что сегодня кажется обязательным, через год не вспомнят. Основы за это же время не изменятся.
Если команде не хватает рук или нужного опыта на конкретный этап, мы подключаем своих специалистов на нужный срок — это аренда IT-команды. Формат подходит и когда нужно закрыть одну роль, и когда требуется собрать группу под отдельное направление.
