Недавно я наткнулся на пост Никиты Прокопова Software disenchantment. Он заставил меня вспомнить пост Мацея Цегловски The Website Obesity Crisis и множество других статей подобного типа. Среди людей, пишущих о разработке ПО, возникает всё более широкий консенсус о том, что приложения становятся больше, медленнее и забагованнее. И это в эпоху, когда оборудование должно позволить нам писать быстрее, меньше и надёжнее. DOOM, вышедший в 1996 году, можно запустить в тесте на беременность и на сотне других неожиданных устройств. Тем временем, современные чат-приложения, работая в фоновом режиме, занимают полгигабайта ОЗУ (или больше), а иногда полностью зависают даже на самом мощном ПО.
Вышеупомянутые посты по этой теме состоят примерно на 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 на смартфоне. Возможно, именно эта строка позволяет приложению не вылетать раз в четыре года в високосный день. Даже самая маленькая вспомогательная функция в конечном итоге превращается в артефакт неочевидного организационного знания. В неё просто не стоит лезть.
Некоторые программисты хотят писать более компактные приложения. Но для рынка и для нас в этом нет никаких преимуществ.
▍ Потребительское ПО недооценивают
Распространять ПО не так уж сложно. Примерно для этого и нужен Интернет. Но продажа приложения — настоящая мука. Та же публика, которая без проблем заплатит $15 за сэндвич или билет в кино (а потом просто пожмёт плечами, если фильм не понравится), будет переполнена экзистенциальными сомнениями, если интересующее её приложение стоит один (1) доллар. Существует лишь две категории, охотно платящие за хорошее ПО: корпорации и видеогеймеры. Мы каким-то образом оказались в мире, где все ожидают, что ПО будет бесплатным.
Это ожидание разрушительным образом влияет на качество потребительских приложений. На создание приложения необходимо от 50 тысяч до полумиллиона долларов. Если вы не можете убедить людей платить «на входе», то вам придётся компенсировать затраты как-то иначе. И отсюда берутся одни из самых важных причин раздувания и торможения веб- и нативных приложений: слежение за пользователем, реклама, маркетинговые воронки, продажи продуктов партнёров, платный доступ по подписке, меры по борьбе с мерами по борьбе со всем вышеперечисленным и сотня ещё менее этичных потоков прибыли. Всё это обычно связывают с жадностью, но гораздо чаще они результат отчаяния. Одни из самых популярных веб-сайтов в Интернете едва сводят концы с концами.
Сложно переоценить мусорность и неэффективность подобных систем. Вы публикуете уникальное высококачественное приложение по цене, которую считаете справедливой. Оно день за днём получает ноль загрузок. Вы пересобираете его под модель с подпиской/бесплатной пробной версией. Она получает несколько сотен скачиваний, но лишь горстка пользователей переходит на платный тариф, и этого далеко недостаточно, чтобы покрыть ваши расходы. Вы добавляете в бесплатную версию рекламу, хотя это и разбивает сердце вашего дизайнера UI. Вы обнаруживаете, что за просмотр рекламы платят доли центов. Вы добавляете ещё рекламы. Пользователи (по-прежнему бесплатные) жалуются, что рекламы слишком много. Вы заменяете некоторые приложения на покупки внутри приложения. Пользователи и на них начинают жаловаться. Вы добавляете модальные окна, мотивирующие людей заплатить за пользование приложением без рекламы. Обнаруживаете, что большинство из них вскоре удаляет приложение. Вы добавляете аналитику и телеметрию, чтобы понять, как повысить удержание пользователей. Вы выясняете, что «удержание» и «аддикция» вполне могут быть синонимами. Цикл продолжается, и вскоре ваше приложение превращается в унылую машину по созданию прибыли, на каждом шагу эксплуатирующую внимание и конфиденциальность пользователя. А вы по-прежнему зарабатываете не так уж много.
Можно было бы избежать всего этого, если бы люди готовы были платить за приложения. Но они не готовы. Поэтому приложения огромные, медленные и забагованные.
▍ Разработчики не осознают силу, которой обладают
Чтобы никто не говорил, что я виню всех, кроме себя, давайте изучим роль разработчиков ПО. Наверняка мы можем что-то исправить.
Даже во время рецессии у разработчиков есть огромный объём власти. Мы можем настоять на том, чтобы работать (или не работать) с конкретными технологиями. Мы можем добиваться высоких зарплат, бонусов и долей в компании. Мы можем менять культуру и рабочую среду во всей компании, проявив даже минимальный уровень солидарности. Хороших программистов сложно найти. Все знают это, и мы знаем, что они знают это.
Это наша власть, и с ней мы способны на большее.
Мы должны выделять в каждом спринте время на устранение технического долга. Мы должны при каждой возможности откладывать работу над фичами, когда есть особенно многообещающая возможность оптимизации и совершенствования кода. Мы должны убеждать наших работодателей спонсировать опенсорсные проекты. Мы должны создать ожидание, что не всегда будем работать над дорожной картой продукта; наш код и наша отрасль ожидает от нас большего.
В большинстве случаев никаких отрицательных последствий не будет. Мы просим не очень многого. Во всех остальных отраслях есть профессиональные стандарты и требования, выходящие за пределы конкретного описания должности. Почему мы часто ведём себя так, как будто их нет в разработке ПО?
Единственная проблема в том, что мотивация работает не в нашу пользу. Это неравный бой. Некоторым менеджерам не понравится, что мы тратим время на вещи, которые они не понимают. Некоторые люди из отдела продаж будут волноваться, что наше ПО неконкурентоспособно. Инвесторы могут угрожать, что отдадут нашу работу на аутсорс более гибким разработчикам. Так будет происходить, пока не изменятся отношение клиентов и рыночные силы. Но если изменение состояния современного ПО — оправдывающая себя цель, это стоит усилий.
▍ Станет ли ситуация лучше?
Трудно сохранять оптимизм относительно будущего программ. В 90-х программистам разрешали создавать крошечные высокооптимизированные приложения, потому что другого выбора не было. Их клиенты работали на 32 мегабайтах ОЗУ и одноядерном процессоре с частотой 200 МГц. Если приложение не было бы максимально компактным, оно бы вообще не заработало. Сегодня базовая модель Macbook Air, выпущенная два года назад, имеет в 250 раз больше памяти (не говоря уже о том, что она быстрее) и четырёхъядерный процессор, скорость каждого ядра которого намного выше, чем у всего компьютера 90-х. Сегодня нам может сойти с рук гораздо больше. И сходит. Мы выпускаем приложения, на 90% состоящие из мёртвого груза. Мы не выполняем оптимизацию до тех пор, пока кто-нибудь не начнёт жаловаться. Мы помещаем в приложения для отправки сообщений, составления заметок и даже написания кода пакет с полнофункциональным браузером (одним из таких приложений я пользуюсь прямо сейчас).
Последние два десятка лет были посвящены тому, чтобы ускорить, упростить и защитить от ошибок разработку ПО. И мы действительно создаём приложения быстрее, с бОльшим количеством фич и задействуя менее опытных разработчиков. Несложно понять, в чём здесь заключается привлекательность с точки зрения бизнеса. Но нам приходится платить, как и нашим клиентам, энергосетям и планете.
Ничто не поменяется мгновенно и даже за пять лет. Но есть причины питать надежду.
Последняя волна языков и технологий веб-программирования (наподобие WebAssembly, ESBuild, SWC, Bun и Yew) обеспечивает новые уровни скорости и надёжности, как во время компиляции, так и в среде исполнения. В веб-серверах набирает популярность Rust, примечательный тем, что обеспечивает производительность C и удобство разработки языков более высокого уровня. Более легковесные альтернативы Electron наподобие Tauri обещают занять его место в роли кросс-платформенного фреймворка для веб-разработчика. Мы ожидаем, что в компиляторах и упаковщиках будет использоваться tree-shaking (удаление мёртвого кода).
Множество популярных видеоигр (например, Dead Cells и The Binding of Isaac) пришли на мобильные платформы в виде платных приложений. Предстоит сделать ещё многое, но это многообещающий прогресс в сторону изменения представлений пользователей смартфонов (крупнейшей в мире группы потребителей технологий) о стоимости ПО.
Если последние двадцать лет были посвящены повышению нашей продуктивности в ущерб эффективности и финансовой устойчивости процесса, то, возможно, следующие двадцать мы посвятим устранению нашего общего технического долга, возвращению эффективности и улучшения экономического обмена без снижения продуктивности, благодаря которой ПО стало неотъемлемой частью нашей жизни.
Помоги спутнику бороться с космическим мусором в нашей новой игре! 🛸
Автор:
ru_vds
