Opinionated

Помните, когда мы думали, что разгадали код? Ещё в 1995 году Sun Microsystems смело провозгласила «Write Once, Run Anywhere» (WORA) сверхспособностью Java. Перемотаем на 2025 год, и мы всё ещё гонимся за той же неуловимой мечтой с React Native, Flutter и множеством фреймворков, обещающих стать «фреймворком, который покорит всех». Спойлер: мы всё ещё занимаемся отладкой повсюду. Позвольте мне быть предельно откровенным: после нескольких лет борьбы с кроссплатформенной разработкой, наблюдая, как проекты превращаются в кошмары обслуживания, и видя, как разработчики ломают голову над специфическими особенностями платформ, я пришёл к спорному выводу: WORA не просто переоценена; она принципиально ошибочна как философия....

Представьте: вы знакомите нового разработчика с проектом, и вместо того чтобы сесть за чашечкой кофе и поделиться знаниями, вы даёте ему ссылку на вики-страницу, созданную с помощью ИИ, и говорите: «Всё, что тебе нужно, там». Через шесть месяцев он всё ещё борется с теми же пробелами в знаниях, которые не может заполнить ни один, даже идеально оформленный Markdown-файл. Знакомо? Мы живём в эпоху того, что я называю Великим обманом документации — опасного мифа о том, что документация, созданная с помощью ИИ, может заменить хаотичный, человеческий и бесценный процесс обмена знаниями....

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

Начну с признания: однажды я потратил три часа на отладку сбоя при развертывании, только чтобы обнаружить, что наша чрезмерно усердная конфигурация ESLint отвергла совершенно корректный код из-за того, что кто-то имел наглость использовать оператор console.log. Три. Целых. Часа. Тогда я понял, что у нас могут быть проблемы. Не поймите меня неправильно — я не выступаю за «дикий запад» программирования, где точки с запятой являются необязательными предложениями, а отступы следуют теории хаоса....

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