🧑🏫 Почему «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 уже хочется вникнуть, а не просто использовать.
Что ж, идешь и смотришь объяснение от Матиаса: youtu.be/ff4fgQxPaO0?t=…
Всё становится на свои места.
Ref: v8.dev/blog/cost-of-j…
А затем у тебя начинают вызывать вопрос:
React.memo, shouldComponentUpdate и кастомные компараторы.
– «А зачем в этот узел вообще текут данные, если на вход мемоизация? Может, структуру компонента и поток данных сначала пересмотреть?»
Нам надо чаще думать о потоке данных.Итого, что нам даёт понимание «BigO» и структуры данных?
Они дают надежду, что «Web Performance» не скатится в чек-лист быстрых решений, а оптимизаторы будут не только созерцать графики «Web Vitals», но и думать о «Total Blocking Time».
web.dev/tbt/
И тогда, придёт и понимание того, что «UX» не заканчивается при остановке профайлера в "Idle", путь пользователя здесь только начинается.
С этими знаниями, может, и не потеряем инженерную культуру. 🥲