Разработка в 2025 году — это уже не только про умение писать код. Важно уметь работать в связке с ИИ, быстро адаптироваться к новым инструментам и смотреть на задачи шире, чем строки кода. Автоматизация ускоряет процессы, языковые модели становятся полноценным помощником, а кибербезопасность требует внимания как никогда раньше.

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

Что формирует будущее разработчиков

1. ИИ и языковые модели. Инструменты вроде Cursor/Windsurf и LLM помогают быстрее и качественнее выполнять то, что вы уже умеете, или разобраться в новой теме. LLM берут на себя «черновую» работу: исправляют опечатки, улучшают оформление кода, помогают с декомпозицией задач и первичным код‑ревью. Это снижает нагрузку и освобождает время под архитектурные решения.

2. Кибербезопасность. С ростом объема данных и активным использованием ИИ‑решений увеличивается и число атак. В 2025 году безопасность уже не «дополнительная опция», а критически важный аспект разработки. В приоритете: оперативное устранение уязвимостей, поддержка зависимых библиотек в актуальном состоянии, а также проектирование безопасных систем.

Главные скиллы

— Промпт‑инжиниринг и итеративный подход. Чем лучше вы понимаете и формулируете задачу для LLM, тем лучше результат. Разбивайте сложные задачи на небольшие, пошагово уточняйте вводные, добавляйте контекст, референсы и критерии качества.
 — Умение адаптироваться к изменениям. Мир меняется быстро: нужна гибкость и готовность учиться новым инструментам и подходам.
 — Осознанное применение ИИ. ИИ ускоряет рутину, но не заменяет понимания. Код или решения без осознания внутренних механизмов сложнее поддерживать; сырые и неадаптированные ответы часто дороже, чем написать с нуля.
 — Критическое и системное мышление. Хороший разработчик видит систему целиком, задает вопросы, сравнивает варианты и думает на несколько шагов вперед: архитектура, влияние изменений, риски и стоимость владения.

Как развиваться разработчику

1. Книги, курсы и пет‑проекты. Рабочая связка: цель → план → небольшой прототип → разбор ошибок. LLM помогают собрать персональный план обучения: перечисляете, что знаете и что хотите изучить, — получаете черновой roadmap и список практик.

2. Конференции и митапы. Это возможность обменяться опытом и задать вопросы. Сильно прокачивает подготовка собственного доклада: структурируете знания, получаете обратную связь, улучшаете подходы.

3. Полезные тг‑каналы. Удобно следить за анонсами моделей, обновлениями LLM и промпт‑подходами в профильных каналах. Выберите несколько источников и регулярно сверяйте советы с документацией и собственным кодом.

Виртуальные потоки кажутся простым способом ускорить I/O. Но на Java 21 многие сталкивались со стагнацией из‑за пиннинга: когда код входит в synchronized и внутри выполняет блокирующую операцию (I/O, wait(), ожидание монитора), виртуальный поток «прибивается» к carrier‑потоку и не может отмонтироваться. Под нагрузкой это быстро исчерпывает пул carrier‑потоков и «замораживает» обработку. Часто как побочный симптом растет число соединений в CLOSE_WAIT, потому что обработчики не успевают корректно закрывать сокеты.

Что изменилось:

В JDK 24 реализован механизм, благодаря которому виртуальные потоки больше не пиннятся внутри synchronized, включая ожидание монитора и Object.wait()): JVM умеет корректно «размонтировать/перемонтировать» поток. Это почти полностью снимает главный источник проблем с Loom и в большинстве случаев избавляет от необходимости переписывать synchronized на ReentrantLock ради масштабируемости. Редкие источники пиннинга остались вне synchronized, например, JNI — их стоит искать профилированием и наблюдаемостью (JFR‑события).

Дальше — еще удобнее в JDK 25:

Scoped Values становятся финальными — надежная альтернатива ThreadLocal для передачи неизменяемого контекста без накладных расходов и утечек. Structured Concurrency остается в статусе preview и хорошо сочетается с моделью виртуальных потоков.

Что имеет смысл сделать уже сейчас без перелома архитектуры:

1. Планировать переход на JDK 25, чтобы получить финальные Scoped Values и полный набор улучшений Loom.

2. Запускать задачи через Executors.newVirtualThreadPerTaskExecutor() или фабрику Thread.ofVirtual() — так вы используете Loom «как задумано».

3. Проаудировать горячие пути — убрать блокирующие вызовы из‑под synchronized, сузить критические секции. При необходимости оставлять ReentrantLock, но не рассчитывать на него как на универсальное лекарство от пиннинга.

4. Включить наблюдаемость — отслеживать события пиннинга виртуальных потоков, рост очередей/времени ожидания и аномальный CLOSE_WAIT.

5. Там, где сегодня используются тяжелые ThreadLocal, по возможности переносить на Scoped Values после обновления до JDK 25 и обновлять библиотеки до версий с поддержкой Loom.

Как именно работает исправление пиннинга и как лечить «больные места» рассказали в статье Виртуальные потоки в Java: эволюция, практика, подводные камни.

Зачастую бизнес‑объекты в информационных системах хранятся в классических реляционных базах данных, где каждому атрибуту объекта соответствует колонка в таблице.

Чтобы изменить такую объектную модель, например, добавить или удалить атрибут, нужно внести изменения в схему базы данных, то есть выполнить DDL‑операцию. Она сопровождается блокировками таблиц и увеличением времени простоя при работе с данными. Кроме того, при увеличении числа атрибутов можно превысить ограничение на количество колонок в таблице. Например, в Postgres их можно создать не более 1600.

Эти проблемы можно устранить, используя хранение данных в формате JSON. Основные преимущества такого подхода:

• отказ от фиксированной структуры таблиц;

• гибкость без необходимости изменения схемы.

Обращение к динамическим полям может осложниться при работе с Hibernate до версии 6.2. Более ранние версии не позволяют обращаться к полям внутри JSON на уровне HQL, что ограничивает возможности фильтрации и сортировки. Поэтому оптимальный вариант — использовать Native SQL. Hibernate позволяет регистрировать SQL‑функции, чтобы вызывать их из HQL‑запросов. Пример регистрации такой функции для Postgres приведен ниже:

registerFunction("jsonQuery",
    new SQLFunctionTemplate(StandardBasicTypes.STRING,
        "jsonb_path_query_first(?1, ?2)::varchar"));

• Первый параметр — колонка в БД, внутри которой хранится JSON, выполняющий запрос.

• Второй параметр — запрос в виде JSON Path, который позволяет добраться до определенных полей.

Пример структуры JSON и использования на ней SQL-функции в запросе:

{
  "CPU_Brand": "Intel",
  "CPU_Model": "Xeon 8380",
  "RAM_Size_GB": 64
}

SELECT obj.id
FROM userObject obj
WHERE jsonQuery(obj.json, '$.CPU_Brand') = 'Intel'

При работе с более сложными вещами, например, фильтрация объектов с вложенными данными, SQL Server требует применения конструкций CROSS APPLY и openjson.

Когда аналитику сложно взаимодействовать с людьми, выполнение рабочих задач становится мучением. И даже может стать причиной выгорания. Чтобы добиться максимально эффективного результата в работе, нужно развивать навыки общения. Так будет проще излагать мысли и отстаивать свою позицию.

Вот некоторые рекомендации, которые помогут аналитикам лучше справляться с вызовами, связанными с коммуникацией:

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

2. Сохраняйте фокус на конечной цели — решение задачи для конкретного пользователя.

3. Практикуйте публичные выступления, активно участвуйте в дискуссиях и не пренебрегайте общением с коллегами и офлайн‑коммуникациями.

4. Защищайте свои границы при взаимодействии с другими людьми и учитесь «держать планку» в конфликтах.

5. Работайте над образом надежного и ответственного профессионала, соблюдайте дедлайны и выполняйте договоренности.

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

Неопределенность — одна из главных трудностей, с которой аналитик сталкивается при обработке требований в сфере информационной безопасности (ИБ). Требования часто сформулированы расплывчато и без конкретики. В процессе внедрения программных продуктов имеется классический набор требований из нормативной документации: ИАФ, УПД, ОПС, РСБ и т.д. В части реализации мер по регистрации событий ИБ (РСБ) аналитик внедрения сталкивается с несколькими группами требований:

1. Общие требования задают базовые правила для защиты данных, определяют сроки хранения и перечень источников событий, которые необходимо фиксировать. 

2. Общий перечень событий, регламентируемый нормативной документацией, включает в себя аутентификацию и авторизацию, управление учетными записями, запуск программных процессов, установку и удаление ПО и иные действия пользователей. Перечень обычно описан обобщенно, что позволяет заказчику предлагать любые требования. Аналитику необходимо зафиксировать и согласовать перечень, провести демо, чтобы избежать разночтений в будущем.

3. Состав полей событий безопасности наполнен идентификатором события, датой и временем, результатом выполнения, идентификатором субъекта, объекта или ресурса доступа и другими данными. Чтобы корректно определить состав, важно учитывать потребности инженера ИБ со стороны заказчика. 

4. Мониторинг предусматривает проработку механизмов просмотра и анализа, передачи в SIEM-систему. 

Чем меньше команда продукта, тем ниже риск того, что взгляды на реализацию разойдутся. Дополнительные согласования, как правило, не нужны, ведь все участники понимают цели и задачи одинаково.

Ситуация начинает выходить из‑под контроля, когда задачи становятся сложнее, а команда — больше. Итоговое решение может не соответствовать ожиданиям и не учитывать глобальное видение продукта.

Чтобы этого избежать, аналитики и продакты проводят приемку аналитики. Аналитик, проработав задачу и определив, как ее лучше решить, приносит свое видение продакту еще до начала разработки. В ходе обсуждения они вместе корректируют спорные моменты и приходят к общему решению. Это позволяет объединить разные взгляды и улучшить качество финального результата.

Три важных плюса приемки аналитики:

1. Два взгляда на решение — сокращается количество ошибок, команда на несколько шагов ближе к истине и идеальному решению.

2. Действия согласованы — продакт заранее знает, что именно будет реализовано и может объяснить на этапе тестирования или демонстрации продукта, почему сделано так, а не иначе.

3. Усилия команды объединены — аналитик не остается один на один с задачей и понимает, что совместная работа помогает эффективнее выполнить задачу, улучшить реализацию и повысить удовлетворенность команды и клиентов.

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

Происходит это по нескольким причинам: 

• специализация на одной области,

• предвзятое мышление,

• стремление к идеальному результату, без учета реальности или ограничений. 

Чтобы не допустить «‎влюбленности»‎ в свое решение, важно:

1. Проверять гипотезы — подвергать свое решение сомнению, формулировать его как гипотезу, которую нужно проверить. 

2. Рассматривать альтернативные решения — задавать себе вопрос «А как еще можно достичь этих целей?».

3. Расширять фокус и обучаться — смотреть на решение с позиции наблюдателя и быть открытым для новых идей и подходов.

4. Получать обратную связь — не бояться критики, коллеги могут заметить то, что было пропущено.   

«‎Влюбленность»‎ в свое решение может поставить работу в тупик. Поэтому необходимо сохранять гибкость и быть готовым рассматривать альтернативные подходы. А еще помнить, что решение — это не характеристика человека. Оно может быть как правильным, так и неправильным, как идеальным, так и не очень.

Аналитику на проектах или продуктах приходится довольно много работать с требованиями. А в сложных проектах, исследованиях и стартапах неопределенность требований — достаточно частое явление. На 100% избавиться от неопределенности не получится: мы не можем контролировать абсолютно все. Но зато можем снизить риски и исключить потери для компании за счет снижения неопределенности. 

Вот небольшой план действий, который поможет работать в условиях неопределенности:

• Создайте mindmap и используйте как базу знаний, чтобы исключить вероятность что-то упустить.

Как создать mindmap: разбиваете свою зону ответственности на области неопределенности → раскладываете области на аспекты → аспекты разделяете на вопросы, на которые нужно ответить и получить решение, и инструменты, которые нужны для ответа на вопросы.

• Составьте чек-лист для типовых задач — так вы сможете быстро выполнять стандартные задачи, особенно если это срочные дела: в помощь аспекты, вопросы и инструменты из mindmap’а.

• Уточняйте вопросы при помощи инструментов.

• Действуйте итеративно — всегда возвращайтесь к тем вопросам, которые сразу не удалось прояснить.

• Если кажется, что что-то упустили, перепроверяйте.

• Актуализируйте — если появляются новые инструменты и вопросы, которые помогли уточнить необходимую информацию, добавляйте их в mindmap.

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

Умение задавать вопросы и делать это своевременно — один из самых полезных навыков. Во-первых, это ускоряет процесс, а, во-вторых, в результате получается именно то, что нужно клиенту. Вроде всё просто. Но почему мы продолжаем пренебрегать вопросами, положившись на «потом как-нибудь разберусь»? Всему виной страх осуждения и боязнь выглядеть некомпетентно. Отсюда получаем: незаданный вопрос — невыявленную потребность — несобранные требования — реализованный не в полном объеме проект. Коммуникация провалена на самых ранних этапах. Рассказываем, как же её наладить и почему не стоит бояться задавать глупые вопросы.

1. Помните: самый глупый вопрос — незаданный вопрос.

2. Задавайте уточняющие вопросы (даже если их много). Чем больше информации на старте проекта, тем меньше проблем в конце.

3. Перепроверяйте поступающую информацию от клиента — он тоже человек и может ошибаться, а еще искажать факты или умалчивать то, что «очевидно». 

4. Не пытайтесь додумывать ответы собеседника — не поняли до конца, где-то есть пробелы, значит нужно уточнять и переспрашивать.

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

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