Thread by @jsunderhood

🧑‍🏫 Почему «BigO» так важен в «Web Performance»?

В этом треде автор постарается объяснить, почему в «Web Perf» нет места хакам, а подебажить алгоритм на бумаге — это круто.

📝 Disclaimer

Автор треда — адепт старой школы и в 2k21 зачем-то учится в универе, хотя это уже не модно. Убеждён, что если у тебя нет фундаментальных знаний, то «инженером» называть себя не стоит. Примерно о том же говорит и Wikipedia в определении «Engineer».

Я не уверен, знают ли ребята без фундаментального образования, как обозначается блок модификации на блок-схеме, да и о чём он вообще.

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

Ничего?

Если ты начертился на бумаге алгоритмов, то ставь класс.

Придётся рассказать про опыт «старой школы» — мой.

Конкретно у меня было 2 преподавателя по алгоритмизации с абсолютно разными подходами.

Алгоритмизация (опыт в техникуме)

Преподаватель давал разные задачи и принимал решения любой ценой.

Это олимпиадный подход. Ты забиваешь на всё и решаешь на скорость. Лишь бы потом эту программу было не лень вбивать в Pascal.

И это хороший опыт.

Алгоритмизация (опыт в универе)

Преподаватель давал не ёмкие задачи и принимал только максимально оптимизированные решения.

И это лучший, как мне кажется, опыт!

P. S. У меня как-то не приняли лабу, потому что сложность была «N», а не «N-1».

Было забавно наблюдать за проверкой алгоритмов. Студент с алгоритмом на 10 блоков мог отлететь, а вот блок-схема на 3 листа сдавалась на «ОТЛ».

Кажется, где-то на этих занятиях я стал понимать как интерпретатор идёт по коду, процессор делает такт, а в памяти создаётся ячейка. 🤖

НО!

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

Наверное, пока ты юниор, ты все силы тратишь на то, чтобы код был читаемым, а не эффективным. 

И это нормально, нет проблем. Точите паттерны, ребята!

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

Ибо если загуглить «BigO», то одним из топ-результатов будет bigocheatsheet.com , где чётко понимаешь, что тут структур данных больше, чем ожидал. Надо гуглить.

– «Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и их отношениях» ©

Собственно, эту фразу Линус Торвальдс говорил в контексте «Git». Так что, тут говорится не об отличиях списка и массива. Повысьте градус контекста этой цитаты.

«BigO» и понимание структур данных — неотъемлемы.

Поэтому, затраты на: чтение, поиск, вставку и удаление сначала (увы, тупо) заучиваешь.

Потом, уже понимаешь «почему так?».
Затем, больше не возвращаться к шпаргалкам.

Там еще есть такой прикольный момент, когда ты сам понимаешь цену вставки:
- в начало
- в середину
- и в конец
для всех ходовых типов данных.

Потом, так же понимаешь и про «удаление». 

Рекоммендую. Прикольное чувство.

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

Со временем, у тебя появляются следующие повадки:
- Ты исследуешь алгоритм на неоптимальность;
- У тебя намётан глаз на квадратичную сложность;
- Ты чётко видишь лишнюю работу в чейне вызовов;
- Профайлер начинает кипятить Макбук;
- ???
- Ты начинаешь исследовать.

🥲

И восприятие эвристики оптимизации программы, меняются.

Нпример, помню свои мысли, когда увидел `optimize-js`: «Ого, вот это показатели!»

Сейчас, более интересным кажется раздел объяснения алгоритма: github.com/nolanlawson/op…

И вердикт: «Использовать я его, конечно, не буду».

В трюк с обёртыванием объектов в `JSON.parse` уже хочется вникнуть, а не просто использовать.

Что ж, идешь и смотришь объяснение от Матиаса:

Всё становится на свои места.

Ref: v8.dev/blog/cost-of-j…

А затем у тебя начинают вызывать вопрос: `React.memo`, `shouldComponentUpdate` и кастомные компараторы.

– «А зачем в этот узел вообще текут данные, если на вход мемоизация? Может, структуру компонента и поток данных сначала пересмотреть?»

Нам надо чаще думать о потоке данных.

Итого, что нам даёт понимание «BigO» и структуры данных?

Они дают надежду, что «Web Performance» не скатится в чек-лист быстрых решений, а оптимизаторы будут не только созерцать графики «Web Vitals», но и думать о «Total Blocking Time».

web.dev/tbt/

И тогда, придёт и понимание того, что «UX» не заканчивается при остановке профайлера в "Idle", путь пользователя здесь только начинается.

С этими знаниями, может, и не потеряем инженерную культуру. 🥲