⚡️ Что такое замыкание и как оно приводит к утечкам памяти

В прошлый раз мы с вами говорили о лексическом окружении и причинах его создания, а сегодня поговорим о замыканиях. Термином “замыкание” в javanoscript обозначает функцию и ее лексическое окружение. Как вы помните, лексическое окружение в javanoscript содержит в себе ссылку на внешнее лексическое окружение - таким образом, все внешние лексические окружения для функции будут доступны ей через цепочку ссылок.

Что происходит с лексическим окружением функции после того, как она завершила свою работу? Довольно часто оно больше не нужно и уничтожается, однако бывает и иначе. Рассмотрим пример:

function makeCounter() {
    let count = 0;
    const increment = () => count++;
    return increment;
}
let counter = makeCounter();
counter();
counter();

Функция makeCounter завершила свою работу, однако лексическое окружение, которое она создала - с идентификатором count в нем - осталось в памяти. Почему так? Потому что лексическое окружение функции makeCounter - внешнее для лексического окружения функции increment, которая в нем создается. Когда мы вернули из makeCounter функцию increment, прицепом к ней мы вернули все ее лексическое окружение. Поскольку на это лексическое окружение ссылается increment (ниже counter - это две переменных указывают на одну область памяти), то лексическое окружение вместе с переменной count надежно зависло в памяти до тех пор, пока counter остается ссылочно доступен.

В данном случае makeCounter у нас “зависло” совсем маленькое лексическое окружение с переменной count - однако бывают и гораздо более серьезные утечки памяти, связанные с замыканиями. Такая ситуация происходит, если “зависшее” лексическое окружение занимает много места в памяти и/или ссылается на другие “тяжелые” лексические окружения. Вот здесь я писала об одной из таких утечек в Promise.race, а в следующий раз поговорим с вами о том, как “зависшее” лексическое окружение приводит к ситуациям, которые мы называем stale props и stale state.

#замыкание #javanoscript

Stale props и stale state

📌 Stale state — это ситуация, когда внутри замыкания используется устаревшее значение состояния. Stale props - то же самое, но для пропсов. Рассмотрим на примере, как это происходит.

export const Example = () => {
  const [count, setCount] = useState(0);

  useEffect(() => {
    setTimeout(() => {
      console.log(count);
    }, 1000);
  }, [])

    return (
       <button
          onClick={() => setCount((c) => c + 1)}
       >
         {count}
     </button> // кликнем несколько раз
    ) 
}

Мы имеем React компонент Example, в котором имеется:
1. Состояние counter. 2. Эффект, который единожды сработает после монтирования и который выводит наше состояние в лог. Что будет, если за секунду мы уже успеем кликнуть по кнопке несколько раз и counter изменится? Выведется исходное состояние - то, которое было на момент срабатывания эффекта и установки таймера. Вы можете увидеть это на скриншоте выше. Давайте посмотрим подробнее, как так происходит.

В анонимной функции-колбеке, которую планирует таймер, никакого идентификатора counter не существует. Откуда javanoscript возьмет его при вызове? Он возьмет его из родительского лексического окружения, то есть из лексического окружения функции Example, которая одновременно является реакт компонентом. Клик на кнопке приведет к изменению состояния, а это, в свою очередь, вызовет ререндер - то есть новый вызов функции Example. Каждый новый вызов создаст свой объект лексического окружения. Однако нашей анонимной функции с логом до этого нет дела - она надежно запомнила, из какого лексического окружения ей нужно брать counter: из того объекта лексического окружения, которое было создано на момент вызова useEffect. Таким образом, когда наш таймер сработал и вывелся лог, мы увидели там устаревшее состояние.

#react

🪄Как применять S из SOLID

Про принцип единственной ответственности написаны тонны статей, но как, чёрт возьми, применять его в реальной разработке? Для того, чтобы успешно применить этот и другие принципы, необходимо осознать одну вещь: наш код не существует сам по себе в сферическом вакууме, это модель реального мира. Связи между компонентами/классами/функциями в нашем коде должны быть такими же, как в реальном мире.

Например, вам нужно сделать формы авторизации и регистрации. На макете они выглядят одинаково, и вы задумываетесь: сделать один универсальный компонент или два отдельных. Для того, чтобы ответить на этот вопрос, вспомните, как проходят эти процессы в реальной жизни. Например, в моем фитнес клубе они существенно отличаются: для регистрации в клубе я заполняла договор с паспортными данными, а для ежедневной регистрации в клубе мне достаточно приложить браслет к турникету. Совершенно разные действия, разные цели, разные сценарии. То же самое и в вебе: регистрация и авторизация - это два разных бизнес-процесса. Даже если сегодня их формы выглядят одинаково, эти компоненты живут своей независимой жизнью: например, на форме авторизации в какой-то момент может появиться галочка “мне уже есть 18”, а на форме регистрации - нет. Или поменяются поля, логика валидации, поведение при ошибках.

Другой пример: вы реализуете карточки товаров, и в разных разделах они имеют разные цвета. Использовать один компонент или делать разные? Давайте подумаем, как бы мы действовали бы в реальном мире. Представьте, что вы печатаете ценники на принтере. Шаблон один и тот же - вы просто вставляете бумагу нужного цвета: белую, жёлтую, синюю. Цвет меняется, но структура остаётся прежней.Если вы решите изменить размер ценника, например, сделать его больше - это уже изменение шаблона, которое повлияет на все ценники сразу. Точно так же в вебе: если мы хотим поменять структуру или размер карточек, то, как правило, мы хотим сделать это у всех карточек сразу. Таким образом, карточка - это один компонент с настраиваемым цветом.

#solid #srp

Про оценку сроков

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

Однако непредвиденные проблемы возникают практически всегда. Внезапно выясняется, что часть системы, куда нужно интегрировать новую фичу, работает с багами, или наше решение не вписывается в существующую архитектуру. Разумеется, все эти моменты становятся известны уже в процессе решения задачи, но никак не на этапе планирования. Мы сталкиваемся со сложным выбором: провалить сроки или овертаймить.

Каждый из нас решает эту проблему по-своему. Один мой бывший коллега всякий раз очень долго извинялся, когда факапил сроки, и обещал обязательно все сделать сегодня. Но он снова не успевал, и снова извинялся. Другой мой бывший коллега оставался допоздна перед дедлайном, а как-то раз и вовсе заночевал на офисном диване.

В защиту программистов скажу, что проблема оценок существует не только в айти: любой сложный процесс практически невозможно спрогнозировать. Один мой менеджер как-то сказал: представь, что твой врач не может назвать, сколько времени уйдет на лечение, что ты будешь чувствовать? Это был очень плохой пример: как раз в это время я проходила стоматологическое лечение, которое заняло на год больше ожидаемого и оказалось в 2,5 раза дороже изначально планируемой суммы.

Разработка - это сборка конструктора из мелких деталей: никогда не знаешь, подойдёт ли новая деталь к уже собранной части. Это напоминает известную проблему остановки Тьюринга: для любых двух функций F и G мы никогда не можем определить, что их суперпозиция остановится (= заработает как надо). Алан Тьюринг доказал неразрешимость этой проблемы еще 90 лет назад, однако менеджеры по сей день продолжают пытать программистов на очередном дейли вопросом “так, сколько тебе еще делать эту задачу?”.

Однако можно сделать ровно противоположное: не угадывать срок, который уйдет на разработку, а зафиксировать время, которое вы готовы уделить на фичу. Например: “Мы готовы потратить на эту фичу 2–5 дней. Обязательно - чтобы работало вот это. Всё остальное сделаем по возможности”. Тогда вы не будете зависеть от точных оценок, и при любом раскладе сделаете главное.

Первый раз я применила этот способ еще в 2019 году. Я прикинула, что мне нужно около двух недель на задачу. Однако менеджер вернулась ко мне со словами - “бизнес не дал тебе две недели, бизнес дал тебе неделю”. “Хорошо, я могу сшить семь шапок из этой шкурки,” - подумала я. Я сделала каркас фичи за неделю, но не успела добавить несколько удобных штук в свое решение, плюс пропустила некоторые корнер кейсы. Менеджер осталась довольна. А затем попросила доработать решение и учесть корнер кейс. “Хорошо,” - сказала я, - “на это мне нужна еще неделя”. На том и порешили.

Если вы разработчик и от вас требуют конкретные сроки - попробуйте так и сказать: “Я точно успею сделать вот это, а остальное - постараюсь, если не вылезем за дедлайн”. Тогда вы точно сможете рассчитывать на то, что критическая функциональность будет готова в срок, а опциональной можно пренебречь.

В тему оценки.

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

И ведь мне это нужно как-то оценить 😊

Говорила то же самое, когда это еще не было мейнстримом 😊
Брутфорсить собесы - это очень плохая идея.

Небольшое объявление для тех, кто планировал прийти ко мне на менторство или консультации - из-за сильной загруженности как минимум до конца октября такой возможности не будет :(
Это не относится к тем, с кем уже работаю или с кем есть договоренности.

Upd. Если вам нужна моя помощь и дело не терпит до конца октября, на данный момент смогу уделить вашему кейсу 10-15 минут и ответить на ваш вопрос в личке. Пишите в личку. Это бесплатно😊

Прошлый пост вызвал жаркую дискуссию о том, нужны ли алгоритмы.

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

Я считаю так: если вы учитесь на реальных задачах, то вам постоянно придется учиться каким-то новым реальным задачам. На старой работе вы привыкли хранить данные в редаксе, приходите на новую, опа, а тут используется контекст. Приходится постоянно переучиваться.

Так получается потому, что реальных задач невероятно много. А вот фундаментальных задач, частными случаями которых являются реальные, на порядки меньше. Понимая фундаментальные задачи, можно с их помощью решить частные случаи. А вот наоборот, увы, не работает (ну а если у вас работает, значит, вы уже шарите в алгоритмах😎).

Бинарный поиск

Сегодня поговорим о бинарном поиске.

Бинарный поиск нужен для того, чтобы быстро что-то найти. Для того, чтобы можно было легко что-то найти, нужен порядок (прямо как в шкафу). Проще говоря, данные, где вы ищите, должны быть отсортированы по какому-нибудь признаку.

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

В классическом варианте вы наверняка увидите массив чисел, в котором ищется число x, равное, ну скажем для примера, 17. Мы делим кучку на две части пополам, и смотрим, чему равна середина. Если середина больше 17, то нам нужно искать в левой кучке (там, где числа поменьше). Если середина меньше 17, то наша кучка - правая. Искать таким образом числа в массиве вам, скорее всего, не потребуется никогда, но вот сама идея - “разделяй и властвуй сравнивай” - очень полезная.

В повседневной работе идея делить кучу на две поменьше пригождается в самых разных ситуациях. Например, конструкция if else тоже позволяет поделить данные на две кучки по какому-нибудь признаку. А еще та идея полезна для дебага. Допустим, вы внесли много изменений в код и в какой-то момент все сломалось (прямо как у меня сегодня). Как быстро найти проблемный файл? Очень просто: убираем половину ченжей (например, в stash) и проверяем, как это отразилось на баге. Если баг все еще воспроизводится, то делим эту кучку еще на две. Эту же идею использует для дебага git bisect.

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

Удачных вам разделений и сравнений!
#алгосы