Технологии разработки развиваются, но качество приложений по-прежнему оставляет желать лучшего. Почему?
Недавно я наткнулся на пост Никиты Прокопова "Software disenchantment" (Разочарование в ПО). До этого похожие мысли я читал у Мацея Цегловского "The Website Obesity Crisis" (Кризис ожирения веб-сайтов), а также у некоторых других авторов. Люди, пишущие о разработке, всё чаще говорят о том, что приложения становятся тяжелее, медленнее и нестабильнее в эпоху, когда развитие "железа" всё менее ограничивает нас в создании быстрых, лёгких и надёжных приложений. DOOM, вышедший в 1996 [прим. пер. на самом деле в 1993] году, может работать на тесте на беременность и сотне других неожиданных устройств; в то же время приложения для чата в 2022 году используют полгигабайта оперативной памяти (или больше), работая в фоновом режиме, и иногда зависают даже на высокопроизводительном оборудовании.
Вышеупомянутые посты на эту тему выглядят примерно на 80% как справедливая критика, а на оставшиеся 20% — как неоправданное брюзжание. Или другими словами:
К счастью, большинство разработчиков догадывается не задавать тупые вопросы в духе: "Это же ОС для смартфонов, как она может быть сложной?" или "Мой редактор таблиц в 90-х весил 10 Кб, как Factorio может весить целый гигабайт?". Если вы не участвовали в создании программы, вы не можете достоверно оценить сложность разработки и подводные камни, с которыми пришлось столкнуться в процессе.
Тем не менее, это не значит, что здесь нет места объективной критике. Приложения действительно стали медленнее, чем раньше. И их размер увеличивается в геометрической прогрессии без пропорционального роста ценности. По меньшей мере, почти в любом современном приложении есть простор для оптимизации. Мы можем сделать их быстрее, возможно, на порядки. Мы можем удалить лишний код. Мы можем писать небольшие узкоспециализированные библиотеки под конкретные задачи. Мы можем найти новые способы сжатия ассетов.
Но почему мы этого не делаем?
Ответ Прокопова: "Разработчики не гордятся своей работой". В этом есть доля правды. Но я твердо убеждён, что это естественное состояние человека — упорно трудиться и создавать отличные вещи, и мы не делаем этого только тогда, когда постоянно сталкиваемся с препятствиями. Поэтому вместо того, чтобы винить "ленивых разработчиков" в глючности и ненадёжности современных приложений, нам стоит спросить: "Какие внешние силы и стимулы создают рабочую среду, в которой разработчики не могут делать свою работу наилучшим образом?"
У меня есть пара идей на этот счёт.
Скорость — это фича, надёжность — ничто
Разработчики представляют себе ПО как сеть взаимодействующих компонентов, исходных и результирующих данных. Эта модель точна и полезна. Однако с точки зрения упаковки, маркетинга и продажи картина отличается. Для бизнеса и клиентов программное обеспечение — это набор функций.
Возьмём, к примеру, приложение для управления запасами. Его маркетинговые материалы будут состоять из нескольких стоковых фотографий высокого разрешения, яркой цветовой палитры и обещаний вроде этих:
Отслеживание запасов на нескольких складах;
Интеграция с системами Delivery Pro, Supply Chain Plus и Super Point-of-Sale;
Многоуровневая еженедельная и ежемесячная отчетность;
Точная настройка доступа и безопасности;
Мгновенные обновления на всех терминалах;
Поддержка Windows, MacOS и Linux.
Это проверяемые утверждения: либо программа делает эти вещи, либо нет. Все они могут быть продемонстрированы в ходе часовой демонстрации продукта. И только одно из них касается скорости. На самом деле программа может быть очень медленной и реагировать на нажатие кнопки несколько секунд, при этом утверждение о "мгновенных обновлениях" не станет ложью.
Думаю, все согласятся с тем, что скорость работы существенно влияет на впечатления пользователя от приложения. Это важный показатель качества. Но его трудно продать. Если вы потратите время на оптимизацию ключевого процесса, пока ваш конкурент разрабатывает новый тип отчета, вы потеряете из-за этого восемь из десяти следующих продаж. Если вы спросите своих клиентов, над чем вам стоит работать дальше, они попросят о новых фичах, а не о скорости, если только программа не настолько медленная, чтобы граничить с непригодностью к использованию. И не дай бог, чтобы совет директоров позволил компании на полгода отвлечься от дорожной карты, чтобы поработать над техническим долгом. От нас постоянно требуют фичи, фичи, фичи.
Разработчики хотят писать быстрые приложения. Но рынку наплевать.
Как видите, надежность вообще не входит в этот список. Как бы вы это обозначили в маркетинговых материалах? "Без ошибок?" Нет способа гарантировать это, не говоря уже о том, чтобы доказать это в демонстрации продукта. "90% покрытия юнит-тестами и полный набор интеграционных тестов?" Клиент не знает, что это значит, а при попытке объяснить заскучает. Не существует способа рассказать о надёжности программы так, чтобы клиенты одновременно поверили и заинтересовались. Эпоха Agile приучила их к тому, что ошибки неизбежно будут, и вы будете исправлять их на ходу. А поскольку не существует исчерпывающего способа оценки дефектов ПО (если бы мы знали о них, мы бы уже их исправили, верно?), это не может служить критерием, по которому можно сравнить незнакомые продукты. Мы можем инвестировать время в тестирование, рефакторинг и улучшения, но этого, скорее всего, никто не заметит.
Разработчики хотят писать качественные приложения. Но рынку наплевать.
Использование жёсткого диска также не входит в список, хотя иногда оно упоминается мелким малоконтрастным шрифтом под кнопкой "Загрузить". И из всего списка этот пункт, пожалуй, меньше всего связан с конкурентоспособностью или качеством в сознании покупателей. Когда в последний раз вы винили разработчика (а не себя или свой компьютер) в том, что у вас закончилось место на диске? Или выбирали между двумя играми, основываясь на размере загружаемого файла? Скорее всего, никогда. Люди могут жаловаться на размер последней Call of Duty, но сиквелы всё равно собирают миллиард долларов в первую неделю после релиза.
Уменьшение размера исполняемого файла или пакета — неблагодарная работа. И зачастую это очень технически сложная работа, требующая глубокого понимания не только вашего приложения, но и сотен библиотек нижнего уровня, которые оно использует. Более того, от этой работы часто предостерегают ("Не изобретайте велосипед"), отчасти потому, что это, в некотором смысле, минное поле. Вы можете не знать, для чего нужна та или иная строка кода, но это не значит, что она бесполезна. Может быть, от неё зависит работа приложения для 0,01% ваших клиентов, использующих Ubuntu на смартфоне. Может быть, это единственное, что удерживает приложение от падения 29-го февраля в високосный год. Даже самая маленькая функция со временем превращается в артефакт неочевидного корпоративного знания. Связываться с этим просто не стоит рисков.
Некоторые разработчики хотят писать более компактные приложения. Но выгоды от этого нет ни для рынка, ни для нас.
Пользователи не ценят ПО
Распространять приложения несложно. Для этого, в общем-то, и существует интернет. Но продавать приложения — что зубы выдирать. Люди готовы заплатить 15 долларов за билет в кино или сэндвич и если он им не понравится, просто пожать плечами и пойти дальше, но они впадают в экзистенциальную тревогу, если интересующее их приложение стоит 1 (один) доллар. Есть только две группы пользователей, которые готовы платить за хорошее ПО: корпорации и геймеры. Мы каким-то образом попали в мир, где все остальные считают, что программы должны быть бесплатными.
Это представление губительно сказалось на качестве потребительских приложений. Создание приложения стоит от 50 000 до полумиллиона долларов. Если вы не можете заставить людей платить за установку, вам придётся окупать затраты каким-то другим способом. И вот основные причины раздутости и медлительности как веб-приложений, так и нативных: трекинг пользователей, реклама, маркетинговые воронки, партнёрские продажи, платные подписки, защита от обхода всего вышеперечисленного и сотня ещё более сомнительных способов заработка. Всё это часто объясняют жадностью, но чаще это результат отчаяния. Некоторые из числа самых посещаемых интернет-проектов едва сводят концы с концами.
Трудно переоценить расточительность и неэффективность подобной системы. Вы публикуете уникальное, высококачественное приложение по справедливой, на ваш взгляд, цене. День за днем счётчик загрузок остаётся на нуле. Вы переделываете его под фримиум модель. Оно набирает пару сотен загрузок, но лишь несколько пользователей переходят на платный тариф, и этого недостаточно, чтобы покрыть ваши расходы. Вы размещаете рекламу в бесплатной версии, разбивая сердце вашего дизайнера. Вы узнаёте, что просмотры рекламы оплачиваются в долях цента. Вы добавляете ещё больше рекламы. Пользователи (которые продолжают пользоваться приложением бесплатно) жалуются, что рекламы слишком много. Вы меняете часть рекламы на покупки в приложении. Пользователи жалуются и на них. Вы добавляете модальные окна, чтобы убедить пользователей заплатить за возможность пользоваться приложением без рекламы. Вы узнаёте, что большинство из них предпочтут вместо этого удалить приложение. Вы добавляете аналитику и телеметрию, чтобы понять, как повысить удержание пользователей. Вы обнаруживаете, что "удержание" и "зависимость" могут оказаться синонимами. Цикл продолжается, и вскоре у вас уже нет приложения, у вас есть безрадостная машина для получения прибыли, которая на каждом шагу эксплуатирует внимание и конфиденциальность ваших пользователей. И вы всё ещё не зарабатываете много денег.
Мы могли бы избежать всего этого, если бы люди были готовы платить за приложения. Но они не готовы. Поэтому приложения становятся тяжёлыми, медленными и глючными.
Разработчики не понимают своей силы
Чтобы меня не обвинили в том, что я возлагаю ответственность на всех, кроме себя, давайте рассмотрим роль разработчиков ПО. Должно же быть что-то, что мы можем сделать лучше.
Даже в условиях экономического спада разработчики обладают огромным количеством рычагов влияния. Мы можем настаивать на использовании (или, наоборот, отказе от) определенных технологий. Мы можем добиваться высоких зарплат, льгот и равноправия на работе. Мы можем изменить культуру и рабочую атмосферу целой компании, проявив хотя бы толику солидарности. Хороших программистов трудно найти. Все это знают, и мы знаем, что они знают.
В этом наша сила, и мы можем её использовать.
В каждом спринте мы должны выделять время на устранение технического долга. Мы должны отодвигать работу над фичами, когда появляется особенно многообещающая возможность оптимизировать и улучшить наш код. Мы должны убедить наших работодателей спонсировать проекты с открытым исходным кодом. Мы должны создать понимание, что не всегда будем работать только над дорожной картой продукта; наш код и наша индустрия требуют большего.
В большинстве случаев это не повлечёт никаких негативных последствий. Мы не просим слишком многого. В любой другой отрасли есть профессиональные стандарты и требования, которые выходят за рамки должностных инструкций. Почему же мы так часто ведем себя так, будто в разработке их нет?
Единственная оговорка заключается в том, что рыночные стимулы не в нашу пользу. Это нелёгкая битва. Некоторые руководители не захотят, чтобы мы тратили время на то, чего они не понимают. Некоторые сейлзы будут беспокоиться, что наше ПО неконкурентоспособно. Инвесторы могут пригрозить, что передадут нашу работу более сговорчивым разработчикам. Пройдёт немало времени, прежде чем отношение клиентов и рыночные силы изменятся. Но если улучшение качества ПО — это достойная цель, оно стоит усилий.
Станет ли лучше?
Трудно с оптимизмом смотреть на будущее ПО. В 90-е годы программисты могли создавать лёгкие высокооптимизированные приложения, потому что другого выбора не было. У их клиентов было 32 мегабайта оперативной памяти и 200-мегагерцовый одноядерный процессор. Если приложение не было максимально экономичным, оно не запускалось вообще. Сегодня в базовой модели Macbook Air двухлетней давности в 250 раз больше памяти (не говоря уже о её скорости) и четырёхъядерный процессор, скорость каждого ядра которого в несколько раз выше. Теперь нам сходит с рук гораздо большее. И мы этим пользуемся. Мы выпускаем приложения, которые на 90% состоят из мёртвого груза. Мы не оптимизируем, пока кто-то не пожалуется. Мы упаковываем полноценный веб-браузер в приложения для отправки сообщений, создания заметок и даже написания кода (я использую одно из них прямо сейчас).
Последние два десятилетия были посвящены тому, чтобы сделать разработку быстрее, проще и доступнее. И, по общему признанию, мы создаем приложения быстрее, чем когда-либо, с большим количеством функций, чем когда-либо, руками менее опытных разработчиков, чем когда-либо. Легко увидеть выгоду для бизнеса. Но мы платим за это немалую цену. А также наши клиенты, энергосети, и планета.
Ситуация не изменится в одночасье, возможно, даже не в ближайшие пять лет. Но есть поводы для надежды.
Последнее поколение языков и технологий веб-программирования (таких как WebAssembly, ESBuild, SWC, Bun и Yew) позволяет достичь новых уровней скорости и надёжности, как во время компиляции, так и во время выполнения. Rust, выделяющейся производительностью на уровне C и удобством более высокоуровневых языков, набирает популярность на веб-серверах. Легкие альтернативы Electron, такие как Tauri, готовы занять место приоритетного кросс-платформенного фреймворка для веб-разработчиков. Tree shaking стал типовой задачей компиляторов и бандлеров.
Что касается рынка, то несколько популярных игр (например, Dead Cells и The Binding of Isaac) вышли на мобильные платформы с моделью платной загрузки. Впереди ещё много работы, но это многообещающий шаг к тому, чтобы перевоспитать пользователей смартфонов — самой большой в мире группы потребителей технологий — в отношении стоимости ПО.
Если последние 20 лет были посвящены тому, чтобы сделать нас продуктивнее, жертвуя при этом эффективностью кода и финансовой устойчивостью, то, возможно, следующие 20 будут посвящены тому, чтобы решить проблему нашего коллективного технического долга, вернуть утраченную эффективность и улучшить экономику разработки без потери продуктивности, которая и помогла ПО проникнуть во все сферы нашей жизни.
Я веду телеграм канал с переводами актуальных новостей с Hacker News и не только. Подписывайтесь, чтобы не пропускать свежак.
Вольно переведено проектом Russian Hacker News. Оригинал статьи. Картинки взяты из упомянутой статьи The Website Obesity Crisis.
