#про_співбесіди
Просто зараз я готуюсь до вечірнього етеру зі співбесідою — підбираю теми, завдання, придумую хитрі задачки. І на думку спало швиденько поділитися з вами моєю точкою зору щодо того, як проводити співбесіди з лайвкодингом.

Саме не проходити, а проводити. Бо в цьому випадку відповідальність за вдале проходження такої сесії лежить саме на інтервʼюєрі. Чому?

Бо це дуже стресово. Навіть я не завжди блискуче справляюсь з таким завданнями з дуже простої причини: одна справа розповідати теорію чи ділитися досвідом, і зовсім інша — перемикнутись на "розробницький режим", коли дедлайн не за два тижні, а за 20 хвилин. І при цьому треба ще й коментувати усе, що ти робиш.

Так от. Найперше і найголовніше — підготуйте нескладну і очевидну задачу. Наприклад, якщо це вправа з код-ревʼю, то хай там буде дві-три, максимум пʼять суперочевидних проблем. Не варто перетворювати сесію на квест-кімнату, де помилка криється в сімнадцятій ітерації квантового алгоритма Безоса–Мікі-Мауса.

Не змушуйте мене кожному з вас писати в особисті, щоб ви поставили вподобайку і поширили цей допис

Не перебивайте. Ви можете зупинити кандидата, коли чуєте, що він у своїх роздумах уже мандрує степами Монголії. Але якщо він просто дещо по іншому висловлює свої думки — стуліть писка ненадовго. Нагадати про свою присутність можна, коли запала незручна тиша — тоді можна запропонувати підказку чи допомогу.

Не перетворюйте практичні задачі на театр одного актора у вакуумі, в якому він змушений котити свій камінь на гору в повній тиші, поки ви витріщаєтесь на нього, як Віго Карпатський зі свого портрета. Дозволяйте гуглити, питати у чата, користуватися тим же Cursor чи Copilot, питати поради у вас, врешті-решт. Неважливо, як саме зʼявився код, головне аби кандидат його розумів і міг пояснити.

І не змушуйте учасника співбесіди обовʼязково написати повністю робочий код в установлений час. Це додасть ще більще стресу, і можна взагалі зловити тупняк. Ваша задача — побачити, як кандидат мислить, як працює над рішенням, як він розбирається з вимогами і таке інше. В наш час власне сам код уже не є самоціллю, набагато важливіше, як саме до нього прийшли.

Якщо коротко — не будьте душними, будьте привітними та відкритими, і все складеться добре, як для кандидата, так і для вас.

До речі, нагадую, що сьогодні ввечері — новий прямий етер зі співбесідою на моєму ютуб-каналі, і закликаю вас усіх прийти подивитися саме стрим, а не запис. Буде дуже цікаво, це я вам обіцяю. Чекаю на усіх вас!

Заразом подивитеся, як я ігнорую власні поради, бгг.

@babichdev

До початку — рівно п'ять хвилин!

Мерщій заварюйте чай і готуйте смаколики, бо рівно о 19:00 розпочнеться прямий етер з новою співбесідою на моєму ютуб каналі!

https://youtube.com/live/bCqM9T3AbFQ

Всім привіт! Мені здається, прийшов час нам познайомитися дещо глибше.

Мене звати Сергій Бабіч, і я веброзробник.

У розробці я вже понад 14 років. За цей час працював в багатьох компаніях і на дуже різних проєктах, з різними технологіями та дуже різними людьми.

Протягом карʼєри я здобув стільки знань і досвіду, що їх стало просто неможливо утримувати в собі, тому я врешті-решт і вирішив започаткувати цей канал. Не блоґ, не інфопомийку з перепостами з інфопомийок, як ви вже помітили, а таке місце сили, через яке я можу ділитися з вами своїми знаннями, своїм досвідом, роздумами та точками зору.

Але не все тут — з мого 14-річного досвіду. Часом спеціально занурююсь у нову тему — і виходжу з неї з відкриттями, якими й ділюсь із вами.

В цьому каналі я пишу про все, що вважаю за дійсно важливе для вас: веброзробку, проведення й проходження співбесід, архітектуру, досвід з проєктів, анонси моїх і не тільки подій, та обовʼязково — про допомогу ЗСУ. І так буде й надалі.

“Але ж ти постиш і рекламу!” — скажете ви. І будете праві. Я справді публікую партнерські дописи. Але тільки ті, що мають сенс саме для вас. І відбираю я кожне оголошення вручну, зважайте.

А ще:
— Моя улюблена частина Assassin's Creed це Black Flag.
— Я з Житомира.
— На українську перейшов сам у віці 18 років далекого 2005 року. Тому не вірю в "не такі щелепи" і "мнє сложна, я живу в [рандомне_місто]". Дивіться пункт 2 ;)
— Обожнюю риболовлю.

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

А підтримати "Дивовижний світ веброзробки" можна наступним чином:
— Заохотити підписатися хоча б одного колегу, який в житті про мене не чув;
— Ставити на кожен допис як не вогник, то хоча б серденько;
— Стати патроном на BASE від monobank.

@babichdev

Коротеньке оголошення:
Цього четверга буде невелика неофіційна тусовка в "Довгих бурхливих оплесках" (Львів). Не івент, не мітап — просто хто прийде, той прийде, познайомимось, поспілкуємось, потусуємось.
Можете підходити під 19 годину, я там уже точно буду.

Чекатиму!

Товариство, тим часом нам лишилося зібрати усього 27 500 гривень у нашому зборі для 109 ОГШБ 10 ОГШБр "Едельвейс"

Давайте натиснемо разом і закриємо нарешті його.

Нагадую, що кожні 50 гривень вашого донату — це квиточок в розіграші LEGO Dune Atreides Royal Ornithopter від української продуктової IT-компанії Brainstack.

🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ

💳 Картка mono:
4441111124390562

@babichdev

#партнерський_допис
Давайте будемо відверті — від штучного інтелекту уже нікуди не сховатися. Але й не треба, на мою думку.

А що точно треба робити просто вже, то це опанувати штучний інтелект в усіх його доступних нам проявах, і, замість нити як він забере всю роботу в світі, стрімко вриватися в майбутнє цифрових технологій вже сьогодні.

Тому я запрошую вас долучитися до AI-конференція Fwdays+DevRain, що відбудеться вже 5 липня в Києві.

Серед тем, які будуть обговорюватися: погляд Microsoft та Google на генеративний AI, що буде з вашою командою завтра, книга про генеративний AI за його допомогою, чи варто інвестувати в AI в 2025 та багато іншого.

Серед спікерів будуть Тетяна Лукинюк (Google), Олександр Краковецький (DevRain), Артем Биковець (mono, Simplesense.), Олексій Мінаков (Generative AI) та інші.

Використайте промокод BABICH10 та отримайте знижку 10%

Деталі за посиланням: https://fwdays.com/event/fwdays-devrain-ai

@babichdev

Я не до кінця розібрався з useEffect. І тепер про це знає весь інтернет.

Ті з вас, хто дивились минулий етер зі співбесідою, мали бачити, як ми з Альбертом розмірковували над практичною задачею. І декому здалося, що я підштовхував його до не найкращого рішення цієї задачі. Так от, друзі. Вам не здалося.

І зараз чудовий час для мене визнати помилку та закріпити цей урок.

Тож, в чому проблема? Як виявилось, я дещо наплутав механізм роботи effect cleanup, а саме коли викликається та сама cleanup функція:

useEffect(() => {
  // якась магія
  return () => {
    // знову прибирати за цими магами
  };
}, [dep]);

Так от, я чомусь був переконаний, що cleanup викличеться при знищенні, або ж unmount компонента. Очевидно, що це в корені невірно, адже ця функція викликатиметься щоразу, як зміняться залежності. Перед виконанням самого ефекту.

Чому ж я був такий впевнений в зворотному? Бо останнім часом не дуже то й писав ефекти як такі, а з cleanup і поготів. А якщо писав, то зазвичай ішлося про ініціалізаційні ефекти, що мають виконатися лише раз:

useEffect(() => {
  // одноразова магія
  return () => {
    // разочок прибрав і все
  };
}, []);

І ось саме в цьому випадку cleanup функцію буде викликано лише один-єдиний раз — на unmount.

Давайте ще раз зафіксуємо:

useEffect(() => {
  return () => {
    // ОДИН раз на unmount
  }
}, []); <- пусті залежності

useEffect(() => {
  return () => {
    // ЩОРАЗУ на зміну залежностей + ОДИН раз на unmount
  }
}, [dep]); <- не пусті залежності

Що цікаво, я не так давно досліджував, як саме працює сам useEffect, як ставляться в чергу ефекти, як реєструються хуки і чому не можна виклики хуків класти в умовні конструкції. А про механізм cleanup просто забув.

Якщо дуже коротко, це все впирається в масив залежностей. React на кожен ререндер перевіряє попередні залежності і нові (не сам масив, а саме залежності) і ставить в чергу ефект лише тоді, як хоча б одна залежність зміниться за значенням або посиланням. До речі, важливо памʼятати, що useEffect не виконує сам ефект, а лише відповідає за постановку його в чергу.

Тож так, беручи прикладу з етеру, нам дійсно не потрібні ніякі рефи, проміжні значення та інші ускладнення:

useEffect(() => {
  const intervalId = setInterval(...);
  return () => clearInterval(intervalId);
}, [userId]);

Що ж, сподіваюсь, це нагадування стане в нагоді не лише мені самому, а я більше не морочитиму людям голову і не позоритимусь із тими ефектами на всю країну в прямому етері.

До речі, хто таки дивився останній випуск, чи винесли ви для себе щось корисне? Розкажіть хоч тут в коментарях, якщо на ютубі соромитесь ;)

@babichdev

#мої_кращі_практики

One hook to rule them all
Мене завжди бентежив підхід, коли компонент бере на себе й логіку, і ефекти, і обробку стану — усе підряд.

Десь ми беремо якісь дані, створюємо змінні з похідними станами, описуємо колбеки і хендлери, ефекти і тому подібне. І якщо описувати це в самому компоненті, то він перетворюється на чорну скриньку, бо тоді єдине місце, де ми можемо перевірити чи правильні значення у нас у стейті — це відображення цих даних в HTML.

І це мені дуже не подобається. Бо я вважаю, що логіку треба тестувати окремо, як логіку, а в самому компоненті ми маємо перевіряти лише те, чи вірно відображаються дані в залежності від різних станів.

Тому я користуюсь далеко не інноваційним, не оригінальним, проте дуже зручним підходом state hook. Він полягає в тому, що усі сторонні дані, які потрібні компоненту, я отримую й обробляю в хуці, який має назву use<ComponentName>State.

І повертає цей хук виключно стан, який необхідний для рендеру UI. Таким чином компонент отримує виключно ті дані, які будуть в JSX. І навіть якщо для цього стану потрібен якийсь інший, сам компонент про них не знатиме.

Це дозволяє дуже чітко розділити відповідальності — всередині стейт-хука я роблю усі обчислення, перетворення за необхідності, створюю усі хендлери та ініціалізую всі ефекти, а UI-компонент просто перетворює цей "зліпок" на інтерфейс.

function useComponentState() {
  const [filter, setFilter] = useState('');
  const { data, isLoading } = useSomeFetch(filter);
  const isDisabled = isLoading || !data?.length;
  const displayList = useMemo(() => {
    return data.map(doSomeStuff);
  }, [data]);

  const onInputChange = useCallback((event) => {
    setFilter(trim(event.target.value));
  });

  return {
    filter,
    displayList,
    isDisabled,
    onInputChange
  }
}

function Component() {
  const {
    filter,
    displayList,
    isDisabled,
    onInputChange
  } = useComponentState();

  return (
    <>
      <input value={filter} onChange={onInputChange} />
      <List items={displayList} />
      <button disabled={isDisabled}>Click me</button>
    </>
  )
}

Що це мені дає? По-перше, розділення відповідальностей. По-друге — компонент перестає бути чорною скринькою і перетворюється на абсолютно прямолінійну систему.

Це полегшує тестування. Бо я тепер можу тестувати суто стейт-хук як юніт, перевіряючи значення замість відображення. А саме відображення можна потестувати просто замокавши цей хук кількома потрібними "снапшотами" стану.

Це полегшує контроль за залежностями компонента, бо у нього вона стає лише одна. А залежності стейт-хука це вже геть інша історія.

Я не скажу, що це срібна куля і панацея, яка вирішує усі проблеми. Бо навіть інтеграційні тести все одно вимагатимуть від нас перевірки різних сценаріїв на відображенні. Але на рівні суто компонента такий підхід суттєво мені спростив роботу. Як мінімум, я не харюсь через те, що всередині компонента купа заплутаної логіки, бо її там просто немає.

Взагалі це лише частина загального підходу з розділення логіки на декілька шарів, зокрема аж на чотири, який я запропонував команді, і який знайшов дуже теплий відгук серед колег.

Цікавить, як це працює на рівні чотирьох шарів? Дайте знати в коментарях — розповім про весь підхід, який у нас суттєво покращив якість як суто коду, так і побудови наших інтерфейсів.

@babichdev

Хочеш потрапити в телевізор?

Подавай заявку!

Чергова співбесіда відбудеться 3 липня 2025, і саме ти можеш стати наступною зіркою каналу "Сергій Бабіч та Дивовижний світ веброзробки"!

Заявки приймаються до 21:00 неділі, 29 червня! З обраним зв’яжусь в понеділок, 30 червня.

Обов’язково мати стабільний інтернет та резервне джерело живлення. Камеру та мікрофон для ефіру я надішлю.

Записи етерів лишаються в публічному доступі. Мова спілкування — українська.

Прошу дуже серйозно поставитися до того, чи ви готові до власне публічної співбесіди

ПОДАВАЙТЕ ЗАЯВКУ ВЖЕ!

@babichdev

P.S. Форма має буть відкрита вже

Доброго ранку, друзі! Розпочну цей тиждень не з веброзробки, а набагато важливіжих справ.

Бійці 109 ОГШБ 10 ОГШБр "Едельвейс" передають вам привіт і подяку. Вони отримали першу частину РЕБу з модулем для високих частот.

І тепер чекають на модуль для низьких частот, на який якраз ми з вами і збираємо кошти. А зібрати лишилося не так уже й багато — якихось ~25 000 грн.

Нагадую, що кожні 50 грн вашого донату — це додатковий шанс виграти подарунок, а саме LEGO Dune Atreides Royal Ornithopter від моїх друзів з української продуктової IT-компанії Brainstack

🔗 Банка mono:
https://send.monobank.ua/jar/9XkNDTzHAZ

💳 Картка mono:
4441111124390562

@babichdev

P.S. Бійці дали дозвіл на публікацію як є, не закриваючи обличчя

Новий допис буде тільки після того, як доведем збір до 80 000.
Отак.

#css_in_action
Навіть невеличка зміна стилів одного елементу в DOM може потягнути за собою цілий каскад перерахунків, які можуть зачепити увесь документ. Так-так, навіть звичайний :hover на вашій картці товару може змусити бравзер запустити reflow та repaint для цілої сторінки. І чим складніший ваш застосунок, чим більше у ньому елементів, тим важчий та складніший такий перерахунок, тим більше ресурсів на нього йде.

Але чи існує якийсь спосіб вказати бравзеру, що усе так і задумано, і не варто випускати кракена там, де достатньо звичайної піратської дуелі на шаблях? І моя відповідь — так, існує!

Мова йде про властивість CSS contain, за допомогою якої можна вказати, що цей конкретний елемент — річ в собі, і тут своя атмосфера. Тобто зміни всередині цього елемента не мають впливати на оточуючий лейаут, і є ізольованими від зовнішнього контексту.

Існує 4 типи такої ізоляції: розміру, лейауту, "стилю" та відмальовки і усі вони відповідають за різні аспекти стилізації та впливають або на сам елемент, або на його нащадків. Обʼєднує їх одне: будь-які зміни відповідні всередині ізольованого контексту не мають впливу на оточуючі елементи.

Що важливо памʼятати. При використанні contain створюються новий containing block, stacking context та block formatting context. Тобто елемент ізолюється настільки, що навіть fixed елементи всередині нього тепер будуть позиціонуватися відносно нього, а не відносно viewport.

Чудова нагода саме зараз поставити вподобайку, чи не так?

Ви можете комбінувати різні значення властивості contain між собою (а самих значень є вісім), проте не всі між собою сумісні. Ну і є strict, яке поєднує в собі усі інші.

Тож яка користь з того? Повернімося до прикладу з початку допису — припустимо, у вас є на екрані 100 карток. Ви наводите курсор на одну з них, аби подивитися деталі, і бравзер починає запускати повністю весь процес рефлоу та репейнту, бо хто зна, яких ви там стилів на ховер навішали, може ви весь DOM перемішали? І це вийде досить дорого з точки зору швидкодії.

Однак, вказавши contain, ви поясните бравзеру, що ви так і планували, а кожна картка — ізольована і не повинна впливати на сусідів та загальний лейаут. В такому разі бравзер обмежить свої розрахунки суто цим елементом, заощаджуючи ресурси та час.

Так, звичайно, сучасні бравзери давно навчилися оптимізувати багато речей, включно з рендерингом, передбачаючи різні сценарії, однак усі вони ґрунтуються на припущеннях. Але contain дає вам змогу точно вказати, як саме та де саме ви полегшуєте бравзеру його й без того невдячну працю.

Використовувати contain ви можете просто вже, адже він є частиною Baseline.

🌐 MDN

А чи були у вас випадки, коли :hover перетворював швидкодію вашої сторінки на гарбуз? Розкажіть в коментарях!

@babichdev

Друзі, новини щодо збору!
Сьогодні зранку я оплатив модуль для РЕБ, на який ми збирали, тож збір завершено!

Розіграш останнього приза проведу дещо згодом, бо справ маю стільки, що не влазить вже.

Залишок від цього збору піде в наступний.

Щойно матиму фотозвіт від бійців, відразу викладу тут.

Дякую усім, хто долучився і долучається! Ви неймовірні!

Співбесіда Junior Angular з Нікітою Топчієм розпочнеться рівно за 5 хвилин!

youtube.com/watch?v=NxZYD5KZyNs

#browser_api
Ви коли-небудь відкривали вебінспектор для підсвіченого коду на тому ж GitHub? Якщо так, то бʼюся об заклад, що ви бачили щось таке:

<span class="blob-code-inner blob-code-marker " data-code-marker=" ">
  <span class="pl-s1">llm_type</span>
  <span class="pl-c1">=</span>
  <span class="pl-s1">fields</span>
  .
  <span class="pl-c1">ChoiceField</span>
  (
</span>

Навіть простий рядок перетворюється на суп, щедро приправлений спанами. Як наслідок: смертельная гангрена купа додаткових вузлів, що захаращують DOM і можуть призвести до суттєвих просадок швидкодії сторінки.

Але прийшов час радіти, бо тихо й непомітно зʼявилася специфікація Custom Highlight API, яка дозволяє розцяцьковувати текст на будь-який смак, не перевантажуючи сторінку оркестром диких span!

Тепер можна просто реєструвати Highlight, в який можна передати декілька діапазонів Range з позиціями, і вказувати стилі — усе без змін розмітки, завдяки CSS псевдоелементу ::highlight.

const range = new Range();
range.setStart(node, startOffset);
range.setEnd(node, endOffset);

const highlight = new Highlight(range);
CSS.highlights.set('myHighlight', highlight);

::highlight(myHighlight) {
  background-color: yellow;
}

І все. По суті, бравзер повністю забирає на себе побудову дерева стилів для масиву тексту, переносячи те, для що потребувало фактичного DOM-піддерева, у віртуальну структуру, приховану від сторонніх очей.

І нам лишається лише розпарсити текст на токени й описати яким діапазонам які стилі призначені.

Концептуально, звісно, суттєво нічого не змінилося — бравзеру так само необхідно надати інформацію, які послідовності символів як розмальовувати. Але замість повноважного DOM-дерева тепер для цього є швидка in-memory структура. А це, очевидно, позитивно впливає на продуктивність самої сторінки.

🌐 MDN: CSS Custom Highlight API

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

До речі, поділіться своїми думками, де би ця фіча стала в нагоді саме вам.

@babichdev

Good Enough Code. ч.4 — поради чи догмат?
[ч.3]

Зі сторони може здаватися, що Good Enough Code базується на якихось догмах, яких треба неухильно дотримуватися, і тоді код буде good enough сам по собі. Але насправді це зовсім не так — це не набір обов’язкових принципів, а радше філософія балансу.

Проте існує декілька орієнтирів, які добре знайомі розробникам і можуть допомогти не збитися з курсу, і як приклад можна узяти найвідоміші з них: YAGNI, KISS, DRY, Pareto.

Вони не є визначальними для GEC, але часто слугують найзручнішою рамкою для перевірки власних рішень.

Втім, важливо пам’ятати: сліпе застосування цих принципів може зашкодити не менше, ніж повне їх ігнорування. Тут, як і завжди в інженерії, все вирішує контекст.

YAGNI (You Aren’t Gonna Need It)
Цей принцип каже нам: «Не реалізовуй функціональність “про запас”, якщо в ній нема потреби просто зараз».

Але якщо ти реально впевнений, що за місяць це знадобиться і зробити потім буде в рази дорожче — можна і варто трошки попрацювати на майбутнє. YAGNI — не табу на передбачення, а швидше захист від безпідставних фантазій.

KISS (Keep It Simple, Stupid).
Простота — найбільша чеснота коду. Але простота без структури швидко перетворюється на хаос.

Бізнесу часто краща структурована складність, ніж хаотична простота, де “ніби все просто”, але підтримувати неможливо. KISS не примушує нас до відмови від архітектури, радше пропонує розумне спрощення.

DRY (Don’t Repeat Yourself). «Не дублюй без потреби — це рятує від багів».
Водночас не варто передчасно абстрагувати, створюючи нечіткі ієрархії там, де простий повтор був би зрозумілішим і дешевшим.

Будь-який код перестає бути універсальним через кілька ітерацій, і часто надмірна абстракція призводить до того, що модуль перетворюється на монстра, що вміє усе, але не може нічого. DRY має працювати на прозорість, а не на штучну універсальність.

Pareto principle (80/20 rule): 80% ефекту дають 20% зусиль — чудова ідея, якщо дозволяє контекст.
Але для критичних компонентів навіть дрібні недопрацювання можуть мати катастрофічні наслідки, тож тут Pareto працює значно обережніше.

Важливо розуміти: надмірне слідування будь-якому одному принципу майже гарантовано порушить інший. Спробуєш фанатично уникати повторів — постраждає простота; спростиш усе до мінімуму — втратиш масштабованість; поженешся за Pareto — ризикуєш пропустити критичні баги.

Нашою метою як розробників має бути розумний баланс, бо викрутити усі показники на 100% неможливо фізично. Важливо завжди тримати в голові: усі ці принципи — не закон, а інструмент мислення. Вони дозволяють перевіряти себе:

– Чи я не перестарався із ускладненням?
– Чи справді варто так абстрагувати?
– Чи достатньо цей код вирішує задачу тут і зараз?

Good Enough Code — це не догмат, не заповіді. Він радше покладається на вміння балансувати між простотою, якістю і контекстом, а головне питання, яким треба задаватися в пошуку цього балансу — «Для кого і навіщо цей код?»

#good_enough_code #мислення_розробника

@babichdev

#туса
Товариство, якби хто хотів зустрітися у Львові, поговорити про фреймворки, бібліотеки і івент-луп за келихом чогось смачного, то цієї пʼятниці буде невеличка тусовка.

Приходіть цієї п'ятниці до пабу "Горобець", за адресою Театральна, 23 десь так від шостої годинки вечора, зустрінемось, познайомимось, поділимось наболілим.

Чекатиму ;)

Друзі, я щойно розіграв Lego серед усіх учасників попереднього збору на РЕБ, однак ще чекаю на підтвердження від переможця. Тож вітаю його з перемогою! Але допис доведеться зробити, коли вже надішлю приз, шо тут поробиш.

А нині у мене до вас прямо дуже термінове прохання. Маємо на бронюванні Mavic для 184 навчального центру, і треба в дуже стислий термін зібрати 80 000 гривень. Проте є важливий момент — двох місяців, як минулого разу, у нас нема, а є тиждень.

Тому я буду неймовірно вдячний за кожну гривню, а особливо — якщо хтось із вас долучиться дружньою банкою. Якщо маєте таке бажання — пишіть.

Дякую!

***
На Mavic для 184 навчального центру

🎯 Ціль: 80 000 ₴

🔗Посилання на банку
https://send.monobank.ua/jar/AeXQ6YRf2X

💳Номер картки банки
5375411202918178

Північ памʼятає! А от твоєму коду — необовʼязково.
Дуже часто, говорячи на співбесідах про оптимізацію швидкодії, перше, що я чую — треба все мемоїзувати. Чи приймаю я це за вірну відповідь? Заледве.

Мемоїзація — це така техніка збереження результату якихось обчислень за умови, що вхідні параметри не змінено.

cache = {}

fn square(x):
  if not (x in cache):
    cache[x] = x * x
  return cache[x]

В цьому дуже спрощеному прикладі з псевдокодом мемоїзується обчислення квадрата числа. І на початку відбувається перевірка, чи ми таке число вже обробляли. Якщо так — повертаємо збережене значення, якщо ні — рахуємо, зберігаємо і вже тоді повертаємо значення з кешу.

Так от. Головне питання — коли ж має сенс користуватися мемоїзацією?

Відповідь проста — коли обчислення дійсно дорогі, і надмірне їх використання може призвести до суттєвих витрат обчислювальних ресурсів.

Часто я бачу в коді "оптимізацію" на кшталт

const doubled = useMemo(
  () => value * 2,
  [value]
);

І це зовсім не оптимізація. На ділі value * 2 виконується практично миттєво, а головне — без використання надлишкових ресурсів.

У випадку з useMemo, відбудеться наступне: спершу створюється екземпляр анонімної функції, потім — новий масив залежностей; далі виконується useMemo, у якому спочатку порівнюються поточні залежності з попередніми, а за тим — відбувається умовна перевірка; і якщо value змінилося — то запускається ще й саме обчислення.

І усе це — заради однієї операції, яка сама по собі відбудеться настільки блискавично, що ваш M4 навіть її не помітить.

Звичайно, майже не помітить він і виконання усієї катавасії з useMemo, але якщо таких "оптимізацій" назбирається достатньо, то це може стати вже відчутним.

Мемоїзація, безперечно, є надзвичайно потужним інструментом, який дозволяє заощадити час та ресурси. Якщо користуватися ним там, де воно дійсно потрібно.

Якщо ж бездумно "оптимізувати" усе, що бодай трохи нагадує обчислення, швидше за все ви будете виконувати стільки надмірного коду, що швидкодія вашого застосунку погіршиться ще більше.

Тож давайте занотуємо: мемоїзація — це не синонім продуктивности. Це засіб уникнути повторної роботи там, де вона справді затратна. Якщо обчислення швидкі, чи виклики функції одноразові — не чіпайте.

Якщо ж вартість обчислення відчутна, а повторюваність висока — тоді так, мемоїзація стане у пригоді. Але важливо пам’ятати: використання мемоїзації — не ритуал "на гарну швидкодію", а осмислене інженерне рішення, яке має свої наслідки.

***
Пропоную разом із вогником або серденьком до цього допису додати ще й 5 гривень донату на Mavic для 184 навчального центру. Дякую всім і цьом вам у лобіка.
https://send.monobank.ua/jar/AeXQ6YRf2X
5375411202918178

***
@babichdev