Я Java-разработчик и в основном работаю с backend: Spring Boot, базы данных, интеграции, авторизация, WebSocket — всё то, что обычно находится за интерфейсом.

В какой-то момент я поймал себя на мысли: я каждый день пользуюсь мессенджерами, но плохо понимаю, как они устроены внутри. Окей, JWT, WebSocket, PostgreSQL, Redis — это понятно. Но что технически означает фраза "end-to-end encryption"? Как сервер доставляет сообщения, если он не должен их читать? Где живут ключи? Что хранится в базе? Что происходит, если у пользователя два устройства?

Решил разобраться через практику. Написал мессенджер с нуля. Назвал Chaos Messenger.

Сразу честно: криптографическую часть я изучал вместе с Claude и ChatGPT — читал спецификации X3DH и Double Ratchet, разбирал примеры, задавал вопросы, пока не сложилась цельная картина. Frontend тоже делался с активной помощью ChatGPT: я backend-разработчик, React для меня не основная среда. Но архитектура, backend, интеграция WebCrypto, модель конвертов, хранение сообщений и принципиальные решения — мои.

Для меня AI здесь был не заменой понимания, а инструментом — примерно как документация, Stack Overflow и ревью коллег. Без понимания threat model и архитектуры такой проект всё равно не собрать.

В статье расскажу, как работает E2EE изнутри: как устанавливается сессия через X3DH, как каждое сообщение получает отдельный ключ через Symmetric Ratchet, почему сервер хранит только зашифрованные конверты, и какие ошибки я допустил по дороге.

Стек: Spring Boot 3, React 18, WebCrypto API, PostgreSQL, Redis, WebSocket/STOMP, Prometheus, Grafana.

Важная оговорка про web-E2EE

Когда я говорю, что сервер не может прочитать сообщения, я имею в виду backend, базу данных, WebSocket-слой и уже сохранённые ciphertext-конверты. У них нет ключей и plaintext.

Но у web-E2EE есть отдельная проблема: frontend-код тоже приходит с сервера. Теоретически скомпрометированный сервер может отдать изменённый JavaScript, который украдёт ключи или plaintext до шифрования. Это ограничение не конкретно моего проекта, а браузерной модели в целом.

Поэтому корректная формулировка такая: backend не получает ключи и не может расшифровать уже переданные или сохранённые сообщения. Защита от подмены клиентского кода — отдельный слой безопасности: подпись сборок, независимая верификация клиента, desktop/mobile-приложения, reproducible builds.

Почему обычный подход не работает

Большинство "мессенджеров" на GitHub выглядят примерно так:

Сервер знает всё. Видит каждое сообщение. Если БД утекла — утекла вся переписка. Если сервер взломали — читай что хочешь. Если завтра компания решит продать данные — технически ничего не мешает.

E2EE решает это радикально: backend не получает ключи и не хранит plaintext. Сообщение шифруется на устройстве отправителя до отправки в сеть, а расшифровывается только на устройстве получателя.

Это уже не вопрос политики конфиденциальности в стиле "мы обещаем не читать". Это архитектурное ограничение: если у сервера нет ключа, он не может превратить ciphertext обратно в текст.

Звучит как магия. На самом деле — два протокола и немного WebCrypto.

Главная идея: конверты

Представь что Алиса хочет написать Бобу. Вместо того чтобы положить письмо на стол и надеяться что никто не прочитает — она кладёт его в запечатанный конверт. Конверт может открыть только Боб своим ключом. Сервер просто передаёт конверт не заглядывая внутрь.

Именно так это работает в коде. В базе данных у меня это выглядит так:

Когда я впервые увидел

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

А вот что сервер возвращает при запросе списка чатов через API:

Не

. Не

. Буквально

(DevTools → Network → ответ API с

)

Откуда берутся ключи: X3DH

Главный вопрос: как Алиса и Боб получают общий секрет, если они никогда раньше не общались? И как сделать это так, чтобы сервер только помог передать публичные данные, но сам не смог вычислить итоговый ключ?

Для этого используется X3DH — Extended Triple Diffie-Hellman, протокол из экосистемы Signal. Его задача — установить общий секрет между двумя устройствами, используя долгосрочные и временные ключи.

Что хранится на сервере

Когда пользователь регистрирует устройство, он загружает на сервер пакет публичных ключей:

На сервер уходят только публичные части. Приватные ключи сериализуются и хранятся локально в браузере — и никогда не покидают устройство в сеть.

Здесь важно сказать честно: хранение приватных ключей в

Более строгий вариант — использовать Web Crypto API с

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

В браузерных E2EE-приложениях обычно приходится выбирать между несколькими вариантами:

• Сериализуемые ключи в localStorage или IndexedDB — проще реализовать, но нужно очень серьёзно относиться к XSS и целостности frontend-кода.
• extractable: false + IndexedDB — безопаснее, но сложнее в реализации и восстановлении состояния.
• Нативное secure storage вроде Android Keystore или iOS Secure Enclave — лучший вариант для мобильных клиентов, но он недоступен обычному web-приложению.

В текущей версии Chaos Messenger используется первый вариант. Это осознанный компромисс для pet/open-source проекта и удобного запуска в браузере. Переход на non-extractable ключи и более строгую модель хранения стоит в roadmap.

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

Установка сессии

Когда Алиса открывает переписку с Бобом впервые, происходит следующее:

В классическом X3DH четвёртая DH-операция с one-time prekey опциональна: она выполняется, если сервер выдал доступный OPK получателя. В моей реализации устройство публикует набор one-time prekeys при регистрации, поэтому первое сообщение обычно использует DH4. Если OPK закончились, сессию всё равно можно установить через остальные DH-компоненты, но это уже менее сильный вариант.

Боб, получив конверт с эфемерным публичным ключом Алисы, повторяет те же операции со своими приватными ключами и получает тот же самый

. Математика симметрична.

Сервер в этот момент видит только публичные ключи и зашифрованный конверт. Он помогает устройствам найти друг друга, но не участвует в вычислении секрета.

Получить

Как шифруется каждое сообщение: Symmetric Ratchet

X3DH даёт нам стартовый

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

Решение — симметричный ratchet. После каждого сообщения цепочка ключей продвигается вперёд:

Визуально это выглядит так:

используется для шифрования одного сообщения через AES-GCM, после чего уничтожается. Если атакующий компрометирует

— он прочитает только второе сообщение.

В рамках такой симметричной цепочки это даёт forward secrecy назад по цепочке: зная текущий или отдельный

Само шифрование сообщения:

А вот что уходит на сервер — живой пример из DevTools:

Сервер получает

и

. Расшифровать без

Важная оговорка: это ещё не полный Double Ratchet

В этом проекте реализован Symmetric Ratchet — цепочка, где из

для каждого сообщения выводится отдельный

Это защищает прошлые сообщения: если атакующий узнает текущий ключ или отдельный

, он не сможет откатить HMAC назад и получить старые ключи.

Но это не полный Double Ratchet из Signal Protocol.

В полном Double Ratchet есть ещё DH ratchet step: стороны периодически выполняют новый Diffie-Hellman обмен и обновляют root key. Это даёт break-in recovery — возможность восстановить безопасность будущих сообщений после компрометации части состояния.

В моей реализации DH ratchet step пока нет. Если атакующий получит актуальное состояние сессии на устройстве и сможет продолжать его читать, он сможет расшифровывать будущие сообщения до переустановки сессии. Это честное ограничение текущей версии, и оно стоит первым пунктом в roadmap.

Мультиустройство: один пользователь, несколько конвертов

Первый неочевидный момент: в E2EE сообщение адресуется не просто пользователю, а конкретным устройствам пользователя.

Если у Боба два устройства — телефон и ноутбук — нужен отдельный encrypted envelope для каждого устройства. Сервер не может взять один конверт, расшифровать его и "переупаковать" для второго устройства: у него нет ключей и он не знает plaintext.

Значит при отправке сообщения нужно зашифровать его отдельно для каждого устройства каждого участника чата.

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

Сервер: хранение и доставка конвертов

На сервере сообщение создаётся с контентом

, а конверты сохраняются отдельно:

После сохранения — fanout по WebSocket. Каждое устройство получает свой конверт и только его:

Это важное отличие от обычного WebSocket-чата. В обычном чате сервер рассылает одно и то же событие всем участникам. В E2EE-чате сервер рассылает разные события разным устройствам: payload для каждого устройства содержит свой

Топик

— строго персональный. Устройство А не получает конверт устройства Б. Никакого broadcast — только адресная доставка.

Архитектура целиком

Баг который долго не замечал

В панели чатов показывается превью последнего сообщения. Я реализовал это через

Запускаю — в списке чатов у всех написано

.

Конечно. Сервер же не знает что там написано.

Я полчаса думал как решить это на сервере. Потом дошло: нельзя решить это на сервере — у него нет ключей. Решение только на клиенте.

После того как пользователь открыл чат и сообщения расшифровались — кешируем последнее в памяти:

Это хороший пример того, как E2EE меняет привычное мышление backend-разработчика. В обычном приложении preview — это поле в SQL-запросе. В E2EE-приложении preview — это локальное клиентское состояние, потому что только клиент видел plaintext.

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

Rate limiting: дыра которую легко не заметить

Эндпоинт

отправляет SMS с кодом. Без защиты любой скрипт может дёргать его тысячи раз — это называется SMS pumping fraud, SMS стоят реальных денег.

Redis у нас уже был для хранения онлайн-статусов. Добавил rate limiting поверх него:

При превышении — HTTP 429 с заголовком

. Клиент знает через сколько секунд можно повторить.

Важный нюанс: в текущей реализации, если Redis недоступен, сервис не блокирует авторизацию полностью. Для pet-проекта это приемлемый компромисс: лучше рискнуть одним лишним SMS, чем положить вход в приложение.

В production я бы сделал строже: fallback in-memory лимит на инстанс, отдельные лимиты по IP и телефону, антифрод-логику и алерты на всплески отправки кодов.

Авторизация WebSocket

Отдельная история — авторизация WebSocket соединений. HTTP-эндпоинты защищены Spring Security автоматически, но WebSocket — другое дело. STOMP-соединение устанавливается один раз, и нужно проверять JWT при каждом подключении.

Отдельно важно не только проверить JWT, но и связать WebSocket-соединение с конкретным устройством. Пользователь может быть один, но устройств у него несколько, а encrypted envelope адресован именно

Поэтому при подключении я проверяю не только токен, но и

: устройство должно быть зарегистрировано и принадлежать текущему пользователю. Иначе легко случайно превратить per-device E2EE-доставку обратно в обычный broadcast по пользователю.

Что получилось — живые скрины

Что реализовано:

• E2EE-модель с per-device encrypted envelopes
• X3DH session setup + Symmetric Ratchet + AES-GCM
• Мультиустройство
• Личные и групповые чаты
• Realtime доставка через WebSocket/STOMP
• Статусы SENT → DELIVERED → READ
• Редактирование и soft delete сообщений
• Online presence, typing indicator
• Фото-вложения
• Поиск пользователей
• Rate limiting на SMS через Redis
• Prometheus метрики + Grafana дашборд
• Swagger UI с JWT авторизацией
• 24 backend-теста на Testcontainers, 12 frontend на Vitest, E2E на Playwright
• GitHub Actions CI

Что ещё не сделано:

• Полный Double Ratchet с DH ratchet step и break-in recovery
• Ротация signed prekey и аккуратное пополнение one-time prekeys
• Более строгая модель хранения приватных ключей на клиенте: non-extractable CryptoKey + IndexedDB
• Защита от подмены frontend-кода: подпись сборок, независимая верификация клиента, reproducible builds
• Android-клиент с Android Keystore
• Реальный SMS-провайдер вместо кода в backend-логах
• Push-уведомления без утечки содержимого сообщений
• Более строгая metadata-модель для групповых чатов

Главный инсайт

E2EE — это архитектурное решение, а не библиотека.

Нельзя взять обычный Spring Boot чат и просто "включить шифрование". Нужно с самого начала проектировать систему так, чтобы backend не был участником доверенной зоны: он не должен получать plaintext, не должен иметь ключи и не должен уметь пересобирать сообщение из данных в базе.

Это меняет почти всё:

• структуру БД — вместо текста появляются encrypted envelopes
• API — сервер отдаёт [encrypted], а не preview сообщения
• WebSocket — доставка идёт не по пользователю, а по конкретному устройству
• мультиустройство — одно сообщение превращается в несколько ciphertext-конвертов
• frontend — становится полноценной криптографической частью системы, а не просто UI

Второй инсайт: мессенджер — это не "чат с WebSocket". В E2EE-модели это система доставки зашифрованных конвертов с адресацией по устройствам. Как только это принимаешь, многие странные на первый взгляд решения становятся логичными.

Репозиторий

Код открыт: github.com/vaazhen/chaos-messenger

В репозитории есть README на русском и английском, диаграммы, скриншоты, security audit, Docker Compose и запуск одной командой.

Проект не претендует на уровень production-криптомессенджера вроде Signal. Это учебный и инженерный open-source прототип, цель которого — показать, как E2EE меняет архитектуру backend, frontend и realtime-доставки.

Если вы делали что-то похожее — особенно интересно сравнить подходы к ротации prekey-ов, хранению non-extractable ключей в браузере и реализации DH ratchet step. Вопросы и критика приветствуются.

Когда Илон Маск в июле 2023 года назвал ситуацию с платформой «смертью от LLM», он оказался прав в отношении форума, но не бизнеса. В отличие от Chegg и других образовательных площадок, которые пали жертвой генеративного ИИ, Stack Overflow научилась монетизировать свой огромный архив контента.

Stack Overflow удалось удвоить годовую выручку до 115 млн долларов. Убытки компании также сократились с 84 млн до 22 млн долларов благодаря жесткой оптимизации расходов и массовым сокращениям.

Как мёртвый форум приносит живые деньги

Компания радикально изменила бизнес-модель. Вместо рекламы на форуме основной источник дохода теперь — корпоративное решение Stack Internal. Это генеративный ИИ-инструмент, обученный на миллионах вопросов и ответов платформы за годы её существования. Продуктом пользуются 25 000 компаний по всему миру .

Второй поток выручки — лицензирование данных ИИ-компаниям по модели Reddit, который заработал более $200 миллионов на продаже пользовательского контента в 2024 году. Убытки компании сократились с $84 миллионов в 2023 финансовом году до $22 миллионов благодаря массовым увольнениям и оптимизации расходов .

Сложные вопросы никуда не делись

CEO Stack Overflow Прашант Чандрасекар объясняет падение активности так: в начале 2023 года исчезли простые вопросы, на которые LLM легко отвечают . Сложные же кейсы по-прежнему задают на Stack Overflow, потому что альтернатив нет.

Если LLM настолько хороши, насколько хороши данные, на которых их обучают, а эти данные обычно курируются людьми, то мы — одно из лучших мест для этого, если не лучшее для технологий.

Замкнутый круг технологий

Stack Overflow стала индикатором новой, циркулярной экономики в технологической индустрии. Языковые модели нуждаются в данных о проблемах программирования и их решениях. У Stack Overflow есть огромный цифровой склад такой информации, но он стареет, поскольку запросы переместились в приватные чаты с LLM. А этим моделям для работы нужны массивы данных — которые больше не пополняются в прежнем объёме.

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

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

Свежая статистика показывает драматичный спад. Однако важная деталь: рост числа вопросов остановился ещё в 2014 году — задолго до появления ChatGPT и массового внедрения больших языковых моделей . Платформа стагнировала десять лет, а ИИ-инструменты лишь ускорили процесс упадка.

Три причины коллапса

LLM как зеркало Stack Overflow

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

Культура модерации

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

Поисковики держат трафик у себя

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

Парадокс обучающих данных

При текущей скорости падения активности (вдвое каждые 2,2 месяца) к 2028 году на Stack Overflow будут задавать примерно один вопрос в день . Это создаёт парадокс: языковые модели, обученные на данных платформы, убивают источник своих же знаний. Откуда будущие версии ИИ получат актуальную информацию о новых технологиях и фреймворках — открытый вопрос.

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

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

Последнее октябрьское обновление системы — KB5066835 — нарушило работу localhost, что фактически лишило разработчиков возможности тестировать веб-приложения локально.

Проблему активно обсуждают на Microsoft Support Forums, Stack Overflow и Server Fault: серверы перестали отвечать на запросы, отвалилась отладка в Visual Studio, а ASP.NET-приложения не компилируются.

По оценкам экспертов, сбой затронул миллионы веб-разработчиков и инженеров, использующих Windows 11 в качестве локальных серверов и рабочих станций.

Что пошло не так

Пакет KB5066835 был задуман как обновление безопасности, улучшавшее сентябрьский релиз KB5065789, но именно он привел к поломке HTTP.sys — системного компонента ядра Windows, отвечающего за маршрутизацию локального HTTP-трафика.

После установки апдейта, localhost перестал отвечать на запросы, а соединения по HTTP/2 начали обрываться.

Как временно исправить

Microsoft пока официально не подтвердила проблему, но сообщество уже нашло обходное решение:

1. Удалить октябрьское обновление KB5066835.
2. Если не помогло — удалить и предыдущее KB5065789.
3. После этого localhost начинает работать штатно. Однако это временная мера и пользователи рискуют остаться без последних исправлений безопасности.

Неудачи Microsoft продолжаются

Это уже второй крупный сбой за неделю. В понедельник компания случайно «сломала» Media Creation Tool — утилиту для установки Windows — всего за день до окончания поддержки Windows 10.

А на прошлой неделе Microsoft окончательно обязала пользователей входить в Windows 11 только через онлайн-аккаунт, что вызвало волну критики.

Немного цифр

Внедрение инструментов ИИ продолжает расти: 80% разработчиков уже используют их в рабочих процессах.

Однако это не привело к росту доверия. Более того, доверие к точности ИИ упало с 40% в предыдущие годы до 29% в этом году. Также снизилось положительное отношение к ИИ с 72% до 60% в годовом исчислении.

• За последний год 69% разработчиков потратили время на изучение новых методов кодирования или нового языка программирования; 44% изучили это с помощью инструментов на базе ИИ в сравнении с 37% в 2024 году.
• За последний год 36% разработчиков научились писать код специально для ИИ.

Популярность инструментов вроде GitHub Copilot или Cursor растёт стремительно: они помогают писать код, подсказывают решения и экономят время. Однако вместе с этим увеличивается число случаев, когда ИИ генерирует код, выглядящий корректно, но содержащий скрытые логические ошибки. По данным опроса, 45% разработчиков сталкивались с такими «почти правильными» фрагментами, на исправление которых уходит много часов. 66% разработчиков отмечают, что тратят больше времени на исправление «почти верного» кода, сгенерированного ИИ. Чем сложнее код, тем чаще разработчики обращаются за помощью к людям, а не к моделям.

Треть респондентов призналась, что обращалась на Stack Overflow из-за проблем, вызванных кодом, предложенным ИИ. Особенно уязвимы начинающие разработчики, которые склонны бездумно доверять подсказкам. 72% опрошенных отвергают практику «вайб кодинга» — вставки автогенерированного кода без тщательной проверки перед продакшеном.

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

По словам Джоди Бейли, директора по продуктам и технологиям Stack Overflow, сервис переосмысляет свою роль на фоне изменений в поиске знаний разработчиками. Несмотря на падение трафика, она отметила, что ситуация не столь драматична, как может показаться, и призвала к адаптации подходов к оценке успеха в цифровую эпоху.

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

P.s. Это перевод зарубежной статьи. Предлагаем подискутировать о вопросе в комментариях.

Как выгорание подкрадывается к разработчикам

Через несколько месяцев после того, как вы почувствуете усталость, console.log() начнет казаться непосильной задачей, а баг, который обычно исправлялся за час, ломает изнутри.

Так выгорание медленно вытесняет любопытство апатией. Разработчик уже не испытывает злости, он просто устает. Становится проще уйти, чем продолжать.

И статистика это подтверждает: по данным Stack Overflow, 32% разработчиков несчастны на работе, а еще 47% выживают на автомате, не чувствуя вовлеченности. Это значит, что почти 80% специалистов находятся в зоне риска эмоционального выгорания, хотя снаружи всё выглядит стабильно.

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

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

Пятиминутная привычка, которая меняет всё

Чтобы преодолеть выгорание, не нужно переворачивать жизнь с ног на голову. Достаточно одной маленькой привычки — пяти минут в день, посвященных программированию без давления и ожиданий. Это может быть что угодно: написание нескольких строк кода, разбор простого алгоритма или чтение документации. Главное — последовательность.

Формула успеха звучит так: Минимальные усилия → Последовательность → Идентичность → Восстановление связи. Начав с малого, можно постепенно вернуть уверенность и интерес к профессии.

Как работает эта практика:

1. Выберите простое действие: например, написать одну функцию или изучить один метод в документации.
2. Установите таймер на 5 минут: это снижает порог входа и делает задачу необременительной.
3. Делайте это каждый день: даже если результат минимален, регулярность формирует привычку.
4. Не ждите вдохновения: действие само по себе создает мотивацию.

Микро-привычки эффективны, потому что опираются на принцип «атомарных изменений», описанный Джеймсом Клиром в книге «Атомные привычки». Маленькие действия требуют минимальной энергии, но со временем накапливаются, формируя новую идентичность. Для разработчика это означает переход от «я устал от кода» к «я человек, который каждый день делает шаг в программировании».

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

Как вернуться к программированию и не выгореть снова

Если хочется вернуться к программированию без риска снова выгореть, помогут простые принципы:

Опустите планку — и опустите её ещё раз. Если на старт уходит больше минуты, задача слишком сложная.

Не отслеживайте результат. Никаких счётчиков строк, коммитов и диаграмм продуктивности. Задача — восстановить доверие к себе, а не нарастить темп.

Избавьтесь от чувства вины. Пропустили день? Не страшно. Один пропуск не должен превращаться в цикл стыда. Выход из выгорания — не марафон продуктивности.

Не ставьте цели слишком рано. Позвольте любопытству проявиться. Работайте над чем-то странным или бесполезным. Там чаще всего и прячется вся соль.

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

Инструменты и ресурсы для тех, кто выгорел и не знает, что с этим делать

• Книги: «Атомные привычки» Джеймса Клира для понимания силы маленьких шагов.
• Курсы: платформы вроде Codecademy или freeCodeCamp для легкого возвращения к основам.
• Сообщества: нишевые Discord-серверы (например, по Python или Rust) или Reddit (r/learnprogramming).
• Трекеры привычек: приложения вроде Habitica для отслеживания прогресса.

Вместо итогов

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

Многие разработчики знают, каково это — смотреть на редактор и не чувствовать ничего. И знают, сколько смелости требует простой шаг: попробовать снова.

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

Иногда именно пять минут дают больше, чем любой лайфхак продуктивности.

Бонус от экспертов: как пережить выгорание и вернуться к работе

Если вы узнаёте себя в описании из статьи — не переживайте, вы не одиноки. Мы попросили двух экспертов из индустрии поделиться личным опытом: как они справлялись с выгоранием, что для них сработало и какие вопросы помогают себе задать в непростые периоды.

Елизавета Якушева, тестировщик, автор тг-канала Press F to Debug:

Для меня выгорание — самая большая и страшная проблема в карьере. Абсолютно всё зависит от неправильно выстроенных ожиданий

Елизавета выделяет два разных типа выгорания:

1. От самой работы — стресс, рутина, груз ответственности.
2. От постоянной учёбы и самосовершенствования — давление трендов, ощущение собственной «недостаточности», переизбыток бесполезной информации.

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

Чтобы справиться, она предлагает задать себе простой, но важный вопрос:

«Зачем я это делаю? Что будет, если я перестану?»

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

Стресс от груза ответственности решается простой мыслью: "Я здесь, чтобы выполнять работу так, как могу. Если я не успеваю что-то сделать вовремя, я умираю, у меня температура под 40, у меня отвалилась нога — вселенная не остановится, если ты возьмёшь тайм-аут в виде отпуска или day-off. Ракета не полетит в космос, и никто глобально не умрёт."

Для пет-проектов помогает осознанность: понимание, зачем ты вообще этим занимаешься.

Я веду образовательный ютуб-канал, чтобы люди могли узнать что-то новое и разобраться в сложной теме. Мне важно, чтобы человек нашёл своё комьюнити и мог прийти куда-то за советом. Мысль о глобальной помощи другим вдохновляет меня даже в самые тёмные моменты

Анастасия Егорова, фронтенд-разработчик, автор канала «Код и кофе»:

Анастасия комментирует технику «5-минутных привычек», описанную в оригинальной статье, и делится, как адаптировала её под свой сложный ритм:

У меня был период жизни, когда я полтора года работала на двух фуллтайм-работах… Иногда, просыпаясь зимним утром в 6:45, чтобы выйти на удалённый созвон в 7:00, я думала, что больше всего хочу уволиться со второй работы. Но нужно было работать.

В такие моменты она договаривалась с собой: поработать всего 5 минут, а потом дать себе что-то приятное — сериал, эклер, отдых.

Где-то на второй–третьей пятиминутке меня затягивало, и 5 минут превращались в полноценный час-два работы без переключения. Несколько таких подходов в течение дня — и к вечеру работа была сделана, а иногда ещё и сварен борщ, и приготовлены котлетки.

Да, бывают и провальные дни — но даже тогда, по её словам, важно просто не бросить всё совсем.

Я реально работала 5 минут, а потом 10 минут отдыхала… и к концу дня с помощью этих пятиминуток было сделано не так много. В такие дни я просто от себя отставала, радовалась, что я сделала хотя бы эти пятиминутные задачи, а не прокрастинировала весь день.

Возможно, этот подход поможет и вам — особенно в моменты, когда ощущение выгорания слишком близко.

Особенно активно ИИ внедряется в повседневную практику профессиональных разработчиков: 51% признались, что используют такие инструменты каждый день.

Однако вместе с ростом использования стремительно падает уровень доверия. Только треть опрошенных действительно верит в точность ИИ-решений, а 46% заявляют, что не доверяют результатам генерации — по сравнению с 31% год назад.

«Почти правильный» код — головная боль, а не помощь

ИИ действительно может ускорять работу — но только если результат точный. 66% разработчиков жалуются, что нейросети предлагают «почти правильный» код, из-за чего они тратят больше времени на отладку, чем если бы писали все сами.

Почти половина (45%) говорят, что отлаживать ИИ-код сложнее, чем просто начать с нуля.

ChatGPT лидирует, но агентов пока боятся

Наиболее популярным ИИ-инструментом остается ChatGPT от OpenAI — его используют 82% разработчиков. На втором месте — Claude Sonnet от Anthropic, который особенно популярен среди профессионалов.

Но вот ИИ-агенты, которые умеют выполнять цепочки задач, пока не прижились: 52% респондентов не используют их и не планируют.

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

Вайб-кодинг? Пока нет

Попытки использовать ИИ для генерации целых приложений (вайб-кодинг) пока остаются экспериментом. 77% разработчиков говорят, что такие практики не используются в продакшене.

Главным источником решений остаются люди: 84% все еще обращаются к Stack Overflow, 67% — к GitHub, а 35% идут на Stack Overflow именно после того, как не смогли разобраться с ИИ-кодом.

Настроение и зарплаты: немного лучше, но не у всех

После падения морального состояния в 2024 году, в этом году 24% разработчиков заявили, что довольны своей работой — против 20% годом ранее.

Основная причина — рост зарплат. Особенно это чувствуют топ-менеджеры и техдиректора (средняя зарплата $130 000 и выше). А вот архитекторы и продакт-менеджеры получают заметно меньше — от $92 000 до $104 000.

Удаленка жива, но доступна не всем

Удаленная работа сохраняет позиции, но зависит от страны и компании.

В США полностью удаленно работают 45% разработчиков. В Германии — всего 21%. Вопрос гибкости остается важным фактором в оценке качества работы.

P.s. Это перевод зарубежной статьи от издания Run.it.Bare — медиа, в котором публикуются практические советы по DevOps, разработке программного обеспечения и искусственному интеллекту. Предлагаем подискутировать о вопросе в комментариях.

Почему программисты перестают помнить, как работает цикл

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

Использование инструментов вроде Copilot, Cursor и CodeWhisperer превращает процесс написания кода в автоматическое подтверждение предложенных вариантов. Разработчик видит сработавший автокомплит и просто принимает его, не задумываясь, как и почему работает решение.

Это не единичный случай. В профессиональных чатах и на Reddit регулярно появляются признания: после перехода на ИИ-инструменты многим стало сложнее писать код самостоятельно и разбираться в логике решений.

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

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

Как ИИ убивает мышечную память разработчика

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

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

ИИ-инструменты убирают повторение, подставляя готовые решения. Это кажется удобным, но невозможно «прокачаться» в программировании, наблюдая, как код пишут за тебя.

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

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

Когда вся сложность передана ИИ, удивляться отсутствию навыка уже не приходится.

Скорость — это не всегда про развитие

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

Молодые разработчики сегодня могут почти за секунду собрать и задеплоить фичу. Но если спросить, почему этот код работает, как он устроен внутри и в чём могут быть уязвимости, ответы обычно расплывчатые. «Это Copilot подсказал, я проверил и отправил». Быстро — да. Но за этой скоростью нередко нет опоры.

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

ИИ не думает о долгосрочной архитектуре. Он даёт шаблонное решение, которое подходит большинству. Но то, что подходит большинству, не всегда подходит вашему проекту.

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

Отладка: момент, когда ИИ отходит в сторону

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

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

Представьте ситуацию: приложение падает на граничном кейсе, логи непонятны, ИИ не даёт внятных ответов. В какой-то момент вы столкиваетесь с багом, который не описан в Stack Overflow, и подсказки ИИ кажутся бесполезными. Потому что ИИ не видит ваш проект целиком: он не знает, как менялось состояние за последние 30 вызовов, не замечает редкие гонки в асинхронных вызовах и не понимает контекст ваших архитектурных решений.

Иногда ИИ дает несуществующие методы, иногда уверенно предлагает ошибочную логику, иногда подтаскивает старые решения с багами из интернета. Всё это выглядит правдоподобно, пока не начинаешь разбираться, почему ночью падает прод.

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

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

Stack Overflow уходит, а вместе с ним — уходит и понимание

Раньше, когда в коде всплывал странный баг или нужно было разобраться с особенностями языка, разработчики шли за ответами на Stack Overflow. Да, там могли ответить резко, указать на ошибку в скобках или заставить читать документацию, но именно это формировало привычку задавать правильные вопросы и искать причины, а не просто готовые решения.

Вместо одного-единственного правильного ответа вы видели несколько подходов, спорили, тестировали, сравнивали. Этот процесс обучал, даже если разработчик не всегда это осознавал.

Сегодня многие начинающие прогеры даже не открывают Stack Overflow. Вместо обсуждений и разборов они получают готовый фрагмент кода из ChatGPT или Copilot и сразу вставляют его в проект. ИИ не спрашивает, правильно ли вы формулируете запрос. Он выдаёт ответ, даже ошибочный, но похожий на правду.

Stack Overflow, при всех его минусах, формировал культуру: чтобы получить хороший ответ, нужно было изучить проблему, корректно задать вопрос, столкнуться с критикой и разобраться, что именно вы сделали не так. Эти обсуждения между опытными разработчиками позволяли видеть логику и контекст за каждым решением.

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

И эта потеря обходится нам гораздо дороже, чем кажется.

Скорость даёт результат, понимание даёт рост

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

Но со временем картина меняется.

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

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

Использовать ИИ можно и нужно, но если не проходить «медленные» и «нудные» этапы понимания кода, роста не будет. Будет лишь иллюзия скорости, которая не превращается в настоящий скилл.

Найди своё сообщество: рост происходит в общении

Можно сидеть в одиночку с ChatGPT и VS Code, запускать фичи и чувствовать себя продуктивным. Но настоящий рост происходит не в вакууме.

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

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

Где это искать:

• Участие в нишевых Discord-серверах по языкам и стеку, которые тебе интересны (Rust, Elixir, Zig и другие).
• Чтение обсуждений в Reddit, где разбирают особенности дизайна языков и библиотек.
• Обсуждение pull request в open-source, где реальные инженеры спорят о производительности, надёжности и архитектуре.
• Вопросы — и не единичные, а пока не разберёшься, как и почему это работает.

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

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

Code review — это про совместное мышление

Большинство код-ревью в командах сейчас выглядят так:

— «Переименуй переменную»;

— «Пропустил точку с запятой»;

— «Окей, мержим».

Так можно быстро влить изменения в main, но упускается главное: код-ревью может быть мощным инструментом роста и обмена опытом в команде.

Каждое ревью — это возможность взглянуть на решение задачи глазами другого разработчика. Не стоит закрывать эту возможность односложным «норм».

Что можно добавить в код-ревью, чтобы оно стало инструментом роста:

• Почему выбрано именно это решение?
• Какие альтернативы рассматривались?
• Что сломается, если завтра поменяется X?
• Можно ли решить задачу проще?

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

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

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

Если ты сам отправляешь код на ревью, не бойся просить о таком фидбэке:

— «Как думаешь, здесь перебор с абстракциями?»

— «Есть ли идеи, как упростить эту логику?»

Код-ревью — это про развитие навыка думать над кодом, видеть архитектуру и обоснованно выбирать решения.

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

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

Создание чего-то с нуля для разработчика — это как тренировка ног в спортзале: никто не хочет, но без этого не обойтись. Речь не о запуске npx create-next-app или копировании кода из ChatGPT. Мы говорим о настоящем процессе: когда вы, например, только что разобрались, что такое сокет, и пытаетесь построить что-то с этим знанием.

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

Выберите что-то фундаментальное. Например:

• Реализуйте WebSocket с нуля, начиная с TCP.
• Напишите маршрутизатор на чистом JavaScript.
• Разберите файл .env вручную.
• Создайте рендерер, похожий на React, используя только DOM API.

Будет ли это медленно? Однозначно. Будет ли код неидеальным? Скорее всего. Но знания, которые вы получите, окупятся, как проценты на сберегательном счете: на собеседованиях, при отладке или в спорах об архитектуре.

«Я переписал систему интеграции с Twitch за два 7-часовых перелета без интернета. И это было круто», — делятся разработчики.

Создание с нуля дает уверенность, которую не заменит автодополнение кода от Copilot. А современные инструменты помогут пережить этот процесс:

• Autobahn WebSocket Test Suite — для тестирования вашей реализации WebSocket.
• Курс HTTP from TCP на Boot.dev — чтобы разобраться, как работает интернет на уровне битов.
• Zig’s Discord — сообщество, где обсуждение низкоуровневого кода с единомышленниками прокачивает навыки.

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

Ваш самый неудачный код станет лучшим учителем. Так что создайте что-то, что не работает, и почините это самым сложным путем.

ИИ — не враг, а соблазнительная опора: как использовать его с умом

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

ИИ позволяет избегать сложностей, но именно в преодолении трудностей рождается понимание. Как сказал один разработчик: «Мы не обречены из-за использования ИИ. Мы обречены, если полагаемся только на ИИ».

Вопрос не в том, использовать ли Copilot или ChatGPT — это отличные инструменты. Вопрос в том, как вы их используете.

• Берете первое предложенное решение и идете дальше? Или останавливаетесь и спрашиваете: «Почему так? Есть ли вариант лучше?»
• Позволяете ИИ писать функции и слепо отправляете их в продакшен? Или переписываете код вручную, чтобы разобраться, как он работает?

Один разработчик использует ИИ как реактивный ранец, ускоряющий работу. Другой — как костыль, заменяющий собственные усилия. Угадайте, кто справится с поддержкой устаревшего кода?

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

Разработчик, который умеет отличать правильное решение от сомнительного, всегда будет на шаг впереди.

Вы — не ретранслятор ИИ: как оставаться настоящим разработчиком

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

Работа разработчика — не в скорости набора текста, а в умении думать. Моделировать проблемы, разрабатывать решения, понимать компромиссы, устранять хаос, задавать правильные вопросы, объяснять и создавать. ИИ не справится с этим без вас.

Если вы ограничиваетесь поверхностными решениями, вас легко заменит стажер или новая модель, которая генерирует код на 20% лучше. Но если вы глубоко понимаете системы, шаблоны, архитектуру и компромиссы, вы становитесь тем, к кому обращаются, когда ИИ не справляется.

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

Создавайте, ломайте, спрашивайте «почему», даже если это раздражает коллег. Используйте ИИ, но не позволяйте ему использовать вас. Ваша задача — не передавать ответы, а создавать понимание. И это то, что ни одна модель не сможет подделать.

Настоящий Dev Flex: глубокое понимание в эпоху ИИ

В 2025 году ИИ с легкостью решает задачи LeetCode, создает лендинги, рефакторит спагетти-код и генерирует каркасы приложений по одному запросу. Что остается разработчику? Многое.

Настоящий профессионализм сегодня — это умение:

• Проектировать системы с нуля, опираясь на фундаментальные принципы.
• Отлаживать сбои, с которыми ИИ не справляется.
• Четко объяснять ошибки, их исправления и компромиссы.
• Заметить, что код «выглядит правильно», но на деле ошибочен, и доказать это.

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

Разработчики, чрезмерно полагающиеся на ИИ, рано или поздно упираются в потолок. Они принимают поверхностные решения, предложенные алгоритмами. А вы? Вы инвестируете в долгосрочные навыки.

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

Как оставаться на шаг впереди

1. Используйте ИИ как инструмент обучения. Не берите первый предложенный ответ. Разберитесь в компромиссах. Попросите решить задачу тремя разными способами. Относитесь к ИИ как к младшему разработчику, которому нельзя доверять на 100%.
2. Участвуйте в сообществах, которые заставляют думать. Не просто читайте Discord или форумы. Задавайте вопросы, изучайте код других, получайте критику. Нишевые сообщества полны разработчиков, которые бросят вызов вашим идеям — и это лучший способ расти.
3. Создавайте проекты без ИИ. Выделите выходные и попробуйте написать проект без подсказок ИИ. Ищите решения в Google, отлаживайте вручную, как в 2014 году. Да, это медленно, но именно так вы учитесь держать баланс без «дополнительных колес».
4. Рецензируйте код с вопросом «Почему?». Даже если код работает, копайте глубже. Какие альтернативы рассматривались? Что может пойти не так? Это тренирует ваше распознавание паттернов и учит понимать чужой ход мысли.
5. Пересоздайте что-то с нуля. Возьмите знакомую систему — маршрутизацию, аутентификацию или управление состоянием — и напишите свою мини-версию. Это сложно, но невероятно полезно.

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

Не становитесь игрушкой в руках ИИ: как сохранить мастерство разработчика

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

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

Чем больше вы полагаетесь на ИИ, тем выше риск стать «инженером-подсказчиком» — человеком, который лишь перекладывает автозаполненный код. Это не то, ради чего вы выбрали разработку.

Используйте ИИ. Доводите его до предела. Но не забывайте:

• Задавать вопросы, даже если ответ кажется очевидным.
• Периодически создавать простые вещи с нуля.
• Разбираться в сломанном коде, пока не поймете, почему он не работает.

Когда вы знаете больше, чем автозаполнение, вы обретаете то, что ИИ не может повторить: суждение, проницательность, мастерство.

В будущем, когда все станут быстрее, победа будет за разработчиком, который копает глубже.

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

2005-2009: Эпоха авторских решений и первых веб-фреймворков

В середине 2000-х типичный рабочий инструмент программиста — это громоздкий системный блок с процессором Intel Pentium 4 или новеньким Core 2 Duo. Мониторы с ЭЛТ-трубкой постепенно уступали место LCD-экранам с разрешением 1024×768 — именно на таких дисплеях создавались первые версии Wikipedia и набирающих популярность соцсетей. Оперативная память в 1-2 ГБ считалась нормой, а жесткие диски на 80-160 ГБ часто заполнялись до отказа — проекты редко весили меньше нескольких гигабайт.

Серьезная разработка велась преимущественно на стационарных компьютерах. Ноутбуки только начинали входить в обиход — их брали в офис, но для реальной работы предпочитали мощные десктопы. Операционная система Windows XP доминировала на рабочих станциях, в то время как серверы чаще всего крутили на Linux — Red Hat Enterprise или Debian.

Среды разработки того времени сегодня кажутся архаичными. Eclipse и NetBeans потребляли гигабайты памяти, Visual Studio 2005 требовала серьезных ресурсов. Многие разработчики предпочитали простые текстовые редакторы вроде Notepad++, а для отладки использовали примитивные методы вроде вывода значений переменных через print. Контроль версий только начинал входить в практику — Git появился в 2005 году, но большинство команд продолжали использовать SVN или вообще заливали файлы по FTP напрямую на продакшен.

Языковая экосистема этого периода вращалась вокруг трех основных технологий. PHP версий 4 и 4.3 доминировал в веб-разработке — на нем работало около 80% всех сайтов в интернете. Однако его объектно-ориентированные возможности были крайне ограничены до выхода PHP 5 в 2004 году.

Java в лице J2EE оставалась стандартом для корпоративных решений — банковских систем, крупных порталов и ERP-комплексов. Spring Framework только начинал набирать популярность, а Hibernate упрощал работу с реляционными базами данных. C++ сохранял свои позиции в разработке игр (особенно с использованием Unreal Engine), драйверов и высоконагруженных сервисов.

Фронтенд-разработка в те годы была невероятно простой по современным меркам. Верстали преимущественно таблицами, а всю динамику реализовывали через jQuery, который появился в 2006 году и быстро вытеснил нативный JavaScript из повседневной практики. AJAX-запросы казались революционной технологией, позволяющей обновлять части страницы без ее полной перезагрузки.

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

• «Философия Java» Брюса Эккеля;
• «Совершенный код» Стива Макконнелла;
• «PHP и MySQL. Разработка веб-приложений» Люка Веллинга.

Русскоязычное сообщество активно обсуждало вопросы разработки на форумах RSDN.ru и CyberForum.ru. В 2008 году появился Stack Overflow, который постепенно стал главной площадкой для профессиональных обсуждений.

Университетское образование давало хорошую теоретическую базу — алгоритмы, структуры данных, принципы ООП. Однако практическим навыкам приходилось учиться самостоятельно, методом проб и ошибок. Документацию часто скачивали в формате CHM-файлов или читали непосредственно на сайтах вроде php.net и MSDN.

Типичный стек начинающего разработчика в 2009 году:

• HTML/CSS с jQuery для фронтенда;
• PHP или Ruby on Rails для бэкенда;
• MySQL в качестве базы данных.

ORM-технологии еще не получили широкого распространения, поэтому SQL-запросы писали вручную. Многие проекты представляли собой монолитные приложения, где весь код хранился в единой кодовой базе без четкого разделения на модули.

Показательный кейс:

В 2007 году разработчик PHP-приложений из МЭСИ (Москва) столкнулся с типичной для того времени проблемой — SQL-инъекциями. Вместо стандартных решений он создал DLAC (Data Logic Access Component) — обертку для работы с базой данных, которая автоматически экранировала параметры запросов. Это выглядело революционно на фоне типичного кода того периода, где строки запросов часто собирали через конкатенацию с пользовательским вводом.

Компонент использовал новую для 2005 года технологию Generics в C#. Он генерировал параметризованные запросы, что резко снижало риски взлома.

Разработчики в университетской среде тогда редко задумывались о безопасности — многие проекты содержали уязвимости вроде SELECT * FROM users WHERE name = ‘.$_POST[‘name’].

DLAC стал локальным спасением для внутренних систем МЭСИ, пока в 2009 году не появился NHibernate — порт популярного Java-фреймворка Hibernate.

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

2010-2014: Мобильная революция и рассвет JavaScript

Начало нового десятилетия ознаменовалось стремительным ростом мобильных технологий. Выход iPhone 4 в 2010 году и Android 2.3 Gingerbread задал новые стандарты мобильной разработки.

Программисты массово переходили на MacBook Pro — не столько из-за преимуществ macOS, сколько благодаря появлению Retina-дисплеев в 2012 году, которые кардинально улучшили качество отображения кода.

Железо продолжало стремительно эволюционировать. Твердотельные накопители (SSD) начали вытеснять традиционные жесткие диски в рабочих станциях. Облачные платформы вроде AWS и Heroku стали реальной альтернативой локальным серверам, которые раньше часто стояли прямо под рабочими столами в офисах. Оперативная память в 8 ГБ стала стандартом для комфортной разработки, а четырехъядерные процессоры ускорили сборку крупных проектов.

Языковая палитра этого периода значительно расширилась. Objective-C стал основным языком для iOS-разработки и оставался таковым до появления Swift в 2014 году. Python 3 начал набирать популярность благодаря веб-фреймворку Django и научным библиотекам NumPy и Pandas, которые открыли дорогу для анализа данных в массовом сегменте.

JavaScript пережил настоящий ренессанс — после выхода AngularJS в 2010 и Node.js в 2009 году он перестал быть просто «языком для анимаций на сайте», превратившись в полноценную платформу для fullstack-разработки.

Важный факт. В 2011 году разработчик из Сан-Франциско Райан Даль представил Node.js — среду выполнения JavaScript на стороне сервера. За первые 24 часа после релиза проект собрал 10 000 звезд на GitHub, что для того времени стало рекордом. Многие скептически относились к идее использовать JavaScript вне браузера, но уже через год такие компании как LinkedIn и Walmart перевели части своего бэкенда на Node.js, получив прирост производительности в 2-3 раза по сравнению с традиционными решениями на Java и Ruby.

Образовательная сфера претерпела значительные изменения. В 2011 году запустилась Coursera с первым массовым курсом по программированию — Machine Learning от Эндрю Ына. В 2012 году в Кремниевой долине открылся Hack Reactor, ставший прототипом современных coding bootcamps (интенсивов по программированию). Эти форматы предложили альтернативу традиционному университетскому образованию, сделав акцент на практических навыках.

Параллельно в России:

• В 2012 году появился Hexlet — одна из первых русскоязычных платформ с практико-ориентированными курсами по программированию. Особенность: выполнение заданий в реальной среде разработки через браузер. Платформа до сих пор работает: на текущий момент 80% выпускников трудоустраиваются в IT, согласно исследованию ВШЭ. В 2012 этот показатель был еще выше.
• «Нетология» (основана в 2011) к 2013 году запустила курсы по веб-разработке с акцентом на JavaScript и Python, сотрудничая с российскими tech-компаниями. Их модель включала менторство и проектные работы.
• В 2013 году стартовал Stepik — платформа с открытыми курсами от ведущих вузов (ИТМО, МФТИ). Особенность: интерактивные задачи с автоматической проверкой кода, что было прорывом для местного рынка.

Курс «Введение в Linux» от Stepik (2014) за полгода собрал 50 тыс. студентов — рекорд для Рунета. Задания включали настройку виртуальных серверов, что сразу применялось в работе.

Эти проекты заложили основу для бума EdTech в России после 2015 года, доказав, что онлайн-формат может давать актуальные навыки быстрее вузов.

Типичный разработчик среднего уровня в 2014 году:

• понимал принципы REST API;
• начинал осваивать основы DevOps с появлением Docker в 2013;
• экспериментировал с микроконтроллерами вроде Arduino или Raspberry Pi, создавая собственные IoT-устройства.

В профессиональной среде начал формироваться консенсус о том, что PHP устаревает для сложных коммерческих проектов.

2015-2019: Эра больших данных и облачных технологий

Аппаратные возможности сделали очередной рывок вперед. Многоядерные процессоры Intel i7 и AMD Ryzen стали стандартом для рабочих станций. 16 ГБ оперативной памяти перестали быть роскошью, а мониторы с разрешением 4К стали доступны широкому кругу разработчиков. В 2015 году появился Visual Studio Code, который быстро обогнал по популярности Sublime Text и Atom благодаря удачному сочетанию функциональности и производительности.

Языковая экосистема продолжила развитие. TypeScript, представленный в 2014 году, предложил решение проблемы масштабируемости JavaScript-кода в крупных проектах. Go от Google, созданный еще в 2009, нашел свою нишу в разработке микросервисов и инструментов оркестрации вроде Kubernetes (2015). Rust от Mozilla начал завоевывать доверие системных программистов благодаря уникальной системе владения памятью.

JavaScript-сообщество столкнулось с первыми серьезными проблемами. В 2016 году инцидент с пакетом left-pad показал уязвимость экосистемы npm — удаление одного небольшого модуля привело к сбоям в работе тысяч проектов по всему миру. Это заставило разработчиков задуматься о зависимости от сторонних библиотек.

Типичный senior-разработчик в 2019:

• разбирался в микросервисной архитектуре и понимал, как избежать vendor lock-in (привязки к поставщику) при работе с облачными провайдерами;
• имел опыт работы с React или Vue.js;
• знал, что понимание принципов работы алгоритмов становится менее важным, чем развитие soft skills для работы в команде.

Ключевые технологии этого периода включали Kubernetes, который стал стандартом де-факто для оркестрации контейнеров, а также TensorFlow (2015) и PyTorch (2016), открывшие эру машинного обучения для широкого круга разработчиков. Появились первые серьезные инструменты для работы с большими данными — Apache Spark, Hadoop.

Ключевой момент. В 2016 году Netflix раскрыл детали своего перехода на облачную инфраструктуру AWS. Компания полностью перенесла все сервисы — от рекомендательной системы до биллинга — в облако за семь лет. Главным триггером стала катастрофа 2008 года, когда три дня простоя дата-центра оставили 8,4 млн подписчиков без доступа к сервису. Миграция потребовала перепроектирования архитектуры: инженеры разбили монолит на 500 микросервисов и внедрили Chaos Monkey — инструмент для тестирования отказоустойчивости, который случайно отключал серверы в продакшене.

Этот кейс стал хрестоматийным примером cloud-native подхода. Облачные технологии стали активно использоваться в разработке, а обращение с ними — обязательным навыком для прогеров.

2020-2024: AI-assisted разработка и новые парадигмы

Пандемия COVID-19 ускорила переход на удаленную работу. Программисты по достоинству оценили макбуки на чипах M1 (2020) за их энергоэффективность и производительность. Домашние офисы оснащались 32-дюймовыми 4К-мониторами и механическими клавиатурами, ставшими своеобразным профессиональным стандартом.

Языковая палитра продолжала обогащаться. Rust официально вошел в ядро Linux в 2022 году, подтвердив свой статус системного языка нового поколения. Zig появился как современная альтернатива «C» с акцентом на безопасность. WebAssembly (Wasm) позволил запускать ресурсоемкие приложения прямо в браузере, открыв новые возможности для веб-разработки.

Искусственный интеллект начал проникать в повседневную работу программистов. GitHub Copilot на базе GPT-3, представленный в 2021, изменил сам процесс написания кода, предлагая контекстные подсказки. Low-code платформы вроде Retool упростили создание внутренних инструментов для бизнеса.

Типичный lead-разработчик в 2024 году:

• умел эффективно работать в гибридных командах (офис + удаленка);
• автоматизировал рутинные задачи через ChatGPT API;
• следил за развитием квантовых вычислений, хотя практическое применение пока оставалось ограниченным.

Ключевой момент. В 2023 году GitHub Copilot, разработанный совместно с OpenAI, стал катализатором перемен в индустрии. За первый год после релиза инструмент использовали более 1,3 млн разработчиков — каждый десятый подписчик GitHub. Система анализировала контекст кода и предлагала целые функции: например, при написании SQL-запроса она автоматически генерировала соответствующую модель данных на Python. Amazon внедрил аналогичный инструмент Amazon Q Developer для внутренних команд — по заявлению CEO Энди Джесси, это сэкономило компании 4,500 человеко-лет работы и $260 млн ежегодно.

Но были и курьезы. В 2024 году разработчик из Берлина случайно отправил в продакшен код, полностью сгенерированный Copilot. Система использовала фрагмент из GPL-лицензированной библиотеки, что нарушило политику компании по открытому ПО. Инцидент заставил пересмотреть процессы ревью: теперь 78% команд требуют ручной проверки AI-кода перед мержем (слиянием).

Параллельно выяснилось, что Copilot в 40% случаев предлагает уязвимый код при работе с СУБД — это привело к взлому API стартапа через SQL-инъекцию. Такие кейсы показали, что ИИ пока не заменяет программистов, а требует от них новых навыков — критического анализа машинных предложений и понимания юридических аспектов кода.

2025: Современное состояние профессии

Современные рабочие станции программистов оснащены ноутбуками с процессорами Apple M4 (3 нм) или Windows-машинами на Snapdragon X Elite. Мониторы с разрешением 8К используются для разработки AR-приложений, а OLED-экраны с HDR стали стандартом для работы с графикой. Появляются первые экспериментальные IDE с нейроинтерфейсами, способные предсказывать код на основе анализа мозговой активности.

Среди языков программирования выделяется Mojo (2023) — «Python для GPU», набирающий популярность в сфере машинного обучения. Carbon как потенциальный наследник C++ пока остается в тени Rust. Квантовые языки вроде Q# и Cirq интересуют в основном энтузиастов и исследователей.

Профессия претерпела значительные изменения. ИИ стал не конкурентом, а помощником — по некоторым оценкам, около 60% рутинного кода в 2025 году (тесты, документация) генерируется автоматически. Знание английского языка стало важнее знания сложных алгоритмов — без него невозможно эффективно работать с современными AI-инструментами. Понятие «fullstack-разработчик» трансформировалось — теперь оно подразумевает владение фронтендом, одним бэкенд-языком и основами машинного обучения.

За два десятилетия программисты прошли путь от одиночек за CRT-мониторами до участников глобальных распределенных команд. Если в 2005 ключевым навыком было умение написать работающий код, то в 2025 главное — способность эффективно взаимодействовать с ИИ-ассистентами. Однако основы профессии остались неизменными — логическое мышление, способность к абстракции и желание автоматизировать рутинные задачи.

Будущее обещает новые трансформации. К 2030 году нейроинтерфейсы смогут заменить традиционные устройства ввода, а квантовые компьютеры — перевернуть основы криптографии. Но пока актуальными остаются проверенные временем принципы: изучать перспективные технологии (вроде Rust и Mojo), осваивать работу с ИИ и, конечно, совершенствовать главный навык любого программиста — умение быстро и грамотно гуглить.

Ты уже программист, если читаешь это! Больше о кодинге тут.

Для сравнения: в сентябре 2009 года было 17 668 вопросов, а за первую половину мая этого года — всего 6667.

Это падение стало продолжением многолетнего тренда. Количество новых вопросов на платформе снижается с 2014 года, но особенно резкий обвал начался после появления ChatGPT в ноябре 2022 года.

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

Как Stack Overflow начал умирать

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

• 2014: усиление модерации и массовое закрытие «низкокачественных» вопросов оттолкнули многих пользователей;
• 2020: пандемия вызвала кратковременный всплеск интереса — разработчики чаще искали ответы онлайн;
• 2021: сайт продали за $1,8 млрд фонду Prosus — на пике, задолго до начала падения;
• 2022: релиз ChatGPT стал точкой невозврата. ИИ оказался не только быстрее, но и вежливее: он не закрывает вопросы и не указывает на «дубликаты», как это делали модераторы на Stack Overflow.

С того момента популярность сайта начала стремительно падать. По сути, ChatGPT стал альтернативой Stack Overflow, обученной, в том числе, на его же данных.

Что будет дальше

На фоне новых реалий, Stack Overflow пробует переосмыслить себя. Компания объявила о ребрендинге и диверсификации: теперь она хочет не только отвечать на вопросы, но и строить экосистему вокруг карьеры и сообщества.

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

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

Кто заменит Stack Overflow

Несмотря на упадок платформы, потребность в обмене знаниями никуда не делась. Просто теперь разработчики уходят в другие форматы: чаты в Discord, Telegram, Slack и другие площадки, где атмосфера менее формализованная и более дружелюбная.

Тем не менее, исчезновение Stack Overflow — это символ конца целой эпохи. В начале 2010-х платформа действительно помогла тысячам разработчиков «стартовать», а система репутации превращала помощь другим в азартную игру. Сегодня все чаще за ответом идут не к сообществу, а к нейросети.

Тогда Хоар задался вопросом: почему программисты до сих пор не создали язык, на котором нельзя случайно сломать даже лифт? Так родился Rust — язык с прицелом на безопасность и надежность. Имя он получил в честь жестких выживающих грибов: «переинженеренных, чтобы не умереть».

В чем сила Rust

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

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

В 2009 году Mozilla увидела в Rust перспективу и стала его спонсировать. В 2010 — проект впервые представили публике. А 15 мая 2015 года вышла стабильная версия Rust 1.0.

За 10 лет — из нишевого языка в глобальный инструмент

Сегодня Rust — это не просто язык, а инфраструктурный стандарт. Его используют в браузерах, ядрах ОС, облачных сервисах, криптографии, базах данных, системах телеметрии и кодеках.

Его официальный пакетный менеджер crates.io вырос с 2000 пакетов до более чем 180 000. Библиотека стандартных функций утроилась. А каждый релиз проверяется на 600 000 публичных проектах.

Rust развивается быстро, но без сбоев: релизы выходят каждые 6 недель, без разрушения обратной совместимости. Уже внесено 246 000 изменений от 6700 контрибьюторов.

Язык, который создает инфраструктуру

Rust не пытается быть всем сразу. Это не замена Python или JavaScript. Rust — язык «труб и фитингов»: он нужен для создания тех самых фундаментальных систем, на которых работает все остальное.

Именно поэтому он стал любимцем среди системных разработчиков. В опросе Stack Overflow язык восьмой год подряд занимает первое место по симпатии: более 80% пользователей хотят продолжать с ним работать.

От Firefox до ядра Linux

Сегодня Rust применяют Google, Microsoft и Amazon. Mozilla внедрила его в Firefox, Google — в Android и ChromeOS, Microsoft — в ядро Windows и облачные сервисы Azure.

Rust даже начал проникать в ядро Linux. Линус Торвальдс признал, что разработчикам непросто учиться новому языку, особенно с таким отличием от привычного C. Но сам он Rust в ядре активно поддерживает.

Учиться сложно, но оно того стоит

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

Среди лучших источников — The Rust Programming Language (в народе просто «The Book»), Rust for Rustaceans и бесплатные онлайн-курсы Rust by Example и Comprehensive Rust от Google.

Главное — не язык, а сообщество

По словам самого Хоара, Rust — это не только о коде. Это история о большом сообществе, которое объединилось ради создания надежной технической основы для будущего. Он называет Rust «языком для создания инфраструктуры» — и в этом его миссия.

В мире, где все зависит от качественного, безопасного и масштабируемого софта, Rust за первые 10 лет доказал: системное программирование может быть и мощным, и приятным.

Больше новостей — в нашем тг-канале «Представляешь»

Согласно данным из официального Data Explorer, количество постов на сайте в апреле 2025 года сократилось более чем на 64% по сравнению с тем же месяцем 2024 года и упало более чем на 90% по сравнению с пиком активности в 2020 году.

Основной причиной называют взрывной рост ИИ-инструментов вроде ChatGPT и других языковых моделей, которые стали альтернативой для быстрого поиска технической информации.

Многие разработчики теперь предпочитают использовать ИИ для решения задач, избегая классических Q&A-платформ.

Почему Stack Overflow планирует ребрендинг

На фоне падения трафика, компания Stack Exchange, владеющая Stack Overflow, объявила о планах по ребрендингу.

Руководители компании — SVP по сообществу Филип Бодетт и SVP по маркетингу Эрик Мартин — отмечают, что текущий бренд стал причиной «ежедневной путаницы, неэффективности и непоследовательности». По их словам, фокус на разработчиках иногда отталкивает более широкое сообщество пользователей.

Кроме того, CEO Stack Overflow Прашант Чандрасекар сообщил, что компания хочет расширить свою миссию с одного основного направления (Q&A) до трех, добавив «сообщества» и «карьерные возможности» в свою бизнес-модель.

Уже сейчас платформа тестирует новые инструменты, включая AI Answer Assistant, Question Assistant, расширенные интеграции с GitHub Copilot, Slack и Visual Studio Code, а также обновленный сайт для поиска работы, созданный в партнерстве с Indeed.

Что этот шаг значит для сообщества

Переход к новой бизнес-модели означает, что Stack Overflow может меньше полагаться на традиционные формы контента, такие как текстовые вопросы и ответы. Однако для многих разработчиков именно эти разделы были основой сообщества.

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

Что дальше

Несмотря на падение трафика, бизнес Stack Overflow остается относительно стабильным. Платформа, принадлежащая инвестиционной компании Prosus, все еще получает доход от корпоративных версий сайта (Stack Overflow for Teams), рекламы и сервисов для рекрутинга.

По данным финансового отчета Prosus, выручка компании выросла, а убытки сократились в первой половине 2024 года.

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

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

Основные типы генеративных моделей

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

Генеративные модели проходят машинное обучение. Они настроены реализуют почти любые запросы, сформулированные человеком. Картинки, текст, музыка, новый дизайн — все это продуцируется за считанные секунды. Главное, правильно сформулировать техническое задание. Если автор хочет изображение единорога, играющего на гитаре, он его получит. Если нужна мелодия в стиле «Metallica для медитации», сеть решит и эту задачу. Модель даже напишет код или целое приложение — здесь мы собрали крутые промпты с примерами.

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

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

Пример такого внедрения — AI Claude в Blender.

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

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

Однако не стоит думать, что такой ИИ мыслит, как человек. Ему доступно только машинное обучение и интерпретация данных. С технической точки зрения Generative AI — это особый класс вычислительных методов, ориентированных на производство новых данных, похожих на реальные образцы. Можно провести параллель с творческой работой человека, но в отличие от людей модели оперируют заданными алгоритмами и обучаются на огромных информационных массивах. Создать что-то из ничего эти инструменты не в состоянии.

Типы генеративных моделей различаются по своим технологическим начинкам. Рассмотрим наиболее востребованные варианты.

Генеративно-состязательные сети

Generative Adversarial Networks (GAN) относятся к наиболее востребованному и эффективному классу моделей ИИ. Их создатель Иэн Гудфеллоу изначально разрабатывал программу для создания реалистичных изображений и после многочисленных неудачных попыток понял, что эту задачу сможет решить только нейросеть. Затем ему в голову пришла еще одна гениальная мысль — нейросетей должно быть две. Одна генерирует картинки, вторая их оценивает — если результат неудовлетворительный, изображение уходит на доработку.

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

Интересный факт. Нейросеть Иэн Гудфеллоу создала полотно, названное «Портрет Эдмонда Белами». Это произведение было продано на аукционе Christie’s почти за полмиллиона долларов.

Принцип работы GAN можно сравнить с отношениями художника и строго критика. Художник (генератор) рисует картинку, критик (дискриминатор) говорит: «Это фейк!».

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

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

Сферы применения технологии:

• генерация реалистичных лиц;
• статичные изображения и анимация;
• дизайн одежды и интерьеров;
• создание дипфейков (этический аспект таких продуктов пока не затрагиваем, но помнить о нем стоит всегда).

GAN-ы могут сойти с ума и нарисовать, например, котика с пятью лапами, так что контроль со стороны человека обязателен.

Примеры GAN — нейросети, созданные на фреймворке TensorFlow, а также DCGAN — одна из первых нейросетей для создания изображений.

Вариационные автоэнкодеры

VAE (Variational Autoencoder) состоят из двух частей: энкодера, преобразующего входные данные в сжатое представление, и декодера, восстанавливающего данные из этого латентного пространства.

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

Технология используется:

• для генерации новых дизайнов;
• для анимации и 3D-моделирования;
• в медицине — для создания синтетических данных для исследований.

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

Трансформеры

Transformers — это так называемые авторегрессионные модели, составляющие основу текстовых генераторов (таких, как ChatGPT, GitHub Copilot). Они анализируют огромные объемы текста и учатся предсказывать следующее слово. Аналогично (пиксель за пикселем) создаются изображения.

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

Трансформеры умеют генерировать код. Например, GitHub Copilot может дописать за вас функцию, но иногда предлагает что-то вроде:

Диффузионные модели

Diffusion Models — это нейросети, созданные для генерации изображений и видео. Типичные примеры AI-моделей на основе такой технологии — DALL·E, Midjourney, Stable Diffusion, Flux.

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

Плюсы таких нейросетей — высокое качество изображений и гибкость. Можно генерировать что угодно: от фотореализма до аниме.

Пример реализации простого текстового промпта:

Нарисуй старика в шляпе на фоне реки Волги в стиле фотореализма.

В целом удовлетворительно, но со стилизованными башнями явный перебор.

Генерация изображений

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

Модели создают изображения на основе текстовых описаний («нарисуй мне зеленое яблоко на дереве»). Для понимания таких описаний нейросети переводят их в цифру с помощью модели NLP для обработки естественного языка. Например, DALL·E преобразует текстовое описание в высокоразмерные векторы, улавливающие не только смысл, но и контекст запроса. Координаты на полученных векторах представляют отдельное свойство входящего текста (яблоко, зеленое, дерево). Затем модель преобразует полученные коды в изображения.

Топ-3 нейросетей, которые создают изображения — это DALL·E, Midjourney и Stable Diffusion. У каждой из них есть свои достоинства:

• DALL·E — умеет рисовать по абсурдным запросам («авокадо в образе римского патриция» и т.д.).
• Midjourney — король арт-стилей. Можно сделать изображение под Ван Гога, а можно — в стиле киберпанк.
• Stable Diffusion — это открытая и гибкая модель с самым широким функционалом и возможностью кастомизации.

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

Есть и реальные кейсы в индустрии. Студия Marvel использовала Midjourney для быстрого создания концепт-артов неземных миров в своих продуктах. Coca-Cola запустила рождественскую рекламу с AI-сгенерированными изображениями «вкуса будущего».

DALL·E, Midjourney и Stable Diffusion — это диффузионные модели, принцип работы которых мы объясняли в предыдущем разделе. Добавим, что нейросеть, которая уже научилась убирать шум, создает изображение почти мгновенно.

На основе диффузионной модели работает также нейросети семейства Adobe Firefly — с их помощью пользователь создает реалистичные изображения и редактирует загруженные фото (например, дорисовывает пляж на заднем фоне).

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

• логотипов — нейросеть может сгенерировать 100 вариантов за минуту;
• рекламных баннеров — не придется нанимать дизайнера;
• спецэффектов в кино — ИИ может реалистично омолодить и состарить актера, сделать фон и т.д.;
• новых дизайнов одежды и аксессуаров;
• персонажей для игр (пишешь «герой-гоблин с копьем» и готово);
• реалистичных текстур (камня, металла);
• фоновых изображений — можно сгенерировать целые города для open-world игр;
• NPC — эти персонажи не клоны, а уникальные.

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

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

Генерация музыки

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

Нейросети для генерации музыки типа Jukebox, Magenta, Boomy, AIVA тоже воспринимают текстовые запросы. Например, можно дать задание: «Напиши трек в стиле группы Queen, но с другим голосом». Уже через минуту задание будет выполнено.

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

1. Разбор музыки на части. Нейросеть анализирует тонны треков, запоминая аккорды (например, что после C#m часто идет F#), ритм (как сочетаются ударные и бас), структуру (куплет- припев-соло).
2. Токенизация. Мелодии разбиваются на еще более мелкие элементы (ноты, аккорды, тембры). Например, в OpenAI Jukebox музыка кодируется в виде последовательности чисел — почти как слова в ChatGPT.
3. Генерация: от простого к сложному. Сначала нейросеть учится создавать ритм (ударные), потом добавляет гармонию (аккорды), в финале мелодию и вокал (да, ИИ может петь!).

У нейросетей-музыкантов даже есть некоторые достижения. Например, в треке Drowned in the Sun нейросеть «оживила» стиль Nirvana. Существует альбом, названный «Hello World», полностью написанный ИИ в стиле поп-панка.

В числе преимуществ:

• быстрота — демо-трек за минуту вместо недель в студии;
• эксперименты — можно смешивать стили («классика с элементами фри-джаза»).
• доступность — не нужно знать нотную грамоту.

Есть минусы:

• бездушность — пока ИИ не хватает эмоций живых исполнителей;
• копирование — нейросети иногда «воруют» куски из реальных песен;
• авторские права — кто владеет треком: вы, ИИ или тот, чьи песни были в обучающей выборке?

Если вы хотите попробовать себя в деле сочинения музыки, начните с Boomy. Это самый простой вариант: выбираете жанр, жмете кнопку — получаете трек.

Через 5-10 лет нейросети, вероятно, смогут:

• Писать саундтреки персонализировано — под ваше настроение прямо сейчас.
• Генерировать живые концерты с виртуальными артистами в VR.
• Ассистировать музыкантам — например, подбирать аккорды «на лету» во время джема.

ИИ никогда не сможет заменить The Beatles или Моцарта, но он уже отлично справляется с фоновой музыкой для стримов, подкастов и игр. В таком качестве их применение будет только развиваться.

Генерация кода

Применение AI генеративного типа упрощает и ускоряет разработку программ. Нейросети анализируют запросы разработчика и создают код на всех топовых языках программирования, включая Python и JavaScript.

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

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

Представьте: вы набираете в IDE комментарий: #напиши функцию, которая парсит JSON и выводит список пользователей, и код появляется сам собой. Это не фантастика — это уже реальность. Современные генеративные модели умеют писать, дополнять и даже исправлять код. Более того, они уже способны создавать прототипы ПО на основе текстовых промптов, что позволяет оперативно оценивать идеи.

Как это работает:

1. Нейросети считывают тонны публичного кода из GitHub, Stack Overflow и других открытых источников. Они запоминают синтаксис языка, популярные алгоритмы (сортировки, работа с API), шаблоны. И не просто запоминают, а фиксируют закономерности.
2. Далее происходит токенизация: нейросеть разбивает код на токены — «кирпичики». Это ключевые слова (например, if, for, def), имена переменных, операторы. ИИ предвидит, какие токены должны идти дальше почти так же, как в чат-ботах, но с упором на правильный синтаксис.
3. В работе с генеративным AI, контекст — ключ к качественному результату. Запрос должен быть максимально точным.

Пример правильного запроса:

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

Конкретные примеры использования генераторов кода:

• Автодополнение. Copilot дописывает код в реальном времени, может написать за вас SQL-запрос или функцию на Python.
• Обучение новичков. ChatGPT (GPT-4) объясняет код, исправляет ошибки, генерирует фрагменты.
• Amazon CodeWhisperer настроен на работу с облачными сервисами.

У этих во многом полезных инструментов есть определенные риски:

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

Совет. Всегда проверяйте сгенерированный код — пока что ИИ все-таки больше умный помощник, чем полноценный программист.

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

Однако разработчики, которые занимаются созданием оригинальных продуктов, могут не опасаться за свое будущее. ИИ пока не сможет заменить их труд полностью, а скорее станет «умной клавиатурой» для прогеров. Причина проста — даже самая продвинутая версия ChatGPT не поймет до конца логики бизнес-проекта, это под силу только человеку.

Но есть все основания полагать, что будет создан реальный «Бизнес-ИИ», который поможет организациям автоматизировать бизнес-процессы, вывести на новый уровень взаимодействие с клиентами и многократно повысить эффективность.

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

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

Он почти 25 лет пишет код и пережил уже не одну «революцию» в индустрии. Сейчас, по его мнению, мы наблюдаем не конец профессии, а очередной виток развития инструментов.

Больше новостей — в нашем тг-канале «Представляешь»

«Когда я был маленьким…»

Матейс вспоминает, как начинал программировать на стареньком 486-м ПК отца, с книжкой по DOS-командам и QBasic. Без автодополнения, без подсветки синтаксиса, без Stack Overflow.

Только PRINT, библиотеки и надежда, что после очередного запуска программа не вылетит. Каждый новый инструмент — будь то ConTEXT, Eclipse или Stack Overflow — упрощал жизнь, сокращал время на рутину и освобождал место для настоящей работы: понимания задач, архитектуры и решений.

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

Что ИИ умеет хорошо — и где спотыкается

ИИ-помощники вроде ChatGPT, Codeium и Windsurf действительно ускоряют повседневную рутину. Надо сгенерировать перевод, сэкономить на бойлерплейте, быстро понять, как устроен новый фреймворк — пожалуйста.

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

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

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

ИИ — не магия, а просто дорогой предсказатель

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

Никакого «разумного понимания» нет. Поэтому ИИ может не только ошибаться, но и выдумывать функции, стирать код, ломать архитектуру — просто потому, что не понял контекста. Особенно если контекста много.

Почему нужен человек — и, возможно, даже больше, чем раньше

Лагерберг отмечает: даже если ИИ выглядит уверенным, его решения могут быть опасны. Неопытные разработчики, копируя с Stack Overflow, рисковали и раньше. Сейчас они рискуют в разы больше — потому что доверяют коду, который выглядит идеально, но может оказаться полным бредом.

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

Вывод: пусть копилот сидит на пассажирском

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

Он не против помощника — но пусть тот сидит сбоку, а не за рулем. Потому что карту он читает, может, и хорошо. Но рулить всё равно должен человек.

Почему это вообще важно?

AI-инструменты уже не просто помогают разработчикам — они активно пишут код. GitHub Copilot, ChatGPT, Codeium и другие способны за секунды сгенерировать сложные алгоритмы, SQL-запросы, тесты и даже целые API. С одной стороны, это удобный способ ускорить разработку, снизить рутину и сделать код чище. Но с другой — AI-код не всегда надежен, а слепое копирование может привести к багам и уязвимостям.

Если раньше единственной угрозой было «гуглить решения на Stack Overflow», то теперь ситуация сложнее: AI-код может быть логически неверным, не соответствовать бизнес-требованиям или использовать устаревшие практики. При этом его сложно сразу раскритиковать — он выглядит идеально, четко структурирован и, на первый взгляд, работает.

Собрали основные причины, почему важно уметь отличать AI-код от написанного человеком:

• AI не всегда понимает контекст и может предложить небезопасные решения, например, SQL-инъекции или некорректную обработку данных.
• AI не знает внутренних договоренностей команды, поэтому может генерировать код, который не вписывается в общую архитектуру.
• AI не знает внутренних договоренностей команды, поэтому может генерировать код, который не вписывается в общую архитектуру.
• AI может выдавать хоть и корректный, но совсем не соответствующий требованиям бизнеса код.
• Некоторые AI-решения обучены на коде с лицензиями, несовместимыми с коммерческими проектами, что может привести к юридическим проблемам.

Кроме того, AI-код всё чаще встречается не только в продакшн-решениях, но и на собеседованиях. Работодатели начали сталкиваться с кандидатами, которые просто копируют ответы из ChatGPT и не могут объяснить, как работает их код.

По данным Stack Overflow Developer Survey 2024, более 70% разработчиков уже используют AI в кодинге, а 40% признались, что нейросети хоть раз предлагали им потенциально небезопасные решения. Поэтому сейчас важно не просто уметь пользоваться AI, но и понимать, где он может навредить.

Где чаще всего встречается AI-код?

AI-сгенерированный код может появиться где угодно: от свежего pull request’а в репозитории до ответа на Stack Overflow или тестового задания кандидата. Иногда это просто вспомогательные сниппеты, а иногда — полноценные фрагменты, которые выглядят слишком «чисто», но вызывают ощущение, что что-то не так.

Разберем, в каких ситуациях чаще всего встречается AI-код и как его распознать.

Кодовые ревью

Допустим, в репозиторий приходит pull request, и он выглядит… странно. Формально код работает, но:

• Он слишком абстрактный и не учитывает специфику проекта.
• Переменные и методы названы шаблонно: processData(), getResponse(), handleRequest().
• Комментарии избыточны или выглядят так, будто их писал учебник: «Этот метод сортирует массив по возрастанию» (да, спасибо, КЭП).
• Код слишком формальный, без характерных для команды решений или оптимизаций.

Пример:

Вы просите разработчика написать логику валидации email-адреса, а в PR прилетает нечто такое:

Формально всё корректно. Но если в вашем проекте уже есть встроенные механизмы валидации (например, DataAnnotations в .NET), такой код выглядит излишним. Кроме того, регулярка взята из учебников и не учитывает edge-кейсы. Это может быть явным признаком AI-генерации.

Форумы и Stack Overflow: кто-то выкладывает красивый, но подозрительно академичный код

AI-код часто появляется в ответах на Stack Overflow, GitHub Discussions или Reddit. На первый взгляд, он идеален, но:

• Не учитывает контекст задачи;
• Не использует упрощения, принятые в реальной разработке;
• Выглядит так, словно его писал преподаватель для учебного пособия.

Пример:

Кто-то спрашивает: «Как перевернуть строку в Python?»

Ответ от AI:

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

Или

Люди обычно пишут проще и без ненужных комментариев.

AI-код в legacy-проектах: «быстро сгенерили, а потом никто не разобрался»

AI помогает быстро закрыть задачу, но иногда это оборачивается проблемами для будущих разработчиков. Представьте, в legacy-коде уже начали появляться фрагменты, которые никто не может понять, потому что их сгенерировал AI, а автор ушел из проекта (надеемся, не жиза).

Пример:

Вы находите в коде функцию, которая вроде бы что-то делает, но написана так, что ее никто не понимает:

Комментариев нет, названия переменных обобщенные. Оказывается, это было быстрое AI-решение для шифрования, но никто не знал, что тут XOR с чередующимися ключами.

Еще один тревожный сигнал — фрагменты кода, которые выглядят слишком универсально, но плохо вписываются в логику проекта. Например, в коде на C# встречается сложная реализация сортировки, хотя в .NET уже есть встроенные методы, делающие то же самое.

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

С ростом AI-разработки на собеседованиях всё чаще встречаются кандидаты, которые приносят решения из ChatGPT. Важно понять, действительно ли человек писал код сам, или просто скопировал без понимания.

Как распознать AI-код на интервью:

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

Пример:

Вы даете тестовую задачу: «Напишите функцию для поиска всех простых чисел до N».

AI-кандидат приносит это:

Формально всё правильно, но человек, скорее всего, объяснил бы решение проще и без таких заумных комментариев.

Как проверить такого кандидата? Лучший способ — попросить изменить или оптимизировать код. Если он не может объяснить каждую строчку или предложить альтернативный вариант, он, скорее всего, просто скопировал ответ из AI.

Шпаргалка: 6 признаков, что код написан AI

AI-код часто выглядит идеально с точки зрения синтаксиса, но его выдаёт стиль, структура и некоторые неестественные решения. Разберем шесть главных признаков, которые помогут быстро понять, что перед вами код от нейросети.

Слишком академичный стиль

AI часто пишет код так, будто это учебное пособие: использует полный формальный синтаксис, лишние комментарии и развернутые определения.

Пример:

Кто-то просит написать функцию на Python для поиска максимального значения в списке. Человек бы написал так:

AI же может предложить развернутый вариант:

Этот код работает, но выглядит так, словно вышел из учебника.

Избыточные и очевидные комментарии

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

Пример:

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

Неестественные или шаблонные названия переменных

AI генерирует код по шаблону и часто использует слишком общие, но «правильные» названия.

Пример:

В реальности разработчик скорее назвал бы класс CsvParser или LogAnalyzer, а не абстрактный DataProcessor.

Неоптимизированные решения, игнорирующие стандартные библиотеки

AI может создать велосипед, даже если есть готовое стандартное решение.

Пример:

Запрос: «Написать код, который объединяет строки в список с запятыми».

AI-код:

Но в Python есть встроенный join(), и нормальный разработчик написал бы просто:

Код слишком универсален, но не учитывает реальный контекст

AI пытается писать универсальные решения, даже если это не нужно.

Пример:

Допустим, нужна функция, которая складывает два числа. Человек просто сделает:

AI же может предложить универсальный метод с кучей проверок:

На вид хорошо, но зачем здесь проверка на отрицательные числа?

Используются устаревшие или редко применяемые методы

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

Пример:

Для чтения файлов в Python AI может предложить:

Хотя уже давно правильный вариант:

Так код выглядит безопаснее и не оставляет открытые файловые дескрипторы.

Хотя AI часто можно вычислить, это не значит, что его нельзя применять. Наоборот, в ряде случаев нейросети могут здорово ускорить работу разработчиков. Главное — понимать, где AI будет полезным помощником, а где может навредить. Рассмотрим несколько сценариев, в которых сгенерированный код действительно помогает.

AI-код не всегда плох: когда его можно (и нужно) использовать

Генерация шаблонного кода (CRUD-операции, конфигурации, тесты)

Разработчики часто сталкиваются с задачами, которые повторяются от проекта к проекту. Например, создать REST API с базовыми CRUD-операциями, написать конфигурационные файлы или сгенерировать unit-тесты.

Пример:

Допустим, нужно быстро создать контроллер для работы с сущностью User в Node.js + Express. Человек может вручную писать стандартные GET, POST, PUT и DELETE, а может поручить это AI:

Такой код вполне можно доверить AI, потому что он шаблонный и не требует сложной бизнес-логики.

Когда стоит использовать?

• Генерация стандартных CRUD-операций;
• Создание базовых конфигурационных файлов (например, docker-compose.yml);
• Автоматическое написание тестов для базовых сценариев.

Автоматизация рутинных задач (генерация SQL-запросов, скрипты для CI/CD)

AI отлично справляется с рутинными задачами, которые требуют знаний синтаксиса, но не требуют креативности. Например, он может быстро сгенерировать сложный SQL-запрос или YAML-скрипт для CI/CD.

Пример:

Нужно составить SQL-запрос для получения списка клиентов, которые сделали заказ в последние 30 дней. AI может сразу предложить готовое решение:

Вручную писать такие запросы несложно, но если их много, AI может сэкономить кучу времени.

Когда стоит использовать?

• Написание SQL-запросов на основе простых описаний;
• Генерация конфигураций CI/CD (например, .gitlab-ci.yml или Jenkinsfile);
• Создание вспомогательных скриптов для автоматизации (например, bash-скриптов для деплоя).

Помощь в написании boilerplate-кода и документации

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

Пример:

AI может быстро создать интерфейс для TypeScript на основе JSON-данных. Так:

AI-сгенерированный TypeScript-интерфейс:

Кроме того, AI может помочь с генерацией документации. Например, если нет комментариев, он их добавит, что особенно полезно при работе с чужим кодом.

Когда стоит использовать?

• Написание интерфейсов и типов для TypeScript или Java;
• Генерация обработчиков исключений и логирования;
• Автоматическое создание документации (например, для API в OpenAPI/Swagger).

Генерация идей, но не слепое копирование (AI как ассистент, а не разработчик)

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

Пример:

Разработчик хочет ускорить поиск в огромном массиве данных. AI предложит несколько алгоритмов (B-дерево, бинарный поиск, хеш-таблицы), а уже сам программист выберет, что подходит лучше.

Когда стоит использовать?

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

AI — не замена разработчиков, а инструмент, который помогает ускорять работу. Его можно и нужно использовать для рутинных задач, но всегда с проверкой и пониманием контекста.

Как научиться быстро определять AI-код?

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

Задавайте себе правильные вопросы

Когда видите код (в PR, на форуме, в тестовом задании), попробуйте мысленно пройтись по этим вопросам:

• Логична ли структура? Если код выглядит идеально отформатированным, но при этом содержит нелогичные или избыточные конструкции, это подозрительно.
• Есть ли повторения? AI любит дублировать куски кода, даже если их можно оптимизировать.
• Реализация слишком академичная? Если код выглядит так, будто его писал профессор компьютерных наук, но без учета реального использования — возможно, его сгенерировал AI.
• Код соответствует задаче или просто «выглядит умно»? Иногда AI генерирует код, который слишком сложен для простой задачи. Например, вместо for-цикла он может предложить рекурсивный алгоритм без реальной необходимости.

Сравнивайте с примерами из реального продакшен-кода

Если вам кажется, что код написан AI, попробуйте сравнить его с примерами из проектов, над которыми работали вы или ваши коллеги. Настоящий код часто:

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

Проверяйте код на избыточность и неестественные конструкции

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

• Ненужные проверки (if True:);
• Лишние константы вместо прямых значений;
  
• Чрезмерная типизация в языках, где это необязательно;
  
• Странные циклы, когда можно использовать встроенные методы.

Определять AI-код — навык, который развивается с опытом. Главное — обращать внимание на логику, осмысленность и соответствие реальным сценариям использования. Если код кажется слишком правильным, но при этом странным — скорее всего, его написал не человек.

По данным StackExchange Data Explorer, количество новых вопросов сократилось на 75% по сравнению с пиком 2017 года и на 60% за последний год к декабрю 2024 года.

Снижение началось ещё до появления ChatGPT в 2022 году, но с его запуском ситуация резко ухудшилась.

Разработчик Теодор Смит, один из бывших топовых участников платформы, отметил, что «Stack Overflow осталось менее года жизни», связывая падение с популярностью ИИ-ассистентов и проблемами внутренней культуры сайта.

Роль ИИ и политика Stack Overflow

Универсальные ИИ-ассистенты, такие как ChatGPT, стали причиной того, что разработчики реже обращаются к Stack Overflow за помощью. Вместо того чтобы создавать новые вопросы, они могут получить ответы в реальном времени. Однако это не единственная причина спада.

Stack Overflow запретил использование генеративного ИИ для ответов на вопросы в 2022 году, мотивируя это низким качеством таких ответов и сложностью их модерации. Несмотря на улучшение качества ИИ-ответов, запрет остаётся в силе, вызывая споры в сообществе.

Последствия снижения активности

Меньшее количество новых вопросов ограничивает покрытие современных технологий. Это приводит к тому, что Stack Overflow становится менее полезным для поиска решений по новым инструментам и фреймворкам.

При этом Stack Overflow остаётся бизнесом. Платформа монетизирует свою базу знаний через сделки с Google, OpenAI и GitHub. Также компания предлагает продукт OverflowAI — генеративный инструмент для корпоративных пользователей, который интегрируется с Stack Overflow Teams.

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

Проблемы с ИИ-контентом

Генеративные ИИ-модели, такие как ChatGPT, позволяют быстро создавать тексты, но их точность оставляет желать лучшего.

Пользователи начали массово публиковать такие ответы и модераторы Stack Overflow, которые работают на волонтерской основе, не успевали проверять и фильтровать этот поток.

Это привело к тому, что платформа стала переполняться низкокачественным контентом, что снизило ее ценность для тех, кто ищет достоверные ответы.

История запрета

Первоначально запрет на использование ИИ для создания контента был введен временно в декабре 2022 года, вскоре после появления ChatGPT.

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

Какие меры приняты?

Теперь на Stack Overflow запрещено публиковать любые материалы, созданные с помощью ИИ. Если пользователь попытается обойти это правило, к нему могут применить санкции, включая баны.

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

Основные результаты опроса

В опросе приняли участие более 65 тыс разработчиков из 185 стран. Главными темами этого года стали использование ИИ и недовольство на рабочем месте, которое достигло невиданных высот.

ИИ увеличивает производительность

72% респондентов поддерживают использование ИИ-инструментов, хотя в прошлом году этот показатель составлял 77%.

Снижение удовлетворенности можно объяснить разочарованием в достигнутых результатах.

Несмотря на это, 76% разработчиков используют или планируют использовать ИИ в своей работе, что выше показателя прошлого года (70%).

Недостатки ИИ

Почти половина (45%) профессиональных разработчиков считают, что ИИ-инструменты плохо справляются с решением сложных задач.

Основное применение ИИ – написание кода (82%), а также тестирование кода (46%).

Опасения разработчиков

70% профессионалов не видят в ИИ угрозы для своей работы, но 79% беспокоятся о распространении дезинформации.

Главная проблема ИИ – недостаток понимания базы кода.

При этом 80% разработчиков недовольны своей работой, а каждый третий откровенно ее ненавидит.

Основные причины недовольства

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

Вывод

Несмотря на недовольство на работе, большинство разработчиков занимаются написанием кода в свободное время как хобби (68%) или для профессионального развития (40%), что говорит о том, что проблема не в главном навыке программистов.

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

Реакция пользователей

Пользователь по имени Бен поделился опытом редактирования наиболее успешных своих ответов, чтобы избежать «кражи» этого труда OpenAI.

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

Пользователи также выразили недоумение о том, почему ChatGPT не может просто указывать источники ответов. Это бы, по мнению комьюнити Stack Overflow, добавило бы признания инструменту и позволило бы пользователям видеть, откуда берутся данные.

Юридическая основа борьбы

Пользователи, возмущенные невозможностью удалить свой контент с сайта, опираются на «право на забвение» — концепцию, закрепленную в Общем регламенте по защите данных (GDPR) Еврособза.

Правда, стоит отметить, что в «Условиях использования Stack Overflow» содержится пункт, который наделяет платформу «неотзывным правом владения всем предоставленным на сайте контентом».

Изменения в политике Stack Overflow

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

Модераторы даже использовали программы для обнаружения ИИ-генерированного контента. Однако на прошлой неделе компания резко изменила свою публичную политику в отношении искусственного интеллекта, о чем мы написали отдельный материал.

Отметим, что ситуация вокруг Stack Overflow является частью более широкой тенденции в индустрии, где компании пересматривают свои «принципиальные позиции» по поводу ИИ в погоне за прибылью.

Что в этом хорошего для OpenAI?

С помощью OverflowAPI, OpenAI не только улучшит производительность своих моделей, но и сможет встроить проверенные «IT-знания» в ChatGPT.

Это значит, что всем нам будет гораздо легче получить доступ к надежной и высокотехнологичной информации и коду, который поддерживают миллионы разработчиков со Stack Overflow.

А что насчет Stack Overflow?

Не останутся в стороне и Stack Overflow — сервис тоже получит свою долю пользы.

Используя модели OpenAI, платформа продолжит разработку OverflowAI. Это значит более продвинутые возможности и улучшенные функции для их огромного сообщества разработчиков.

Когда все это произойдет?

Первая волна интеграции двух платформа ожидается уже в I половине 2024 года.

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

Докладчик предлагает пошаговый подход к изучению веб-разработки, начиная с основ HTML, затем изучения CSS для добавления стиля и макета на страницу. После этого предлагается приступить к первому проекту, создав портфолио или веб-сайт с использованием HTML и CSS.

Затем следует изучение основ JavaScript и манипуляции DOM для добавления интерактивности. После этого предлагается создать проект с интерактивностью, что позволит оттачивать навыки отладки и использования различных инструментов. Далее докладчик предлагает углубить знания в HTML, CSS и изучить основы бэкэнд-разработки, включая работу с сервером, базами данных, а также изучение Git и GitHub.

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

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

Вот, о чём идёт речь в видео:

1. Изучение программирования сложно, большинство начинающих терпят неудачу, особенно в веб-разработке из-за избытка информации.
2. Автор предлагает пошаговый подход к изучению веб-разработки без теоретических отступлений и множества возможных направлений.
   
3. Первым шагом является изучение HTML для определения содержания и структуры веб-сайта.
   
4. После HTML следует изучение CSS для добавления стилей и макета страницы.
   
5. Важно активно практиковаться, создавая проекты, например, портфолио или резюме, и использовать инструменты разработчика для тестирования CSS.
   
6. Следующий шаг - изучение JavaScript для добавления интерактивности на веб-сайты, начиная с основ языка и манипуляции с DOM.
   
7. После освоения JavaScript рекомендуется создать проект, например, игру в браузере, и практиковать отладку и поиск решений проблем в интернете.
   
8. Повторный взгляд на HTML и CSS: изучение доступности, адаптивного дизайна, анимаций, CSS-фреймворков и препроцессоров.
   
9. Переход к изучению серверной части с использованием Node.js и Express, а также основ работы с терминалом, Git и GitHub.
   
10. Изучение баз данных, включая SQL и NoSQL, начиная с MySQL и MongoDB.
    
11. Создание полноценного проекта с бэкендом и базой данных, добавление уникальных особенностей для резюме.
    
12. После основ начинается изучение фреймворков и библиотек, таких как React, для упрощения разработки.
    
13. Проект с использованием React и изучение TypeScript для строгой типизации в больших кодовых базах.
    
14. Основы компьютерных сетей, включая IP-адреса, HTTP/HTTPS и DNS.
    
15. Основы облачных вычислений и развертывания веб-приложений в облаке с использованием AWS и EC2.
    
16. Изучение Docker и контейнеров для обеспечения изоляции и одинаковой среды выполнения кода.
    
17. Основы безопасности веб-разработки, включая защиту от SQL-инъекций, межсайтовой подделки запросов и скриптинга.
    
18. Использование Next.js и серверной отрисовки для повышения производительности и индексации в поисковых системах.
    
19. Автор советует глубже изучать интересующие темы и избегать менее важных, но при этом следовать правильному подходу к обучению.
    

Ниже — транскрибированный перевод видео на русский язык.

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

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

Основы HTML и CSS

Нет миллиона различных возможностей, куда можно двигаться. Просто последовательный подход от начала до конца, который вы можете начать прямо сегодня. Первое, что вам нужно изучить, это основы HTML или язык гипертекстовой разметки. Это язык, который мы используем для определения содержания и структуры веб-сайта. Представьте, что у вас есть текст, который должен быть размещен на веб-сайте. Нам нужно определить, что является заголовком, что является абзацем и так далее, и мы делаем это с помощью HTML.

Сейчас вам не нужно слишком углубляться. Цель - просто уметь взять простой текст и преобразовать его в базовый HTML-документ. И после HTML пришло время изучить основы CSS или каскадные таблицы стилей. Это то, как мы добавляем стиль и макет на страницу. По сути, как мы берем наше содержание и придаем ему жизнь, добавляем цвета, макет и описываем, как оно должно выглядеть.

И после того, как вы изучите немного CSS, пришло время немного отдохнуть и попробовать поработать над своим первым проектом. Я крайний сторонник идеи, что вам нужно активно учиться. Поэтому не просто проходите кучу учебных пособий. Убедитесь, что вы делаете что-то, чтобы постоянно учиться и проверять свои знания. Если вам нужна идея, то можете сделать портфолио для себя или что-то вроде страницы "Обо мне" или резюме, используя HTML и CSS. Это также отличное время, чтобы научиться использовать инструменты разработчика, с которыми вы станете очень хорошо знакомы со временем.

Изучите JavaScript

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

И, вероятно, этот этап займет больше всего времени. Я бы порекомендовал вам пройти какой-то курс, будь то здесь, на YouTube, или какой-то платный курс где-то еще, но просто изучите основы JavaScript и научитесь хорошо использовать язык. И после этого вы можете перейти к манипуляции DOM, то есть как мы используем JavaScript для изменения содержания веб-сайта, как мы добавляем эту интерактивность.

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

И работая над этим проектом, вы, вероятно, обнаружите, что это самое сложное, что вы делали до сих пор, но это на самом деле хорошо. Это даст вам больше возможностей практиковать новые навыки отладки. Изучите, как использовать JavaScript с инструментами разработчика, а также научитесь искать проблемы с JavaScript в Google и на Stack Overflow. И я также рекомендую попробовать использовать ChatGPT, когда у вас возникают проблемы.

Теперь, не просто копируйте код с Stack Overflow или GPT или откуда-то еще. Используйте их как инструменты, чтобы научиться делать вещи. Но попробуйте начать включать их в свой рабочий процесс. Хорошо, теперь у вас есть этот невероятный веб-сайт с интерактивностью, но пришло время немного улучшить свои навыки и вернуться к некоторым вещам, которые мы ранее пропустили.

На что сделать упор в HTML и CSS

С HTML я бы сосредоточился на том, как писать доступный HTML. А с CSS я бы сосредоточился на адаптивном дизайне. И если вас особенно интересует CSS, вы можете учить такие вещи, как переходы и анимации, систему сетки и как писать более сложные селекторы, такие как псевдоклассы и псевдоэлементы. Вы также можете использовать это время, чтобы изучить некоторые CSS-фреймворки, такие как Bootstrap и Tailwind, которые по сути являются предварительно написанным CSS для вас, или вы можете изучить некоторые препроцессоры, такие как SAS или less, которые добавляют некоторые интересные функции в CSS.

И чтобы быть ясным, я не думаю, что вам нужно это делать. Я просто хотел упомянуть об этом на случай, если вас особенно интересует CSS. И теперь вы должны быть довольно комфортны на фронт-энде, и пришло время начать работать с бэк-эндом. Так что на этом этапе я бы сначала научился делать запрос к серверу с фронт-энда. Так что с помощью JavaScript, как использовать fetch и как писать асинхронный код.

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

Терминал и GitHub

И еще одна конкретная вещь, которую нужно изучить с терминалом, это как использовать Git и GitHub. Git - это просто система контроля версий. Она просто отслеживает все ваши изменения, как история Google Docs, но только для кодирования.

И GitHub - это просто веб-сайт для загрузки вашего репозитория Git, таким образом, вы можете поделиться им с другими людьми. И теперь, чтобы начать писать некоторый бэк-энд код, я бы порекомендовал вам изучить Node.js с Express. Причина, по которой я говорю это, заключается в том, что Node.js позволяет вам использовать JavaScript на бэк-энде, так что вам не нужно изучать целый новый язык программирования, просто несколько новых функций для JavaScript. И с Node вам также нужно изучить NPM или менеджер пакетов node, который просто позволяет вам интегрировать открытый исходный код в ваши собственные проекты.

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

Базы данных и SQL

И для этого вам нужно изучить немного о базах данных. Существует два основных типа баз данных, и я бы изучил немного обоих. Так что у нас есть SQL-базы данных и NoSQL-базы данных. SQL или SQL - это реляционная база данных.

Так что это позволяет вам в основном иметь множество различных таблиц и как-то связывать их между собой. И существует множество вариантов SQL. Большинство из них очень похожи друг на друга, но MySQL, вероятно, хорошее место для начала, но не стесняйтесь использовать тот, который вам больше нравится. А NoSQL-база данных - это просто любой другой тип базы данных. Так что это может быть хранилище документов или некоторая система пар ключ-значение.

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

Так что если это то, что вы хотите делать, попробуйте добавить какой-то уникальный поворот к любому вашему проекту, чтобы он немного выделялся. И на этом этапе вы можете сказать: где фреймворки и библиотеки? Где модные слова, такие как React и Vue и Angular? И сейчас пришло время, я думаю, начать их изучать. И ключевой момент, который здесь следует отметить, заключается в том, что мы долго ждали, чтобы их изучать.

Фреймворки и библиотеки

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

Итак, когда вы дойдете до этой точки, где вы действительно можете их понять и создавать собственные приложения без фреймворков и библиотек, пришло время начать их изучать, потому что они важны для индустрии. Я бы начал с React, просто потому что это самый популярный, у него самая большая экосистема, и из-за всех этих вещей это также самый востребованный навык. Но, конечно, если вы предпочитаете изучить что-то другое, вы можете сделать это. И теперь, когда вы знаете React, пришло время для еще одного проекта. Что я бы сделал с этим проектом, так это просто взял бы последний проект, который вы сделали, и преобразил бы код в React. И на этом этапе я бы также изучил бы TypeScript.

Изучите TypeScript

Итак, TypeScript - это надмножество JavaScript, что означает, что весь JavaScript допустим в TypeScript, но не весь TypeScript допустим в JavaScript. И все, что он действительно добавляет, это строгая типизация. Таким образом, вы можете определить типы всего, что вы пишете на JavaScript, что может быть очень полезно в больших кодовых базах. Я много времени провел, пиша код, но не так много времени думая о том, как этот код вообще попадает в браузер, как работает весь этот интернет. Поэтому я бы изучил немного компьютерных сетей.

Это действительно будет очень важно в будущем. Просто изучите основы того, что происходит, когда вы вводите URL в свой браузер. Если вы можете ответить на этот вопрос, вы, вероятно, хорошо разбираетесь в компьютерных сетях, если только вас это не интересует и вы хотите углубиться. И конкретно это означает, что вам нужно понять такие вещи, как IP-адреса, HTTP и HTTPS, и систему DNS. И я создавал эти веб-сайты, но мы знаем только, как запускать их с нашего собственного компьютера. Поэтому пришло время изучить немного об облачных вычислениях, потому что что бы произошло, если бы в моем доме отключили свет?

Ну, мой веб-сайт бы вышел из строя, и это нехорошо. Поэтому мы хотим узнать, как использовать облако вместо этого.

Облачные вычисления

Облачные вычисления просто позволяют вам запускать свой код на компьютерах кого-то другого. Крупнейшие поставщики облачных вычислений будут Amazon с AWS, Google с GCP и Microsoft с Azure. Я бы порекомендовал начать с AWS, просто потому что это самый популярный, но любой из них подойдет.

И на данный момент, как и многие другие вещи, вам не нужно углубляться слишком сильно. Вы можете узнать больше, когда вам понадобится что-то в будущем, но сейчас просто научитесь развертывать свое веб-приложение в облаке. Поэтому, если вы используете AWS, вам захочется узнать, как использовать EC2. И сейчас, когда вы изучаете, как использовать облако, также может быть полезно углубиться немного в инфраструктуру.

Docker и контейнеры

Таким образом, вы можете узнать, как использовать вещи, такие как Docker и контейнеры, что позволяет вам убедиться, что когда ваш код запускается, где бы он ни находился, он будет запускаться в изоляции и в точно такой же среде каждый раз. Далее, любому хорошему веб-разработчику следует хорошо понимать безопасность, потому что вам нужно уметь не только защищать свой веб-сайт, но и данные ваших пользователей. Для этого вам нужно понять некоторые из наиболее распространенных атак, которые могут быть совершены против вашего веб-сайта. Это такие вещи, как SQL-инъекции, межсайтовая подделка запросов или межсайтовый скриптинг. И затем вам нужно узнать о различных концепциях, используемых для предотвращения этих типов атак. Такие вещи, как CORS и валидация ввода как на стороне клиента, так и на стороне сервера, а также просто шифрование.

Таким образом, убедитесь, что мы используем HTTPS и что мы шифруем пользовательские данные, такие как пароли. И теперь вы создаете эти невероятные веб-сайты, но вам нужно убедиться, что они действительно производительны и что они высоко ранжируются в поиске на Google. Хороший способ сделать это - использовать Next.js и более обще изучить серверный рендеринг. Это позволяет вам рендерить некоторые компоненты с серверной стороны и отправлять их обратно, как сырой HTML на фронт-энд.

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

Всего в исследовании приняли участие 90 тысяч разработчиков. Также Stack Overflow спросил у респондентов, какими инструментами они чаще всего пользуются, включив в варианты ответа ИИ-инструменты вроде ChatGPT.

Самыми популярными языками оказались JavaScript, HTML/CSS и Python. При этом JS занимает первое место в рейтинге уже 11 лет подряд.

HTML/CSS и JavaScript — самые популярные языки для людей, изучающих программирование.

Студенты-разработчики чаще используют Python, чем SQL (59% против 37%), в то время как профессиональные разработчики сообщают, что используют SQL чаще, чем Python (52% против 45%).

По сравнению с профессиональными разработчиками, те, кто учится программировать, чаще используют Java (37% против 31%), C++ (32% против 20%) и C (32% против 17%).

Rust — язык, которым больше всего восхищаются. Более 80% разработчиков, которые использовали его однажды, хотят снова использовать его в следующем году.

Меньше всего восхищаются языком программирирования MATLAB. Менее 20% разработчиков, использовавших этот язык, хотят использовать его снова в следующем году.

Что касается инструментов для работы с БД, в 2023 году PostgreSQL занял первое место и обошёл MySQL.

Профессиональные разработчики чаще используют PostgreSQL (50%), а те, кто учится, чаще используют MySQL (54%).

MongoDB используется одинаковой популярностью как профессиональных разработчиков, так и у студентов. Это вторая по популярности база данных для тех, кто учится программировать после MySQL.

Node.js и React.js — две самые популярные веб-технологии. Профессиональные разработчики используют и то, и другое в равной степени. Студенты чаще используют Node.js, чем React (52% против 48%).

jQuery больше используется профессиональными разработчиками, чем студентами (24% против 18%). Express больше используется студентами, чем профессионалами (25% против 18%).

Что касается ИИ-инструментов, чаще всего респонденты выбирают ChatGPT: 83% респондентов использовали его в прошлом году. Это больше, чем у Bing AI, на 20%.

Ознакомиться с полным исследованием от Stack Overflow можно на их лендинге:

Налейте любимый напиток в огромную кружку и украсьте понедельник мемами!

Ищем сотрудника. Кранчей (не) будет

«Если это календарь вам о чём-нибудь говорит, то просканируйте QR-код»

В комментариях обратили внимание на работу в выходные:

Немного о синдроме самозванца

«Не знаю, спроси у челов на Stack Overflow»

Эй, а в чём проблема с веб-разработкой?..

В погоне за KPI

Хорошо ведь, вышел в плюс получается

Постарайтесь не выгореть, любимые читатели!..

Хорошо, когда у джуна есть зарплата

Редкое фото, на котором джуниор получает свою первую зарплату:

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

Блокнот — тоже IDE?

Дорогая IDE, не лети впереди паровоза.

Вспомнил известный рассказ про Элизу. В рассказе код писали в тетрадке:

Опыт разработки — 71 год

Очень быстрый набор опыта

Но есть способ и похитрее:

Делитесь своими мемами под этой записью, и пусть ваш понедельник будет задорным. ?

Стоит отметить, что Prosus NV владеет долями в таких крупных образовательных платформах как Skillsoft, Udemy и Codecademy. Теперь же к ним добавится и Stack Overflow, который является одной из самых популярных платформ для получения ответов от коммьюнити той или иной сферы.

Ожидается, что окончательно сделка будет закрыта в третьем квартале 2021 года. При условии, что регулирующие органы одобрят её, а все условия закрытия будут выполнены.

Отметим, что ранее, в апреле, европейская компания продала 2% от своей доли в другом IT-гиганте — китайской Tencent. Это принесло Prosus более 14 млрд долларов.

Источник: Prosus

Оригинальный пост на Coding Horror датируется 6 апреля 2008 года, то есть почти за полгода до релиза сервиса. В нём Джефф Этвуд спрашивает у своих читателей, как лучше назвать его новый проект. На выбор было представлено множество вариантов, в числе которых был и ставший финальным Stack Overflow.

Название, ставшее финальным, получило 1721 голосов — 25% от общего числа проголосовавших. На втором месте по популярности было Private Void — этот вариант набрал 934 голоса (14%). Замкнуло тройку лидеров название Dereferenced с 755 голосами (11%).

В том же посте Этвуд даёт ссылку на подкаст. В нём разработчик рассказал о том, что вообще будет представлять будущий Stack Overflow.

Источник: Reddit

Авторы курса Learn C++ из Codecademy взяли у Страуструпа интервью. В отдельном материале можно почитать его рассуждения про значимость языка и советы всем начинающим программистам. А здесь мы перевели его ответы на 5 самых популярных вопросов по C++ за всё время.

— Почему отсортированный массив обрабатывается быстрее, чем не отсортированный?

Посмотреть этот вопрос на Stack Overflow, на русском Stack Overflow

— Очень похоже на вопрос с собеседования. Это и правда так? Как это можно проверить? Отвечать на вопрос про производительность, не проведя перед этим измерения — плохая идея, так что нам важно понять, как проводить эти измерения.

Итак, я проверил сортировку массива миллиона целых чисел:

Прим. перев. В оригинальном вопросе автор находил сумму элементов массива и на отсортированных данных это получалось почти в 10 раз быстрее. Страуструп вместо сложения взял ещё одну сортировку и проверил, что быстрее отсортируется: уже упорядоченный массив или рандомный. Звучит глупо, но на самом деле ответ универсальный и применим к любым операциям с массивами. Если данные упорядочены, то работать, скорее всего, будет быстрее.

Я запустил код несколько раз, чтобы убедиться. Действительно, то, о чём говорится в вопросе — правда. Я использовал следующий код:

По крайней мере это правда для моего компилятора, стандартной библиотеки С++ и моих настроек оптимизатора. Разные реализации могут привести и приведут к разным результатам. Есть исследование на эту тему (должно легко гуглиться), и в большинстве реализаций компилятора С++ будет наблюдаться такой же эффект.

Первая причина такого поведения лежит в механизме предсказания ветвлений (branch prediction): основная операция в алгоритме сортировки — сравнение if (v[i] < pivot]) ... или его эквивалент. Для упорядоченной последовательности это сравнение будет всегда истинно, тогда как в рандомном массиве выбор ветки будет случайным.

Другая причина в том, что если массив уже упорядочен, нам не нужно перемещать элементы на правильные позиции. Из-за этих небольших деталей мы и получаем разницу во времени в 5 или 6 раз.

Алгоритм быстрой сортировки (да и алгоритмы сортировки вообще) — это целое исследование, которым занимались величайшие умы computer science. Хорошая функция для сортировки подразумевает как выбор правильного алгоритма, так и учёт особенностей реализации железа.

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

— Что за оператор −−> в С++?

Посмотреть этот вопрос на Stack Overflow, на русском Stack Overflow

— Это старый хитрый вопрос. В С++ нет оператора −−>.

Рассмотрим такой код:

Выглядит так, как будто и правда есть оператор −−>, и если правильно объявить переменные p и m, то код даже скомпилируется и запустится:

Это означает: если p−− больше чем m (а это так), то надо сравнить результат (true) с нулём. Ну, true != 0, так что результат всего выражения — false, и функция f() не вызовется. Другими словами:

Пожалуйста, не тратьте много времени на подобные вопросы. Они сбивали с толку новичков ещё до того, как появился С++.

— Исчерпывающий список книг по С++

Посмотреть этот вопрос на Stack Overflow, на русском Stack Overflow

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

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

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

Рекомендую мою книгу «Программирование. Принципы и практика с использованием C++» для тех, кто только начинает изучать программирование, и «A Tour of C++» для тех, кто уже программирует и хочет больше узнать о современном С++. Люди с хорошей математической базой могут начать с книги Питера Готтшлинга «Современный C++. Для программистов, инженеров и ученых».

Когда вы начнёте использовать C++ по-настоящему, вам понадобится набор правил, чтобы научиться лучшим практикам. Для этого на гитхабе есть C++ Core Guidelines.

За короткими ёмкими объяснениями отдельных особенностей языка и функций стандартной библиотеки рекомендую идти на сайт cppreference.

Бьёрн Страуструп: не существует исчерпывающего списка книг по C++, это бред.

Тем временем редакторы Tproger:

— Чем отличаются ссылки от указателей в С++?

Посмотреть этот вопрос на Stack Overflow, на русском Stack Overflow

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

Чтобы инициализировать указатель, вы даёте ему адрес объекта:

Чтобы считывать и записывать значение через указатель, надо использовать оператор разыменования (*):

Если присвоить одному указателю другой, они оба будут указывать на один и тот же объект:

Заметьте, что один и тот же указатель может в разное время своей жизни указывать на разные объекты. Это ключевое отличие от ссылок. Ссылка привязана к конкретному объекту в момент своего создания и не может позже ссылаться на что-то ещё.

Для ссылок происходит неявное разыменование. Вы инициализируете ссылку объектом, и в ссылке сохраняется адрес этого объекта:

Оператор new возвращает указатель, так что нам нужно разыменовать его перед присваиванием.

Чтобы считывать и записывать значения через ссылку, нам надо просто использовать имя этой ссылки (без явного разыменования):

Когда мы присваиваем одну ссылку другой, то будет скопировано именно значение по ссылке, а не сама ссылка:

Что ссылки, что указатели часто используются в качестве аргументов функции:

Указатель может быть и nullptr, так что нам нужно следить за тем, чтобы он в принципе на что-то указывал. А ссылка всегда относится к какому-то объекту.

— Как пройтись по словам в строке С++?

Посмотреть этот вопрос на Stack Overflow, на русском Stack Overflow прямого аналога не нашли

Надо использовать stringstream. Но как определить, что такое «слово»? Скажем, в предложении «Я устал переводить эту статью.» последнее слово «статью» или «статью.»?

Прим. перев. Перевели строки в коде на кириллицу, компилируется на C++14 (clang 8.0).

Если пунктуации нет вообще, то всё просто:

Или даже так:

По умолчанию оператор >> пропускает пробелы. Если же нам нужен настраиваемый набор разделителей слов, код будет посложнее:

Здесь функция d служит для определения, является ли символ разделителем, и я возвращаю "" (пустую строку) чтобы обозначить, что слов для возвращения не было.

Если у вас есть библиотека Range из C++20, можете использовать split_view вместо того, чтобы писать это всё самостоятельно.

ПФР заявляет, что оцифровал трудовые книжки всех россиян. Это значит, что при найме на работу документы можно будет подавать в электронном виде. Есть лишь два «но».

Во-первых, под это дело пока нет правовой базы. Минтруд планирует внести в Госдуму законопроект об электронных трудовых книжках до конца весенней сессии — до 28 июля. Если его примут, закон вступит в силу со следующего года.

Во-вторых, даже если он вступит в силу, россиянам всё равно придётся возиться с бумажками. Для надёжности. Даже в электронном виде ваш стаж может затеряться в интернетах и не дойти до ПФР. В таком случае придётся подтверждать его документально.

***

В России проведут диктант на тему цифровой грамотности. Он состоит из трёх блоков с вопросами:

• о самых базовых вещах — как обращаться с девайсами и работать с приложениями;
• об онлайне и соцсетях;
• о кибербезопасности.

В диктанте можно поучаствовать очно 18 мая (доступно 67 площадок в 57 городах России) или онлайн с 18 по 24 мая (на сайте цифровойдиктант.рф).

Последствия

Команда Stack Overflow объявила, что 11 мая неизвестные получили доступ к внутренним системам сайта. Идёт расследование. Разработчики выясняют, насколько всё серьёзно, и проверяют сервис на уязвимости.

Утекли пользовательские данные или нет, неизвестно. Руководство сервиса этого не исключает, но подтверждений пока нет.

***

1 марта во Флориде произошло ДТП. Tesla Model 3 ехала по автомагистрали, когда с прилегавшей дороги ей наперерез выехал тягач с полуприцепом. В этот полуприцеп и въехала Tesla. Машине полностью срезало крышу, водитель погиб.

Этот случай расследовал Национальный совет по безопасности на транспорте США. Недавно специалисты опубликовали отчёт. Ключевые факты:

• водитель включил автопилот за 10 секунд до столкновения;
• через 2 секунды после включения автопилота он убрал руки с руля;
• автомобиль ехал со скоростью 109 км/ч при разрешённых 89 км/ч;
• ни водитель, ни автопилот не попытались предотвратить столкновение.

Третья авария со смертельным исходом с 2015 года.

Эксперты жалуются, что компания вводит клиентов в заблуждение насчёт возможностей своих автомобилей. По факту они оснащены продвинутыми системами круиз-контроля. Но подаются как полноценные (или близкие к тому) беспилотные системы. Одна вообще называется «Full Self-Driving Capability» — водитель может подумать, что от него действительно ничего не требуется.

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

5G

Сферический 5G в вакууме на скорости больше 1000 Мбит/с:

Хайлайты

Разработчики снова выделили Python среди других языков программирования. Он находится не на первых строчках, но определённо в первых рядах, обогнав Java. В рейтинге языков, которые программисты больше всего любят, Python занимает второе место (на первом — Rust).

Больше половины респондентов написали первую строчку кода в шестнадцать лет. Это в среднем по всем странам без учёта возраста. В России подростки начинают кодить с 14,5 лет.

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

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

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

В этом году в исследовании участвовали 90 тысяч разработчиков из разных стран мира. В прошлом году респондентов было больше 100 тысяч.

Stack Overflow

Вернули 90-е вместо 2007-го…

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

Весенняя лошадка

Разработчики Stack Overflow также добавили пасхалку для любопытных пользователей и копателей исходных кодов страниц.

Google

Google Змейка

При входе в новую версию мобильного приложения Google Карты появляется возможность поиграть в старую добрую змейку, но с новым смыслом. Вам предстоит водить транспорт (двигается подобно змейке) и подбирать пассажиров (альтернатива маленьким точкам), а также провозить их к местным достопримечательностям или местным блюдам, что даст определённые бонусные очки в игре.

P. S. Google позаботились и о тех, кто не может или не хочет использовать приложение, выложив игру на отдельный сайт.

Google Tulip

Сири, Алекса, Алиса? Пф.

Тюльпаны! Теперь можно общаться с тюльпанами! А ещё с кактусами. У вас с ними больше общего, чем кажется. Ведь тюльпаны любят воду, свежий воздух и солнечный свет. А кактусы, как оказалось, интроверты.

Разговоры с тюльпанами доступны через Google Home и Google Assistant.

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

Акт коммуникации в действии:
Тюльпан предполагает, что они с пользователем могут быть родственниками

Google Ложка

Японское подразделение Google вновь отличилось и представило новый инструмент для набора текста — гнущаяся ложка. Выбор той или иной буквы зависит от силы наклона ложки. Подробнее смотрите в демонстрации ниже.

P. S. Она ещё и мысли читает, если подключить соответствующую гарнитуру.

Google Files — теперь чистит ваш телефон и изнутри, и снаружи

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

Наверное. Когда-нибудь.

Tinder

Сервис знакомств выпустил новую функцию — верификация по росту. Теперь парней с ростом 6 футов (183 см) станет меньше. Компания акцентировала внимание именно на 6 футах, так как большинство американских парней ставят именно такой рост. Ожидается, что около 80 % пользователей с мужским профилем добровольно-принудительно уменьшат свой виртуальный рост до реального.

Система верификации в действии

Nintendo

Nintendo изменила внешний вид Kirby. Как говорят некоторые пользователи Reddit, сегодня это Squirby (square + Kirby).

А qbby (он же BoxBoy!) в ответ на это округлился:

PornHub

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

Краткий перевод содержания:

Beterade — первый изотонический напиток, помогающий мужчинам и женщинам восстановить баланс жидкостей в организме… абсолютно ВСЕХ… после любой физической активности: от игры в карманный хоккей до драки с вашим спарринг-партнёром.Напиток обладает тремя незабываемыми вкусами: фонтанирующая папайя, разрывной банан и ореховый взрыв.

T-Mobile

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

Более того, для любителей мобильности представили уменьшенную версию BoothE. Уверяют, что работает не хуже стационарной, но выглядит довольно странно:

Билайн сегодня Бузлайн

Компания решила сделать однодневный ребрендинг и переименоваться в «Бузлайн», более того, один из тарифов также получил название в честь Ольги Бузовой — «Бузлим».

Ребята с 4PDA подготовили небольшое погружение в возможное будущее

Сайт получил новый дизайн, который, вероятно, отражает возможный сценарий развития Рунета в связи с введением закона о суверенном Интернете.

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

KDE

Функция не новая, но судя по официальному твиту, обновлённая (ещё в 2017-м) и всё ещё увлекает котов. Встречайте, Bouncy Ball!

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

Построение модели

Калькулятор построен на данных, полученных из результатов ежегодного исследования. Благодаря большому количеству ответов разработчиков этого года список стран был расширен. Теперь модель охватывает Австралию, Бразилию, Индию, Испанию, Нидерланды, Польшу, Россию и Швецию.

Разделение разработчиков по областям производили с учётом образования, опыта работы и их роли в проектах. Знание различных технологий сильно повлияло на уровни зарплат. Согласно данным исследователей, языки Go, Scala, хранилище Redis и библиотека React ассоциировались с высокими денежными ставками, а PHP — с низкими. В то же время повсеместно используемые технологии, например, JavaScript, на изменение уровня зарплаты влияли незначительно.

Второй год подряд для прогнозирования зарплат была выбрана множественная линейная регрессия с регуляризацией для более точного выбора переменных. Зарплаты моделировались по логарифмической шкале, потому что их распределение логарифмически-нормальное. Применение предсказательного интервала в 50 % говорит о том, что половина людей с похожими вводными данными получает отображаемую зарплату. В итоге были построены 2 модели: в первой оказались страны с высокими доходами, во второй — с низкими.

Результаты исследований

Согласно данным исследования, разработчики стали в среднем получать больше, а в таких городах, как Лондон и Сан-Франциско, зарплаты выросли на четверть по сравнению с прошлым годом. При этом, в разных городах одной страны зарплаты могут отличаться на 20 %.

Примечателен тот факт, что для США, Франции, Германии и Канады средний уровень зарплат по стране отличается от среднего уровня оплаты труда в отдельных городах. На графике показан разрыв между Сан-Франциско, Сиэтлом, Нью-Йорком и другими городами Соединённых Штатов:

Согласно результатам исследования, самыми оплачиваемыми специалистами являются DevOps-инженеры.

Stack Overflow не только является одним из самых популярных ресурсов для обсуждения вопросов программирования, но и создаёт проекты для развития отрасли. Так, в начале мая 2018 года вышел сервис, позволяющий обсуждать вопросы внутри команд. Среди нововведений — интеграция ответов команды в общую базу вопросов сервиса.

JavaScript и Python

Наиболее востребованы JavaScript и Python, также растет интерес к Go и Rust, говорит Спольски. Он объяснил популярность JS доступностью: язык повсеместно использовался в браузерах и многие могли легко начать экспериментировать с ним. В серверной разработке JavaScript стал популярен благодаря Node.js, отмечает бизнесмен. Востребованность Python Спольски объяснил удобством его использования в сфере машинного обучения и работы с большими объемами данных.

Си и C++

По словам предпринимателя, Си и C++ сейчас используются в основном в «специфических» областях и при работе со старым кодом.

Я большой поклонник Си, но считаю, что никто не должен создавать продукты с помощью Си. Даже сторонники описывают его как язык программирования «без ремня безопасности».

По мнению основателя Stack Overflow, менее востребованными становятся Java и Visual Basic.

Stack Overflow

Джоэл Спольски назвал собственную платформу кучей «украденных идей», но очень успешной. Например, идею тегов он увидел на Flickr, а систему оценки ответов — на Reddit. Популярность системы бизнесмен объяснил повсеместным использованием программирования.

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

В мае 2018 года Stack Overflow выпустила сервис для обсуждения вопросов внутри команд. Тогда же платформа изменила систему тегов и добавила продвинутую интеграцию со Slack.

Ключевые особенности

Важным нововведением является интеграция ответов команды в общую базу вопросов сервиса. Если участник команды будет искать ответ, который уже дали ранее в его команде, то в поисковой выдаче этот результат будет приоритетнее:

Также среди полезных функций:

• неограниченное количество вопросов и ответов;
• измененная система тегов;
• продвинутая интеграция со Slack, а также использование командных функций во всем Stack Overflow.

Как начать пользоваться?

Проект уже доступен всем командам от 5 до 500 человек по подписке: новым пользователям предлагается бесплатный пробный период на 14 дней, после — по 10 $ в месяц за первую десятку участников и по 5 $ за дополнительных членов команды.

Stack Overflow также известен своими ежегодными опросами разработчиков о разных аспектах их профессиональной деятельности. Напомним, в 2018 году ко всем прочим пунктам были добавлены отношение к ИИ и сексуальная ориентация.

Восьмой ежегодный опрос собрал рекордное количество респондентов — анкеты в течение получаса заполняли более 100 тыс. разработчиков. Для сравнения, в 2017 году опрос прошли 64 тысячи человек.

Содержание

• Краткий обзор
• Разработчики:Опыт и специальностьОбразованиеДемографияЛичная жизнь
• Технологии:«Люблю, ненавижу, хочу»Среды разработки и инструментыИскусственный интеллект
• Работа:КомпанииЭтикаПоиски работыРабочие практикиЗаработная плата

Краткий обзор

Команда Stack Overflow выделила основные инсайты восьмого ежегодного опроса.

• DevOps и машинное обучение — главные тренды разработки. Языки и фреймворки, связанные с ними, переживают подъем, и разработчики по этим направлениям получают самые высокие зарплаты.
• Лишь крошечная часть разработчиков отметила, что не принимает во внимание этические вопросы или что не обязана их рассматривать. Хотя специалисты видят множество подобных проблем, они не знают, кто должен их обозначать, решать и принимать на себя ответственность.
• В целом, разработчики оптимистичны относительно возможностей искусственного интеллекта, однако не достигли согласия в том, какая именно угроза в нем таится.
• Рейтинг Python поднялся, обогнав С#.
• Оценивая ожидания от работы, разработчики разного пола отдали предпочтение разным вещам. Женщины поставили в приоритет корпоративную культуру и условия для профессионального роста, а мужчины — размер оплаты труда и возможность поработать со специфическими технологиями.

Разработчики

Команда Stack Overflow представила данные о географии опроса в наглядной карте. Больше всего респондентов собралось в США (20,6 %) и Индии (13,9 %). Разработчиков из России 2,9 %, но в масштабах опроса это примерно 2900 человек.

Кроме того, российских специалистов можно назвать самыми молодыми. Средний возраст разработчика в стране — 24,7 лет с опытом 7,6 лет. Самые «опытные» и «взрослые» программисты живут в Австралии, США и Соединенном Королевстве.

В целом, три четверти профессионалов, прошедших опрос, младше 35 лет.

Опыт и специальность

Почти 60 % респондентов отметились как специалисты бэкенда, и около 20 % заняты в мобильной разработке. В среднем разработчики отмечали по две специальности, но самой популярной комбинацией оказалась тройка: бэкенд-, фронтенд- и full-stack-разработка.

Почти половина всех профессиональных разработчиков вкладываются в Open Source проекты, но опрос показал сильную зависимость от языка. Среди разработчиков Rust, Julia и Clojure в проектах с открытым исходным кодом заняты 70 %, тогда как из специалистов по VBA, VB.NET и C# таких всего 40 %.

Диапазон уровней опыта в индустрии очень широк, но добрая треть специалистов получила профессию в течение последних пяти лет. По годам практики всех опережают разработчики Cobol и Perl, а замыкают топ специалисты по Matlab, Haskell и Kotlin. Если отсортировать данные по сферам деятельности, вершину рейтинга займут управленцы, специалисты DevOps и создатели настольных приложений.

Образование

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

Почти 90 % респондентов обучались новому языку или фреймворку сами, вне образовательной программы. Из них около половины проходит онлайн-курсы на MOOC-платформах, а четверть участвовала в хакатоне. Интересное наблюдение: 76 % респондентов отметили, что участвуют в хакатонах ради удовольствия, и только 19 % — ради награды.

Чтобы оставаться востребованным, разработчик обязан учиться всю жизнь. В исследовании HackerRank разработчики назвали самой популярной обучающей платформой Stack Overflow, а опрос на самой Stack Overflow отдал лидерство официальной документации.

Демография

Как и прежде, в индустрии велик гендерный разрыв: 6,8 % женщин конкурируют с 92,7 % мужчин. Еще 0,9 % (580 человек) приходится на нон-бинарную категорию и 0,7 % (451 человек) — на трансгендеров. Кроме того, Stack Overflow впервые поинтересовался у респондентов сексуальной ориентацией:

Если рассматривать представление мужчин и женщин в разных ролях, то подавляющее большинство во всех составляет сильный пол, меняется только соотношение. Среди преподавателей и исследователей мужчины встречаются в 10 раз чаще, в рядах сисадминов и DevOps-специалистов — в 25–30 раз. Самое большое представление женского пола отмечено среди академиков, QA-инженеров, специалистов по большим данным и дизайнеров. Полную картину отражает график, где вертикальная ось отвечает за относительное соотношение (1 к 10 – 1 к 25), а пунктирная линия — это среднее соотношение мужского и женского представления.

Личная жизнь

Stack Overflow также задавал вопросы о здоровье. Наличие психологических проблем отметили 11,5 тысяч респондентов, физиологических — только 1,7 тысяч.

Кроме того, в этом году опрос выяснял, есть ли у разработчиков кто-то, о ком они должны заботиться — дети или недееспособные родственники. Утвердительно ответила четверть респондентов, но причина может быть в возрасте: почти 60 % разработчиков, у которых за плечами десяток лет профессионального опыта, отметили наличие детей или родственников на обеспечении. Их младшие коллеги, возможно, пока не успели обзавестись семьей и обязанностями.

Разработчики считаются ночными и вечно голодными созданиями, однако опрос создал совершенно иную картину.

Большинство программистов просыпается до 8 часов утра, не пропускает из-за работы приемы пищи и с разной регулярностью все же занимается спортом. Только 37,4 % отметили, что обычно не делают никаких физических упражнений.

Респонденты опроса — профессиональные разработчики, студенты и просто любители, и больше половины из них проводят за компьютером от 9 до 12 часов. При этом 40 % тратят на активность вне дома всего 1–2 часа, а то и меньше.

Технологии

Шестой год подряд JavaScript занимает первую строку в рейтинге языков программирования. Python оставил позади C# так же, как обогнал в прошлом году PHP, и претендует на звание самого быстрорастущего языка.

При этом самые высокие зарплаты получают разработчики F#, Ocaml, Clojure и Groovy — их оклад, в среднем, превышает 70 тысяч долларов в год. За ними идут Perl, Rust и Erlang:

Рейтинг технологий по-прежнему возглавляют Node.js и AngularJS, а MySQL и SQL Server лидируют в списке самых популярных баз данных.

В отношении платформ разработчики отдают предпочтение Linux, Windows (Desktop или Server) и Android.

«Люблю, ненавижу, хочу»

Stack Overflow посвятила целый подраздел вопросам о самых любимых, самых ненавистных и самых желанных языках, средах разработки и инструментах. От года к году лидеры редко меняются. К примеру, третий год подряд Rust возглавляет список самых любимых языков программирования. А вот второе место занял Kotlin, впервые появившийся в опросе.

Вершину «ужасного» топа в третий раз занимает Visual Basic 6 – это значит, что высокий процент разработчиков, использующих его сейчас, не хотят продолжать с ним работать. Python второй год держится в лидерах списка языков, которые специалисты хотели бы выучить.

Такие же рейтинги составлены для фреймворков, библиотек и инструментов:

Для баз данных:

И платформ:

Полные списки можно посмотреть в разделе Most Loved, Dreaded, and Wanted.

Среды разработки и инструменты

Visual Studio Code недавно отделился от Visual Studio, став наиболее популярным инструментом среды разработки по мнению всех респондентов. Однако при сортировке по типу разработки выявляются другие лидеры. Специалисты, работающие с мобильными приложениями, чаще выбирают Android Studio и Xcode. Системные администраторы и специалисты DevOps предпочитают Vim, а у специалистов по большим данным в фаворитах IPython/Jupyter, PyCharm и RStudio.

Как правило, совместно используемые технологии группируются в смежных экосистемах. В графике большую центральную группу формируют языки веб-разработки (JavaScript, HTML и CSS), соединенные через SQL с технологиями Microsoft (C#, Visual Studio и .NET Core):

Stack Overflow поинтересовался операционной системой, которой разработчики пользуются большую часть времени. Половина специалистов указала Windows (49,9 %), остальные примерно поровну распределились между MacOS (26,7 %) и Linux (23,2 %).

Для 65 % разработчиков одного монитора маловато: половина из них использует как минимум два.

Искусственный интеллект

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

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

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

Уровень беспокойства зависит от типа разработки. К примеру, специалист по большим данным в 1,5 раза чаще рассматривает проблемы, связанные с алгоритмами, чем вероятность сингулярности. На этот вопрос можно было дать ответ в свободной форме, и разработчики, усомнившись в сценарии «Скайнета», обсудили проблему отслеживания путей, которыми алгоритм принимает решения, и опасность использования искусственного интеллекта без возможности проверить и аргументировать их.

Работа

В начале опроса 80 % респондентов пометили программирование как хобби, однако выяснилось, что 74 % заняты полный рабочий день:

Компания

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

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

Больше всего респондентов опроса (23,8 %) собралось в средних предприятиях, насчитывающих от 20 до 99 сотрудников. На втором месте (19,6 %) более крупные компании с количеством сотрудников от 100 до 499, а на третьем (13,6 %) — гиганты, на которых работает больше 10 тысяч людей.

Спектр карьерных целей разработчиков на пять лет вперед фокусируется на технической работе, и только часть респондентов отметила, что хотела бы занимать ту же должность и заниматься той же работой. Около четверти мечтают о собственном деле, однако такая тенденция заметна среди разработчиков младше 25 лет.

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

Удовлетворение работой значительно ниже у разработчиков, занятых в сфере финансовых сервисов и ИТ, а максимальное зафиксировано у специалистов 35–44 лет.

Этика

В гипотетической ситуации, когда требуется написать код, который будет использован в неэтичных целях, 58,5 % респондентов заявили, что откажутся от работы. 36,6 % разработчиков отметили вариант «зависит от проблемы» и только 4,8 % ответили согласием.

Вопрос о том, что делать после возникновения проблемы, еще более сложный. Поднимут ли разработчики этическую проблему, и если да, то как?

Согласно результатам опроса, наибольшую ответственность за возникшую проблему должен взять на себя руководящий состав.

80 % респондентов уверены, что разработчики обязаны рассматривать свою деятельность с этической стороны. Среди тех, кто ответил, что не знает или не думал об этом, 40 % заявили раньше, что не обязаны заявлять об этических проблемах.

Поиски работы

Только 16 % разработчиков активно ищут работу, однако три четверти специалистов при этом отметили, что открыты для предложений.

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

Около половины разработчиков сменили работу меньше, чем два года назад:

Интересный вопрос команда Stack Overflow задала о том, какие эмоции связаны у разработчиков с ключевыми для поиска работы словами. Оказалось, что «работа», «собеседование» и «рекрутер» вызывают раздражение, а «собеседование», «работа» и «компания» звучат изматывающе. В то же время с интересом и восторгом у разработчиков ассоциируются «новый», «компания» и «возможность».

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

Разработчики всех полов отдают наибольшее предпочтение четырем пунктам:

• Компенсации и пособия
• Технологии: языки, фреймворки и другие инструменты
• Возможности для профессиональной разработки
• Офисная среда и корпоративная культура

Однако женщины и представители других полов ставят культуру компании на первое место, а мужчины — на четвертое, выдвигая вперед компенсации и пособия.

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

Рабочие практики

Для поддержания продуктивной работы программисты, в основном, выбирают эргономичные клавиатуры и мыши (52,2 %) и столы для стоячей работы (50,4 %). Менее популярны (22,4 %) подставки для запястий, а завершают рейтинг (12,4 %) расслабляющие коврики.

Разработчики также поделились своими практиками ведения проектов. Безусловно лидирует Agile:

А для контроля версий чаще всего выбирают Git:

Интересную зависимость показали вопросы о проверке кода. Больше половины разработчиков проверяют его несколько раз в день:

Затем команда Stack Overflow проследила корреляцию этого ответа с показателем удовлетворенности работой, и оказалось, что выше всего, на 5,14 балла из 7, ее оценивают перестраховщики:

Заработная плата

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

Предсказуемо, что у более опытных разработчиков зарплата выше. Однако команда Stack Overflow разглядела в данных зависимость оплаты труда от типа разработки при одинаковом уровне опыта:

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

В каких регионах удалённая работа наиболее распространена?

На этой карте показаны страны, где участие в опросе 2017 года приняло как минимум 100 человек. В США 11.2% респондентов ответили, что они работают удалённо на полную ставку, однако это число колеблется между гораздо меньшими значениями в Западной Европе (3.93% в Швеции и 3.47% в Бельгии) и большими значениями в Центральной Азии, Восточной Европе и России (20.5% в России). Местные экономические факторы, а также ожидания сотрудников от места работы играют роль в этих повсеместных различиях.

Размер компании, в которой работают разработчики, также сильно влияет на вероятность удалённой работы.

В Stack Overflow работает около 250 человек. Ранее в блоге компании рассказывалось о том, как они делают эффективные команды из офисных работников и удалёнщиков. Результаты опросов показывают, что разработчики из небольших компаний (даже меньше Stack Overflow) с большей вероятностью работают удалённо, в то время как в больших компаниях такая вероятность ниже.

Вполне логично, что компании поменьше поддерживают удалённую работу. Как правило, такие компании зачастую только образовались, не имеют своего офиса, и разработчики, которые формируют компанию, работают, откуда им удобно. После применения прогнозного моделирования на данных опроса (предсказывает, работает ли разработчик удалённо или нет) выяснилось, что размер компании был самым значительным показателем, позволяющим делать прогноз.

Что можно сказать о самих разработчиках?

Есть большая разница в общем уровне опыта удалённых и офисных разработчиков. В большинстве стран разработчики, которые работают удалённо, имеют больше опыта профессионального программирования, чем те, кто работают в офисах. Числа действительно большие — в среднем, 5-летняя разница в опыте удалённых и офисных работников в Соединённых Штатах и Канаде. Несложно понять, почему компании с большей вероятностью поддерживают удалёнщиков, у которых есть проверенный послужной список.

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

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

В целом разработчики вполне довольны своей карьерой, 74.5% респондентов оценили свою степень удовлетворённости 7 или более баллами по 10-балльной шкале. Определенные характеристики разработчиков, в том числе удалённая работа, связаны с ещё большей удовлетворённостью карьерой.

Разница небольшая (никто не доволен на 100%, вне зависимости от того, работает он удалённо или в офисе), но как разница из-за удалённой работы, так и разница из-за внесения вклада в open source, являются статистически значимыми.

Как и в предыдущие годы, анонимные результаты опроса будут выложены в открытый доступ под лицензией Open Database License. Некоторые ответы, способные нарушить анонимность набора данных, исключаются из общего доступа. Соответствующие вопросы помечены сообщением «This information will be kept private».

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

Пройти опрос

Жизненный цикл фреймворка

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

В соответствии с этой концепцией и с помощью инструмента Stack Overflow Trends исследователями был выделен ряд UI-фреймворков, оказавших наибольшее влияние на круг фронтенд-разработчиков:

• Angular;
• React;
• Vue.js;
• Backbone;
• Knockout;
• Ember.

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

Визуализированные результаты анализа позволяют условно выделить две основные фазы, на которые разбивается использование фреймворка: быстрый подъем на волне роста популярности и более медленный, но стабильный спад — это разработчики начинают пробовать новые технологии. Такие циклы длятся от силы два года. В 2011 году начался период освоения нескольких конкурирующих фреймворков: Backbone, Knockout, и Ember. Количество связанных с ними вопросов росло примерно до 2013 года, после чего началось стабильное медленное угасание. Где-то в это же время начался подъем популярности AngularJS.

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

Наиболее резкие взлёты

Чтобы определить наибольший рост популярности, взглянем на ежегодное изменение популярности тегов в задаваемых вопросах на Stack Overflow. У каких тегов самый высокий процент изменения за время существования сайта?

Анализ выше основан по меньшей мере на 10 000 вопросах и исключает теги, которые заканчиваются числами (iOS8).

В этом анализе выделяются два тега, у которых есть что-то общее, причём у обоих наблюдается стремительный рост. Swift — язык программирования от компании Apple, используемый для разработки приложений под iOS, преемник Objective-C. Тег Angular использовался для новых версий чаще, чем AngularJS. Обе технологии росли невероятно быстро не только в плане популярности, но и в плане влияния, поскольку они были естественными новыми этапами в жизни существующих сообществ разработчиков. Обратите внимание, что AngularJS также невероятно быстро стал популярным, хотя и занимает 10-е место в рейтинге ежегодного роста на Stack Overflow.

Другие технологии, представленные на диаграмме выше, демонстрируют сравнительно скромный рост в ежегодной статистике:

• Android Studio — IDE, предназначенная для разработчиков приложений для мобильных устройств. Впервые эта интегрированная среда разработки была выпущена в 2013 году и сразу же стала популярной.
• Angularjs-directive очевидным образом связан со стремительным ростом фреймворка Angular.
• iPad был анонсирован компанией Apple в 2010 году.
• TensorFlow — библиотека машинного обучения, исходный код которой Google открыла в 2015 году. Из диаграммы выше видно, какой заметный успех обрела новая технология.

Наиболее резкие падения

Посмотрим на другую сторону медали. У каких тегов наблюдается наибольший процент снижения популярности за период существования сайта?

Этот график, как и предыдущий, основан по меньшей мере на 10 000 вопросах, исключающих теги, оканчивающиеся числовыми значениями вроде iOS4 и Xcode6.

Давайте рассмотрим конкретные примеры:

• Backbone.js — JavaScript-фреймворк с жёстким жизненным циклом для этой экосистемы. Успешно потерял популярность.
• Cocos2d, игровой движок для iPhone, утратил доверие.
• Схожая с Adobe Flash программа Silverlight от Microsoft довольно быстро устарела, собственно, как и Adobe Flash c фреймворком Flex. Обе технологии были включены в августовский пост о сокращении популярности.
• Тег Object-Relational Mapping имеет более высокий уровень активности после падения, чем другие теги, но значительно более низкий, чем примерно десять лет назад.
• Parse — довольно интересный пример. Это платформа для разработчиков бэкенда мобильных приложений, которую приобрела компания Facebook в 2013 году. В 2016 разработку и поддержку платформы свернули. Всё это время Parse была платформой с открытым исходным кодом. Иногда она используется как противопоставление Swift по параметрам популярности — Parse была новой и популярной технологией, но разработчики объявили об окончании разработки.

Устойчивый рост

Технологии могут демонстрировать как резкое падение (те, которые мы рассмотрели выше), так и устойчивый рост. Какие стеки демонстрируют наиболее устойчивый рост с 2010 года, судя по вопросам по меньшей мере за пять лет? Давайте посмотрим на средний ежегодный показатель роста популярности тегов, предварительно проанализировав не менее 10 000 вопросов, и найдём технологии, популярность которых росла на протяжении многих лет, причём не только из-за взрывного старта.

В статистике выше видно, что первые позиции занимает тег Angular и некоторые другие члены экосистемы JavaScript, такие как TypeScript и Meteor. Довольно популярны также технологии из области анализа данных и машинного обучения — Pandas и dataframe. Другие технологии — вездесущая поисковая система Elasticsearch и игровой движок Unity — занимают уникальные позиции в индустрии программного обеспечения. Они совсем разные, но все росли стабильно в течение последних 5-10 лет. На странице Stack Overflow Trends можно посмотреть на популярность инструментов, а также на динамику их роста по тегу.

Компания Stack Overflow в сотрудничестве с Microsoft и их платформой Cognitive Services разработала бота, использюущего наработки Microsoft в области ИИ. Данный бот представляет собой расширение для Visual Studio Code и позволяет разработчикам находить ответы на вопросы без переключения между средой разработки и веб-браузером, тем самым повышая производительность.

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

Представители Stack Overflow в своём блоге отметили:

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

Также есть возможность сравнить свою зарплату с окладами в тех городах, где трудоустроено большинство разработчиков. Место работы чаще всего является важнейшим фактором определения суммы получаемой заработной платы. В дополнение к месту проживания, калькулятор также попросит указать уровень образования, количество лет опыта разработки, сферу деятельности (веб-разработка, мобильная разработка и т.п.) и технологии, которыми вы уверенно владеете.

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

Все аналитические данные были собраны в период с января по август 2017 года по 250 тегам, которые получили наибольшее количество трафика за этот период. Чтобы избавиться от шумов, были выбраны 64 страны, из которых вопросы посещались более 5 миллионов раз за этот период. Стоит отметить, что эти данные представляют собой активность среди разработчиков, понимающих английский язык.

Корреляция языков программирования с ВВП на душу населения

Как было сказано выше, трафик, связанный с Android-разработкой (в процентном соотношении с общим количеством запросов), отрицательно коррелирует с ВВП страны на душу населения. Но справедливо ли это утверждение для других популярных тегов?

Если посмотреть на другие популярные языки программирования и выделить PHP, Python и R, то картина будет выглядеть следующим образом:

Как видно, трафик по тегам «Android» и «PHP» отрицательно коррелирует с доходом страны, а по «Python» и «R» — положительно. В каждом из случаев можно увидеть исключения (в Корее более популярна ОС Android, а в Китае больше используют Python), но в целом корреляция присутствует.

Вероятно, на выбор языка программирования влияет сочетание экономических и социальных факторов (например, уровень образования, возраст индустрии программного обеспечения, уровень аутсорсинга), которое в целом соотносится с богатством страны.

Как сегментировать отрасль разработки ПО?

Лучше всего уйти от корреляций и обратить внимание на то, что существует только два типа стран: с высоким и не высоким уровнем дохода. Для разделения стран можно использовать классификацию доходов Всемирного банка, которая основана на ВНП (валовой национальный продукт) на душу населения.

В мире всего 78 стран с высоким уровнем дохода — это США, Канада, страны Западной Европы, часть Ближнего Востока и Восточной Азии, Австралия и Новая Зеландия. Такое разделение более оправдано, чем, например, разделение на Восточное и Западное полушарие. Ведь Австралия, как правило, больше похожа на США и Европу с точки зрения используемых технологий, чем на Китай или Индонезию.

Согласно статистике Stack Overflow, 63,7% трафика поступает из стран с высоким уровнем дохода. Вероятно, это связано с удобным доступом в Интернет, большей долей разработчиков и лучшим знанием английского языка. Большая часть трафика из стран с невысоким уровнем дохода поступает из Индии, Бразилии, России и Китая.

Чем отличаются страны с высоким уровнем дохода?

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

Здесь можно выделить несколько моментов:

• Научные исследования. Как было отмечено выше, языки программирования Python и R наиболее популярны в странах с высоким уровнем дохода. Тег «Python» жители стран с высоким уровнем дохода посещают примерно в 2 раза чаще, а тег «R» — примерно в 3 раза. Стоит отметить, что часть тегов, связанных с Python и R, относятся к научным пакетам pandas, numpy, matplotlib и ggplot2. Это говорит о том, что эти два языка программирования могут быть связаны с наукой и академическими исследованиями. Поэтому можно предположить, что использование этих языков более распространено в развитых странах, где научные исследования составляют большую часть экономики, а программисты имеют высокие научные степени.
• C/C++. «C» и «C++» — другие популярные в странах с высоким уровнем дохода теги. Одна из гипотез заключается в том, что это может иметь отношение к образованию — C и C ++ относятся к числу языков, которые используются в университетах. Это также может быть связано с географическим распределением электроники и промышленности.
• PHP и Android. Как было отмечено выше, вопросы, связанные с Android-разработкой, больше интересуют посетителей из стран с низким уровнем дохода. Тег «PHP» также популярен в странах с невысоким доходом, как и тег «CodeIgniter» (PHP-фреймворк с открытым исходным кодом). Исследования показывают, что этот тег получает подавляющее количество трафика из Южной и Юго-Восточной Азии (в частности, из Индии, Индонезии, Пакистана и Филиппин). Возможно, CodeIgniter — это наиболее популярный инструмент среди аутсорсинговых компаний, занимающихся веб-разработкой.

Заключение

Если создать список самых посещаемых технологий программирования для стран с высокими и низкими доходами, он будет выглядеть примерно так:

Видно, что в 2017 году «Python» является вторым по популярности тегом среди стран с высоким уровнем дохода, но восьмым в остальном мире. Что же касается языка программирования R, он является 15-м по популярности в странах с высоким уровнем дохода, но даже не попал в топ-50 самых популярных тегов в остальном мире.

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

Почему не получается выйти?

Причины обычно две: человек попадает в Vim неожиданно для себя (его туда забрасывает консоль или стороннее приложение) и / или он заходит туда настолько редко, что каждый раз забывает, как закрыть программу. У нас есть простая и понятная шпаргалка по Vim для «потеряшек» с заветным ответом.

Сколько людей попадает в ловушку?

За последний год вопрос набрал около 0,005% от общего трафика = 1 из 20 000 посещений = по будням в самое активное рабочее время около 80 человек в час ищут, как выбраться из редактора. В течение 5 лет с момента публикации появлялось все больше уставших от безвыходного положения:

А вот так распределяется количество запросов по странам:

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

Какие программисты чаще всего застревают?

Самый интересный вопрос — какова корреляция между тем, какой язык использует разработчик, и тем, как часто у него возникают проблемы с выходом из Vim? Исследователи посмотрели, какие теги активно посещают застрявшие пользователи. Оказалось, больше всего страдают мобильные, фронтенд- и C#-разработчики (привыкли использовать IDE), а меньше всего — программисты на C, C++, Python и Ruby (у них обычно нет проблем с текстовыми редакторами).

Еще раз напомним, что мы написали шпаргалку по Vim. Выход есть всегда ?

Трафик в течение дня

Для получения статистики был выбран август 2016 года (чтобы максимально исключить из выборки запросы школьников и студентов, которые могли исказить результат) и 250 самых используемых тегов. Также для каждого запроса по IP-адресу вычислили информацию о часовом поясе и с достаточно высокой точностью определили местное время.

Сайт помогает программистам выполнять свою работу, поэтому неудивительно, что трафик сильно повышается примерно с 9 до 17 часов, а в районе полудня немного падает — люди идут обедать.

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

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

Посмотрим на статистику посещений тем, касающихся четырех распространённых языков: C, Python, JavaScript и C#.

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

Тем не менее, можно заметить некоторые различия: например, разработчики на C# начинают и заканчивают работу раньше, что, скорее всего, связано с использованием языка в банках и корпорациях, а C более популярен в вечернее время суток.

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

Самые популярные языки с 9 до 17

Ранее мы видели, что одна из отличительных черт тега — это его использование во время классического рабочего дня. Из четырёх языков выше C# можно считать наиболее «офисным», а C — наименее.

Днём предпочтение отдаётся многим технологиям Microsoft — SQL Server, Excel, VBA и Internet Explorer, а также корпоративным — например, SVN и Oracle. Вне рабочего дня популярны фреймворки типа Firebase, Meteor и Express, а также графические библиотеки и Haskell — функциональный язык программирования.

Посмотрим на относительную частоту посещений тегов:

Среди самых популярных технологий на Stack Overflow (более 100 000 посещений тега в день) в рабочие часы наиболее активно используются C#, SQL, SQL Server и Excel, а в остальное время — Android, iOS, Swift, Node.JS, C++, и C.

Вот статистика обращений к тегам в зависимости от местного времени, представленная в виде анимации:

Заметьте, что технологии Microsoft (Excel, VBA, C#) первыми появляются с утра и остаются в тренде с 9 до 17, а к «поздним» тегам относятся C/C++, мобильные технологии и Haskell.

Что предпочитают «жаворонки» и «совы»

Для подавляющего большинства тегов можно отметить повышение вечерней активности в сравнении с утренней. Для подсчёта относительной посещаемости исследователи разделили трафик с 9 до 12 часов на трафик с 13 до 16 часов. Таким образом, высокий коэффициент (близкий к единице) означает, что тег использовался примерно одинаково вечером и утром, а низкий — что программисты начинают работу с ним ближе к вечеру.

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

Статистика по городам

Ранее мы сравнивали технологии, но интересно было бы посмотреть и статистику использования Stack Overflow в зависимости от местоположения. Перед вами 50 городов, которые отличились повышенным трафиком на сайте в апреле этого года. Красным цветом выделены города, наиболее активные с 9 до 17, а синим — в не рабочее время:

Рассмотрим подробнее статистику по четырём городам: Лондону, Москве, Парижу и Кесон-Сити (Филиппины):

Подробнее ознакомиться с исследованием можно в официальном блоге.

В ежегодном опросе приняли участие около 64 тысяч программистов со всего мира. Он показал наличие специалистов самого разного уровня. Сейчас благодаря онлайн-курсам и традиционным курсам по программированию начинающие тоже могут постепенно начать карьеру разработчика, пишет Stack Overflow. Лишь 7,5% опрошенных занимаются программированием более 20 лет, в то время как более 50% начали свою деятельность в этой сфере менее 5 лет назад.

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

Сфера трудоустройства

Опрос охватывает целый ряд тем, начиная от трудоустройства и заканчивая предпочтениями в разработке. Специалисты Stack Overflow выяснили, что лишь 13,1% разработчиков находятся в активном поиске работы, но возможные предложения были бы интересны 72,5% опрошенных. Возможность удалённой работы считается большим плюсом в среде разработчиков. 53,3% участников опроса признались, что их зарплата намного меньше заслуженной, а 44,9% опрошенных находят свой труд малооплачиваемым, но не критично.

Согласно опросу, самым высокооплачиваемым направлением по всему миру является работа с Clojure, «диалектом» Lisp для JVM. В США больше всего зарабатывают специалисты, знающие Go и Scala — их средняя годовая зарплата достигает $110 000.

Выбор языков программирования

Stack Overflow узнал, какие языки программирования чаще используют разработчики, а также выяснил их предпочтения. Самыми распространёнными языками по-прежнему являются JavaScript (62,5%), SQL (51,2%) и Java (39,7%). Любимым языком пользователей стал Rust, который выбрали 73,1% опрошенных, за ним идёт SmallTalk (67%) и TypeScript (64,1%). Swift переместился со второго места на четвёртое.

Самыми востребованными языками стали Python (20,8%), JavaScript (18,6%) и Go (13,5%). Среди языков, от которых хотят отказаться, находятся Visual Basic 6 (88,3 %), за ним VBA (Visual Basic for Applications) и CoffeeScript. Что касается фреймворков, самыми популярными являются React (66.9%), Node.js (62,1%) и .NET Core (60,9%). При этом Node.js возглавил список самых востребованных фреймворков этого года.

Популярные направления

Stack Overflow также проанализировал разные направления разработки. 72,6% опрошенных занимаются веб-разработкой, 28,9% создают десктопные приложения, 23% — мобильные приложения, а 14,4% опрошенных являются администраторами баз данных.

Гендерное соотношение

Значительная разница в процентном соотношении видна в вопросе пола. Опрос показал, что 88,6% разработчиков — мужчины, 7,6% — женщины, что на 2% больше, чем в прошлом году, а 2,6% опрошенных пол не указывают, либо относят себя к трансгендерам.

С подробными результатами опроса можно ознакомиться на сайте Stack Overflow.

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

К счастью, Stack Exchange (родительская компания Stack Overflow) опубликовала дамп своей базы данных, которым и воспользовался Ветцель. Он запустил сервис dev-books.com, который позволяет изучить все собранные и отсортированные им данные о книгах, когда-либо упомянутых на Stack Overflow. Сайт уже посетило более 100 000 человек.

Кроме того, Влад поделился историей создания этого сервиса. Передаём ему слово.

Рассказывает Влад Ветцель

Получение и импорт данных

Я взял данные Stack Exchange из archive.org.

С самого начала было ясно, что нельзя выложить XML-файл размером 48 ГБ в новую базу данных (PostgreSQL), используя популярные методы, такие как myxml := pg_read_file('path/to/my_file.xml'), потому что на моем сервере не было 48 ГБ ОЗУ. Поэтому я решил использовать парсер SAX.

Все значения хранились в тегах <row>, так что для парсинга я использовал скрипт на Python:

После трех дней загрузки (за это время загрузилась почти половина XML), я понял, что допустил ошибку: атрибут ParentID на самом деле должен был быть задан как ParentId.

Ждать еще неделю мне не хотелось, и я перешел с AMD E-350 (2×1.35GHz) на Intel G2020 (2×2.90GHz). Но и это не ускорило процесс.

Следующим решением стала пакетная вставка:

StringIO позволяет использовать переменную вместо файла для обработки функции copy_from, которая использует COPY. Таким образом, весь процесс импорта данных занял всего одну ночь.

После этого я занялся созданием индексов. Обычно индексы GiST медленнее, чем GIN, но они занимают меньше места. Поэтому я решил использовать GiST. На следующий день у меня был индекс объёмом 70 ГБ.

Когда я запустил пару тестовых запросов, я понял, что для их обработки нужно слишком много времени. Причина была в чтении с диска, и тут меня выручил новый SSD на 120 ГБ.

Я создал новый кластер PostgreSQL:

Затем я позаботился о том, чтобы скорректировать файл конфигурации (я использовал Manjaro OS):

Я перезагрузил конфиг и запустил PostgreSQL:

На этот раз для импорта потребовалась пара часов, но я использовал GIN. Индексы заняли 20 ГБ пространства на SSD, а выполнение простых запросов занимало меньше минуты.

Извлечение книг из базы данных

Когда мои данные, наконец, были импортированы, я начал искать сообщения, в которых упоминались книги, а затем скопировал их в отдельную SQL-таблицу:

Следующим шагом нужно было найти все гиперссылки:

Тут я понял, что StackOverflow проксирует все ссылки так: rads.stackowerflow.com/[$isbn]/

Я создал еще одну таблицу со всеми постами, содержащими ссылки:

Все номера ISBN я извлёк при помощи регулярного выражения. Я поместил теги Stack Overflow в другую таблицу через regexp_split_to_table.

Как только самые популярные теги были извлечены и подсчитаны, топ-20 книг по всем тегам почти совпадал. Поэтому я решил улучшить систему рейтинга.

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

Поскольку это была «разовая» работа, я решил использовать массивы PostgreSQL. Примерный план создания запроса:

Создание веб-приложения

Поскольку я не веб-разработчик и, конечно, не эксперт по пользовательским интерфейсам, я решил создать простое одностраничное приложение, основанное на Bootstrap.

Я создал опцию «Поиск по тегу» и извлёк самые популярные теги, чтобы сделать результаты поиска кликабельными.

Для визуализации результатов поиска я использовал столбчатую диаграмму. Сперва я попробовал Hightcharts и D3, но у них были проблемы с отзывчивостью и настройкой, поэтому я создал свою отзывчивую диаграмму на основе SVG:

Заключение

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

Обновление 25.03: Автор опубликовал полный отчёт из Google Analytics и Amazon вместе со своей историей. Слово Владу.

Как сайт приносит прибыль

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

Начальный запуск

После запуска я разместил ссылку на dev-books.com на сайтах Hacker News и Reddit, пытаясь привлечь внимание некоторых разработчиков к моему проекту.

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

В конце дня я получил сообщение от преподавателя freeCodeCamp Куинси Ларсона. Он предложил мне написать рассказ о моем проекте и о его создании, чтобы сделать его более доступным для людей.

Прорыв

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

Довольно скоро я набрал 65 очков и опубликовал свежий заголовок для Hacker News и Reddit.

На этот раз, по данным Google Analytics, было зафиксировано более 750 одновременных посетителей в течение нескольких часов подряд, а мой пост в Hacker News был в топе.

На следующий день я узнал, что у dev-books.com более 5000 репостов на Facebook.

Геолокация

На следующий день я создал отчет по геолокации в Google Analytics и выяснил, что довольно много трафика идет из Азии и Европы, в особенности из России.

Мои азиатские и европейские посетители были вынуждены ожидать заказы из США. Чтобы избежать этого ожидания, я создал партнерские аккаунты на amazon.co.uk, amazon.de и amazon.fr. Из-за этой проблемы я потерял несколько заказов.

В ту же ночь мои посетители начали получать ссылки на ближайший магазин.

Самая интересная часть

На приведенных ниже рисунках вы можете увидеть статистику Amazon.com за февраль 2017 года. Из всего европейского кластера Amazon я получил чуть больше 250 долларов. Возможно, было бы больше, если бы я сделал ссылки на основе геолокации с самого начала.

Мой заработок за февраль: $2534,40.

Доволен ли я результатом? Абсолютно.

Dev-books.com по-прежнему работает и продолжает получать заказы. За полтора месяца с момента запуска сервис принес мне более 3000 долларов.

Tproger публикует статистику по тегам за последние 7 лет: она отображает изменения трендов со временем, взлеты и падения популярности языков и платформ.

Из рейтинга можно сделать много интересных выводов. Например, что JavaScript окончательно захватил первое место в 2013 году и пока не собирается отступать. С другой стороны, также заметно, что Python стремительно набирал популярность все эти годы и в 2017 имеет все шансы обогнать JavaScript. Кроме того, мы можем сделать вывод, что PHP и разработка под Android постепенно перестают быть трендовыми вещами.

Посмотреть статистику в реальном времени можно на сайте AnalyticsOverflow.

Напомним, не так давно также был опубликован интересный анализ Stack Overflow — определены самые дружелюбные сообщества программистов.

Какие же из тегов имеют наибольшую разницу в частоте вопросов в рабочие и выходные дни? Ответ дает следующий график:

Haskell показывает необычную популярность в выходные дни, составляя 0.365% всех вопросов в сравнении с 0.21% вопросов в рабочие дни. Sharepoint же напротив, более популярен в рабочие дни: 0.0683% в выходные против 0.188% в рабочие.

Как можно заметить, низкоуровневые технологии, такие как C, C++, указатели, Ассемблер, более популярны в выходные дни, так же, как и вопросы по математике, алгоритмам, рекурсии.

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

Многие из популярных в рабочие дни технологий связаны с Microsoft: Excel, SQL Server, VBA, T-SQL.

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

Видно, что наиболее популярные теги в рабочие дни связаны с Microsoft, в то время как в выходные дни преобладает интерес к низкоуровневым языкам и новым технологиям, таким как Swift и Node.js.

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

Заметим, что теги, вроде Ruby on Rails и Scala были популярнее несколько лет назад на выходных, чем в рабочее время, но теперь ситуация поменялась.

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

И как она это сделала?

Для выявления позитивных комментариев Сара искала комментарии, содержащие следующие слова и фразы: “thank you”, “thanks”, “awesome” и “:)”. Вот BigQuery-запрос:

А вот результат:

Выяснилось, что программисты, пишущие на R и Rust, а так же веб- и iOS-разработчики являются самыми доброжелательными и счастливыми программистами.

Ну а как же негативные комментарии?

Для поиска отрицательно окрашенных комментариев использовался тот же запрос, но ключевыми словами и фразами являлись следующие: “wrong”, “horrible”, “stupid”, or “:(“. Результаты — на скриншоте ниже:

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

Не всё так плохо, как кажется

Хотя Интернет и представляется многим достаточно негостеприимным местом, на каждый отрицательный комментарий набралось почти 6 положительных ?

Что лучше использовать для сравнения enum'ов --- == или equals()?

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

Они же оба работают, верно?

Да. В документации написано:

«Допустимо использовать оператор == вместо метода equals, если доподлинно известно, что хотя бы один из них ссылается на перечислимый тип» (“It is permissible to use the == operator in place of the equals method when comparing two object references if it is known that at least one of them refers to an enum constant”).

Причина этого очень простая — каждый из объектов enum создаётся только единожды, и поэтому, если вы создадите десять переменных равных SomeEnum.RED, они все будут ссылаться на один и тот же объект (а оператор == как раз это и проверяет).

Какие есть преимущества у оператора ==?

1. Он никогда не выбросит следующее:

2. В одном из ответов приводилась цитата Джошуа Блоха (автор книги «Effective Java», видимо, и цитата оттуда) о том, что этот оператор работает быстрее, и если гарантируется уникальность каждого экземпляра класса, то стоит использовать именно его.

3. Как известно, сравнения через == проверяются на соответствия типов во время компиляции (это хорошо, поскольку поможет вовремя выявить ошибку):

4. Этот вариант короче, и сразу понятно, что происходит именно проверка равенства (то есть вариант более читаемый).

Ого, как серьёзно все подошли к вопросу! Ну теперь точно буду использовать оператор равенства.

Не спешите так. Не все единогласно за ==. Вот что пишут сторонники equals():

• Нет ни единого случая, когда переменная перечисляемого типа должна быть равна null — если вы так описываете какое-то особое состояние, то его можно просто заменить на ещё одно допустимое состояние enum'а. А значит, NPE не надо скрывать, так как это, вероятнее всего, ошибка, и чем раньше о ней станет известно, тем лучше.
• Аргумент про скорость == весьма сомнителен. Современные компиляторы, скорее всего умеют заменять equals на == самостоятельно. Если это не так (как доказали позже, это действительно не так), то это проблема Java, над которой нужно работать.
• Какой Java-программист не знает, что делает equals? Такой вариант наоборот более читаем, так как для объектов мы привыкли использовать именно метод equals. Значит, и для enum’ов нужно поступать так же, чтобы не возникало путаницы.

Звучит легко, но на деле, даже самые опытные специалисты становятся авторами «закрытых» вопросов. Ничего сложного в публикации вопросов на Stack Overflow нет, просто надо понимать, как устроено сообщество — мы подробно описывали это в недавних публикациях — мы рассказывали о наиболее важных аспектах использования Stack Overflow, необходимых каждому разработчику, и объясняли, как реагирует сообщество на «вопросы низкого качества» и что делать, если такой вопрос задали именно вы. Освоив несколько простых правил, вы без труда сможете непрерывно получать на Stack Overflow те знания, которые необходимы для решения ваших задач, не тратя лишнее время на чтение всей документации.

Проверим, насколько хорошо вы знаете, что такое Stack Overflow и как им пользоваться?