СофтХабрахабр

[Перевод] Моё разочарование в софте

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

Но в последнее время при разработке не принято думать об эффективности, простоте и совершенстве: вплоть до того, что мне становится грустно за свою карьеру и за IT-отрасль в целом. Я занимаюсь программированием уже 15 лет.

Современная архитектура использует точно рассчитанное количество материала, чтобы выполнять свою функцию и оставаться в безопасности в данных условиях. Для примера, современные автомобили работают, скажем, на 98% от того, что физически позволяет нынешняя конструкция двигателя. Все самолёты сошлись к оптимальному размеру/форме/нагрузке и в основном выглядят одинаково.

Ни у кого вроде нет возражений. Только в программном обеспечении считается нормальным, если программа работает на уровне 1% или даже 0,01% от возможной производительности. Люди даже гордятся, насколько неэффективно работает программа, типа «зачем беспокоиться, компьютеры достаточно быстрые»:

Я потратил шесть часов и переписал её на Rust, теперь она выполняется за 0,06 секунды. @tveastman: Я каждый день запускаю программу на Python, она выполняется за 1,5 секунды. Это ускорение означает, что моё время окупится через 41 год, 24 дня 🙂

Наверное, вы слышали такую мантру: «Время программиста дороже времени компьютера». Это означает, что мы тратим компьютерное время в беспрецедентных масштабах. Вы бы купили машину с расходом 100 литров на 100 километров? Как насчёт 1000 литров? С компьютерами такое происходит постоянно.
Оглянитесь вокруг: портативные компьютеры в тысячи раз мощнее тех, что привели человека на Луну. Тем не менее, каждый второй сайт не может обеспечить плавную прокрутку страницы на 60 FPS на последнем топовом MacBook Pro. Я могу комфортно играть в игры, смотреть видео 4K, но не прокручивать веб-страницы! Это нормально?

Почтовому приложению Google Inbox в браузере Chrome от той же Google, требуется 13 секунд, чтобы открыть письмо среднего размера:

Он ещё анимирует пустые белые формы вместо того, чтобы показать их содержимое, потому что это единственный способ анимировать что-то на веб-странице с приличной производительностью. Нет, не 60 FPS, а скорее «настолько быстро, насколько возможно на этой странице». С нетерпением жду, что же веб-сообщество предложит, когда дисплеи 120 Гц станут мейнстримом. Они еле справляются с 60 Гц.

Что можно делать так долго? Обновление Windows 10 занимает 30 минут. Этого времени достаточно, чтобы полностью отформатировать мой SSD-накопитель, загрузить свежий билд и установить его примерно 5 раз подряд.

Павел Фатин: Набор текста в редакторе — относительно простой процесс, поэтому даже 286 могли обеспечить довольно плавный процесс набора.

В современных текстовых редакторах задержка при наборе больше, чем в 42-летнем Emacs. Текстовые редакторы! Что может быть проще? На каждое нажатие клавиши, нужно всего лишь обновить крошечную прямоугольную область на экране, а современные текстовые редакторы не могут сделать это за 16 мс. А это много времени. МНОГО. 3D-игра заполняет экран сотнями тысяч (!!!) полигонов за те же 16 мс, а также обрабатывает ввод, пересчитывает мир и динамически загружает/выгружает ресурсы. Как так?

Мы получаем более быстрое оборудование, на котором софт с теми же функциями ворочается медленнее, чем раньше. Тенденция такова, что софт вовсе не становится быстрее и функциональнее. Никогда не задумывались, почему ваш телефон загружается от 30 до 60 секунд? Всё работает намного медленнее максимальной скорости. Здесь нет никаких физических ограничений. Почему он не может загрузиться, скажем, за одну секунду? Хочется, чтобы разработчики достигли предела, используя каждый бит для производительности. Лично мне бы такое понравилось.

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

Просто задумайтесь на секунду, насколько неприлично огромное это число. Система Android без приложений занимает почти 6 ГБ. Думаю, в основном код: ядро, драйверы. Что там, фильмы в HD-качестве? Сколько же драйверов вам нужно для телефона? Ещё какие-то ресурсы, конечно, но они не могут быть такими большими.

Сегодня у нас есть веб-страницы тяжелее, чем эта ОС! Windows 95 занимала 30 МБ. Но разве она в 133 раза лучше? Windows 10 уже 4 ГБ, то есть в 133 раза больше. Да, у нас появилась Кортана, но я сомневаюсь, что она весит 3970 МБ. Я имею в виду, функционально они практически одинаковы. Но это Windows 10, неужели Android должен быть ещё в полтора раза больше?

Эта программа рисует 30 клавиш на экране — она правда в пять раз сложнее, чем вся Windows 95? Приложение клавиатуры Google как ни в чём не бывало съедает 150 МБ. Сервисы Google Play, которыми я не пользуюсь (я не покупаю там книги, музыку или видео) — 300 МБ, которые просто сидят здесь и которые нельзя удалить. Приложение Google app, в основном, просто пакет для Google Web Search, занимает 350 МБ!

И это вообще без игр и музыки! После установки всех необходимых приложений (социальные сети, чаты, карты, такси, банки и т. д.) на телефоне остался всего 1 гигабайт для фотографий. Помните времена, когда ОС, приложения и все ваши данные помещались на дискету?

Ваша программа для заметок наверняка написана в Electron и, таким образом, поставляется с драйвером для контроллера Xbox 360, умеет показывать 3D-графику, воспроизводить аудио и фотографировать с помощью веб-камеры.

Так что Slack — это пример очень ресурсоёмкого приложения. Простой текстовый чат всегда славился скоростью и малым потреблением памяти. Добро пожаловать в 2018 год. Я имею в виду, что чат и текстовый редактор — это самые базовые вещи, они должны потреблять меньше всего ресурсов.

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

Android-телефон на 16 ГБ был прекрасен три года назад. Сегодня под Android 8.1 он еле работает, потому что каждое приложение увеличилось минимум вдвое без видимых причин. Дополнительных функций нет. Они не стали быстрее и внешний вид не изменился. Они просто… раздулись?

И это не потому, что iOS 9 намного лучше — в основном, система не изменилась. iPhone 4s вышел с iOS 5, но едва может работать под управлением iOS 9. Не волнуйтесь — вы получили захватывающие новые возможности, например… работа тех же приложений с той же скоростью! Но новое оборудование быстрее, поэтому они сделали программное обеспечение медленнее. Не знаю.

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

Приложение JavaScript может прекратить работу из-за завтрашнего обновления Chrome. @jckarter: Программу DOS можно заставить работать без изменений практически на любом компьютере, сделанном после 80-х годов.

Сегодняшние веб-страницы не будут работать в любом браузере через 10 лет (а может и раньше).

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

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

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

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

Любое веб-приложение выдаёт постоянный поток «случайных» ошибок JS, даже на совместимых браузерах.

Вся архитектура баз данных веб/SQL построена на предпосылке (даже надежде), что никто не изменит данные, пока вы смотрите на открытую веб-страницу.

Видели диалог «Какую версию сохранить?» Сегодня планка так низка, что пользователи рады даже этому вопросу. Большинство приложений для совместной работы сделали «как смогли», там масса типичных сценариев, когда они теряют данные.

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

И всё же это самая популярная серверная ОС. Linux намеренно убивает случайные процессы.

Время от времени монитор Dell нужно аппаратно перезагружать, потому что в нём есть софт. У меня каждое устройство регулярно выходит из строя так или иначе. Вам повезёт, если он обнаружит устройство, иначе что делать? AirDrop? Спецификации настолько сложны, что устройства не будут устанавливать связь друг с другом, а периодические перезагрузки — оптимальный вариант. Bluetooth?

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

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

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

Ничто не мешает сделать процесс сборки надёжным, предсказуемым и на 100% воспроизводимым. Системы сборки по своей сути ненадёжны и периодически требуют полной очистки, хотя у них есть вся информация для инвалидации. NPM уже много лет находится в состоянии «иногда работает». Просто никто не думает, что это важно.

@przemyslawdabek: Кажется, что rm-rf node_modules является неотъемлемой частью рабочего процесса в проектах Node.js/JavaScript.

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

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

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

Я держусь подальше от «ИИ», потому что хочу от компьютеров противоположного: надёжности, предсказуемости и логики. @rakhim: Когда приложение или сервис говорит «под управлением ИИ» или «на основе машинного обучения», я читаю это как «ненадёжное, непредсказуемое поведение, которое не поддаётся объяснению».

Мы засунули виртуальные машины в Linux, а затем засунули Docker в виртуальные машины, просто потому что никто не смог разобраться с бардаком, который производят большинство программ, языков и их окружений. Мы накрываем дерьмо одеялами, чтобы не убирать его. Например, «единый бинарник» остаётся ОГРОМНЫМ преимуществом Go. Нет бардака == успех.

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

Люди бездумно ставят переусложнённые «полные пакеты» для простейших проблем, не думая о последствиях. А зависимости? В конечном итоге вы получаете дерево, которое является чем-то средним между фильмом ужасов (огромное и полное конфликтов) и комедией (нет причин, по которым мы добавили сюда эти пакеты, но вот они): Из этих зависимостей растут новые.

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

Зачем беспокоиться, если всегда есть другой выход. Что ещё хуже, ни у кого нет времени остановиться и выяснить, что произошло. Перезапустить процесс. Поднять новый инстанс AWS. Написать скрипт, который будет перезапускать ваше сломанное приложение каждые 20 минут. Удалить и восстановить базу данных. Двигайся быстро, не трать время на исправление ошибок. Включить одни и те же ресурсы несколько раз: тяп-ляп — и в продакшн.

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

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

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

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

Сегодняшнее определение прогресса — или подбросить топлива:

@sahrizv: 2014 — нужно внедрить микросервисы для решения проблем с монолитами.
2016 — нужно внедрить Docker, чтобы решить проблемы с микросервисами.
2018 — нужно внедрить Kubernetes, чтобы решить проблемы с Docker.

или изобретать велосипед:

@dr_c0d3: 2000: напишите 100 строк XML, чтобы «декларативно» настроить сервлеты и EJB.
2018: напишите 100 строк YAML, чтобы «декларативно» настроить микросервисы.
В XML были хотя бы схемы…

Мы застряли, и никто нас не спасёт.
Пользователям тоже. Они выучились принимать то, что мы делаем. Мы (инженеры) говорим, что каждое приложение для Android занимает 350 МБ? Хорошо, они будут с этим жить. Мы говорим, что не можем обеспечить плавную прокрутку? Окей, они свыкнутся с телефоном, который подтормаживает. Мы говорим: «Если не работает, перезагрузитесь»? Они перезагрузятся. Ведь у них нет выбора.

Все строят одни и те же медленные, раздутые, ненадёжные продукты. Конкуренции тоже нет. Случайный скачок вперёд по качеству даёт конкурентное преимущество (iPhone/iOS против других смартфонов, Chrome против других браузеров) и заставляет всех перегруппироваться, но ненадолго.

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

Иногда на пасмурном небосводе просвечивают лучики надежды.

Работа Мартина Томпсона (LMAX Disruptor, SBE, Aeron) впечатляет, она освежающе проста и эффективна.

Редактор Xi Рафа Левиена, кажется, построен на правильных принципах.

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

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

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

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

Как инженеры, мы можем и должны, и сделаем лучше. Поэтому я хочу заявить: нынешняя ситуация — полное дерьмо. Мы должны глубоко понять, что мы делаем и почему. У нас могут быть лучшие инструменты, мы можем создавать лучшие приложения, более быстрые, предсказуемые, более надёжные, использующие меньше ресурсов (на порядки меньше!). Мы можем и должны гордиться нашей работой. Мы должны выпускать продукты надёжно, предсказуемо, с самым высоким качеством. Не просто «учитывая то, что у нас было...» — никаких оговорок!

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть