У нас на проекте есть 2 основных правила для написания стилей:

- У всех CSS-классов должен быть префикс dp\-, выбранный по названию продукта
- Мы используем БЭМ — <block>__<element>\-\-<modifier>

Однако есть большой пласт легаси стилей, где эти правила не используются.

И вот, при добавлении monaco-editor’а (текстовый редактор на котором построен VS Code) в новую фичу, прилетело ишью — у горизонтального и вертикального скролл-баров разная толщина.

А вся проблема в том, что наши глобальные стили для класса slider применяются к элементу с таким же классом в monaco-editor.

Именно эту проблему и решают префиксы — позволяют избежать коллизии имён с библиотечными классами.

#css #bem

size-limit

Вот здесь я писал про source-map-explorer и о том, как с его помощью анализировать размер бандла. Но, чтобы не приходилось анализировать бандл, лучше предотвратить его раздувание.

Это можно сделать на этапе CI с помощью size-limit.

Как использовать❓****

1. Устанавливаем size\-limit и плагин @size\-limit/file, необходимый для анализа web-приложений.

```
npm install --save-dev size-limit @size-limit/file

```

1. Добавляем когфиг size-limit в package.json

```
"size-limit": [
{
"limit": "35 kB",
"path": "dist/app-*.js",
"gzip": true
}
],

```

1. Добавляем запуск size-limit в скрипт, который вы запускаете на CI

```
"scripts": {
"size": "npm run build && size-limit",
"test": "vitest && eslint . && npm run size"
}

```

Если вы пользуетесь гитхабом, то можете использовать GitHub action, который добавляет в качестве комментария изменение размера бандла.

Также size-limit поддерживает задание временных лимитов на исполнение вашего кода и использует для этого “безголовый хром”.

#frontend #performance #tools #ci

GitHub

GitHub - ai/size-limit: Calculate the real cost to run your JS app or lib to keep good performance. Show error in pull request…

Calculate the real cost to run your JS app or lib to keep good performance. Show error in pull request if the cost exceeds the limit. - ai/size-limit

Со стороны может показаться, что у нас, у программистов, очень лёгкая работа. Как любит говорить мой тренер по теннису: “мол успешные айтишники сидят где-нибудь в эмиратах, птягивают кофе в кафешках и в ус не дуют”. В чем-то он может и прав, но почему-то не у всех получается “войти в айти”. А те, кто вошел, только и говорят о выгорании.

Года 3 назад я писал, что я делаю, чтобы не перегореть. С тех пор добавилось ещё несколько привычек.

? Я начал играть в большой теннис. Пока бегаешь по корту и чуть ли не выплёвываешь свои лёгкие, совсем забываешь о работе.

?‍♂️ С нового года я начал делать зарядку, увидел пост у Евгения Шушкова и тоже решил попробовать. Не уверен, что я чувствую себя намного лучше, но зарядка определённо помогает проснуться. Но что гораздо лучше, она помогает на какие-то 15 минут немного избавиться от тревожности.

- Обычно я делаю вот этот комплекс на 15 минут
- Или этот на 5 минут, когда лень, но чтобы не потерять привычку

? В дополнение к зарядке стараюсь пару раз в неделю подтягиваться или отжиматься. Или же делаю вот этот комплекс на пресс, первые 4 минуты, потом пресс умирает.

?В мае я отписался от новостных каналов.

---

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

P.S.

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

Если у вас есть желание помочь людям, кто вынуждено покинул свои дома из-за всей ситуации в Курской области, это можно сделать здесь. Или напишите мне в личку.

Я вообще считаю, программирование это не про “писать код”, это про людей. И мы можем сделать жизнь людей лучше не только написав очередные 1000 строчек кода.

Хабр

Очередная история о борьбе с выгоранием

Я думаю, не стоит никому объяснять, что такое выгорание, большинство периодически ходят по краю, рискуя упасть и окунуться в это состояние с головой. В двух словах выгорание  — это поломка...

source-map-explorer

На прошлой неделе анализировал размер главного бандла мобильной версии нашего приложения.

В спешке мы накосячили с импортами и бандл раздулся.

? Как анализировать?

Для анализа использовал утилиту source-map-explorer.

При запуске, утилита генирирует древовидную карту, с помощью которой можно увидеть, какие именно файлы попадают в бандл.

К сожалению, почему именно это что-то попало в бандл утилита не говорит.

? В чём была проблема?

Иногда мы ленимся и в файле компонента кладём какую-нибудь утилитную функцию, enum или константу, а потом где-то в другом месте импортируем их.

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

P.S. А какими инструментами пользуетесь вы?

#frontend #performance #tools

Как инспектировать разметку попапов

Если у вас возникают проблемы с дебагом попапов, которые открываются только по ховеру, то вот несколько простых советов:

Способ 1: Открываете DevTools ⇒ Вкладка Sources ⇒ Далее наводите мышкой на свой элемент ⇒ Нажимаете F8, чтобы приостановить выполнение скрипта

Способ 2: Открываете DevTools ⇒ Находите тег body или тот тег, внутри которого появляется попап и нажимаете на нём правой кнопкой ⇒ Выбираете “Break on ⇒ subtree modification” и дебажите до тех пор пока не появится попап.

Способ 3: Мой любимый. Вставляете скрипт в консоль и у вас есть 3 секунды чтобы показать попап. Именно этим способом пользовался пока не узнал про первый ?

```
setTimeout(() => { debugger }, 3000)

```

#frontend #devtools

Если бы вас спросили, что самое сложное в вашей работе, чтобы вы ответили?
Я думаю одна из самых сложных вещей - читать чужой код, или свой собственный, написанный пару лет назад.

? Сегодня статья о том, Как избежать когнитивной перегрузки: способы оптимизации кода для разработчиков.

Вот основные моменты из статьи, если вам лень читать всю статью в пятницу да ещё и летом ?

- Когнитивная нагрузка – это объем умственной работы, необходимый разработчику для выполнения задачи. Нашим приоритетом должно быть максимальное снижение такой нагрузки в проектах.
- Типы когнитивной нагрузки:
- Внутренняя — изначальная сложность задачи, её нельзя уменьшить.
- Внешняя — создается способом представления информации. То есть то, как написан код, решающий задачу.
- Знакомая и простая вещь — не одно и то же. Они ощущаются одинаково — та же легкость перемещения по пространству без особых умственных усилий, но по совершенно разным причинам. Каждый «умный» и нестандартный прием приведет к трате времени на обучение для остальных разработчиков. После того, как они его освоят, им будет легче работать с кодом. Именно поэтому не так легко понять, как можно упростить уже знакомый код.
- Нет никакой «упрощающей силы», влияющей на базу кода, кроме вашего сознательного выбора. Упрощение требует усилий, а люди часто спешат.
- Отладка в два раза сложнее написания кода. Следовательно, если вы пишете код максимально хитроумно, вы по определению недостаточно умны, чтобы его отладить.

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

- DRY (Don’t repeat yourself) — хотя в целом это хорошее и фундаментальное правило, его чрезмерное использование приводит к непосильной когнитивной нагрузке. У DRY есть альтернатива — AHA Programming
- Вы можете слишком рано извлечь общую функциональность, основываясь на предполагаемом сходстве, которого на самом деле в долгосрочной перспективе может не быть. Это может привести к ненужным абстракциям, которые будет непросто модифицировать или расширять.
- «Небольшое копирование лучше, чем небольшая зависимость».

https://habr.com/ru/companies/ncloudtech/articles/818643/

#fridayreading #essential

Хабр

Как избежать когнитивной перегрузки: способы оптимизации кода для разработчиков

По мнению Артема Закируллина*, одна из фундаментальных проблем, с которой сталкиваются разработчики при анализе кода – высокая когнитивная нагрузка. Это не абстрактное, а реальное ограничение...

Как я обычно узнаю о новых фичах в C# ❓****

О новых фичах в C# я обычно узнаю с помощью подсказок Райдера — IDE для C# от JetBrains.

В общем, обновился, пишу код, и Райдер предлагает что-то исправить там, где раньше все было окей. Думаю — ну ок, давай исправим. Но ощущение, что он перепутал C# c JavaScript.

- string[] array = new [] { “a”, “b”, } предлагает заменить на string[] array = ["a", "b"]
- Array.Empty<string>() на []
- List<string> list = new (vowels) на List<string> list = [.. vowels]

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

```

int[] row0 = [1, 2, 3];
int[] row1 = [4, 5, 6];
int[] row2 = [7, 8, 9];

int[] example1 = [..row0, ..row1, ..row2];
List example2 = [..row0, row1[0]];

```

В общем, в C# 12 поднасыпали синтаксического сахара для работы с коллекциями. А ещё прихватили Primary конструктор из Scala. Это когда конструктор объявляется сразу после имени класса.

```

public class BankAccount(string accountID, string owner)
{
public string AccountID { get; } = accountID;
public string Owner { get; } = owner;

}

```

Подробнее о релизе C# 12 здесь.

А о том, как добавить поддержку спред оператора для кастомных коллекций описывается тут.

#csharp

Docs

Declare and use C# primary constructors in classes and structs

Learn how and when to declare primary constructors in your class and struct types. Primary constructors provide concise syntax to declare constructor parameters available anywhere in your type.

function(): Promise ? async function(): Promise

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

Пример

```
function fn(obj) {
const someProp = obj.someProp
return Promise.resolve(someProp)
}

async function asyncFn(obj) {
const someProp = obj.someProp
return Promise.resolve(someProp)
}

asyncFn().catch(err => console.error('Catched')) // => 'Catched'
fn().catch(err => console.error('Catched')) // => TypeError: Cannot read property 'someProp' of undefined

```

- при объявлении функции с ключевым словом async JavaScript гарантирует, что функция вернёт Promise, даже если в ней произошла ошибка
- если функция возвращает Promise, но объявлена без async то catch не поймает ошибку, если в функции произошла ошибка
- дело в том, что ошибки произошедшие внутри конструктора new Promise((resolve, reject) => { throw new ... }) промиса ловятся. Когда мы добавляем async, то по сути заворачиваем тело функции в new Promise((resolve, reject) ⇒ { })

То есть, чтобы сделать функции из примера идентичными, нужно завернуть первую функцию в промис.

```
function fn(obj) {
return new Promise((resolve, reject) => {
const someProp = obj.someProp;
resolve(someProp);
});
}

```

https://habr.com/ru/articles/475260/

#javascript #frontend

Хабр

Разница между асинхронной функцией и функцией, возвращающей промис

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

Сегодня принёс вам одну из лучших статей по код ревью.

В конце статьи автор упоминает фразу, которая уже давно вертелась у меня на языке, и вот здесь она отлично сформулирована.

? “Как это ни парадоксально, наличие постоянно полезных и ценных ревью — это признак того, что вы можете добиться большего на других этапах процесса.”

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

Также ещё одна мысль, которую доносит автор — “код ревью не должно быть одинаковым для всех изменений”.

? Проблемы медленных ревью

- Они медленные ?‍♂️  — замедляют релиз на несколько часов или дней
- Поверхностные — не улучшают качество кода, не происходит обмен знаниями.
- Если ревью происходит медленно — разработчики начинают создавать большие пул реквесты, что увеличивает нагрузку на ревьюера и делает код ревью ещё медленнее.

Подходы, которые описываются в статье

Автор долго придерживался принципа Ship / Show / Ask

- *? Ship. Изменения простые, нет знаний, которыми стоит поделиться — льём в прод без ревью.
- *? Show. Если изменения простые, но в них есть что-то полезное и ими стоит поделиться (например вы написали новую функцию или компонент), то — сливайте изменения, а потом просите о код ревью. Код ревью — не блокирующий. Я обычно называю это постревью.
- ❓Ask.** Если вы вносите сложные изменения — дождитесь код ревью и только потом сливайте изменения. Тут код ревью блокирующий.

Со временем он его немного перефразировал в Automate / Defer / Pair

- *? Automate. Если в изменениях нет знаний, которыми стоило бы поделиться, а в коде особо нечего улучшить — пропускаем ревью и полагаемся на линтеры, статические анализаторы и тесты.
- *↪️ Defer (отложить). В зрелом и проверенном процессе разработки большинство изменений нужно ревьюить, но ревью не должно быть блокирующим. Это особенно хорошо работает, когда новая фича деплоится за фича флагом и можно спокойно получить фидбек после деплоя.
- ? Pair. Если корректность изменений очень важна: их сложно откатить или изменения связаны с оплатой, или же изменения достаточно сложные — то вам нужно работать в паре** с ревьюером, созвониться и объяснить ему изменения, чтобы он был в контексте и смог сделать ревью быстрее и качественнее.

#codereview #fridayreading #weekphrase

refactoring.fm

Thoughts on Code Reviews 🔍

Why so many teams mess them up, and a modest proposal to do them better.