This media is not supported in your browser
VIEW IN TELEGRAM
#фишка дня
Пользуетесь VS Code и хотите упросить себе жизнь ещё больше?
Say no more!
Берёте такие и пишете вокруг какого-то куска кода комментарии:
И вуаля, весь этот означенный комментариями блок можно взять и свернуть, как функцию или область видимости в скобках.
Можно использовать при работе с, например, legacy-кодом или вообще пометить себе кандидата на вынос в отдельный модуль 🔪.
Удобно? По-моему, да. Спасибо, Nicolas Carlo.
#vscode #refactoring
Пользуетесь VS Code и хотите упросить себе жизнь ещё больше?
Say no more!
Берёте такие и пишете вокруг какого-то куска кода комментарии:
// #region
bla {
blu;
ble;
}
foo {
bar;
baz;
}
// #endregion
И вуаля, весь этот означенный комментариями блок можно взять и свернуть, как функцию или область видимости в скобках.
Можно использовать при работе с, например, legacy-кодом или вообще пометить себе кандидата на вынос в отдельный модуль 🔪.
Удобно? По-моему, да. Спасибо, Nicolas Carlo.
#vscode #refactoring
👍41🔥5👏1
#статья дня
Чему senior-разработчики могут поучиться у начинающих: https://stackoverflow.blog/2019/12/19/what-senior-developers-can-learn-from-beginners/
А теперь подтверждение тезисов статьи от, собственно, меня.
Случилось вот что: мы в шесть глаз просмотрели глупейшую опечатку.
В очень старом коде было повторяющееся условие проверки включения элемента в массив настроек:
…и обратное к нему (=== -1).
Очевидно, было принято решение заменить его на переменную
И в этот момент и была допущена ошибка: заменив инверсное условие, мы забыли поставить оператор отрицания: “!”. И на ревью никто не заметил этого.
Почему? Потому что иногда лучше быть чётким в своих условиях, пусть даже код и выглядит странно. Очевидно, решение было плохим, но оно хотя бы было прямолинейным и чётко описывало условие. Раз три человека это пропустило, значит, и подход к рефакторингу был неверным изначально.
Не нужно писать плохой код, но что ещё хуже — во имя благих намерений пытаться исправить плохо написанный, но рабочий код.
…и ещё пишите тесты, прежде чем влезать в логику старого кода, да.
#tdd #codestyle #refactoring
Чему senior-разработчики могут поучиться у начинающих: https://stackoverflow.blog/2019/12/19/what-senior-developers-can-learn-from-beginners/
А теперь подтверждение тезисов статьи от, собственно, меня.
Случилось вот что: мы в шесть глаз просмотрели глупейшую опечатку.
В очень старом коде было повторяющееся условие проверки включения элемента в массив настроек:
settings.indexOf(“ADD_RESULTS”) !== -1…и обратное к нему (=== -1).
Очевидно, было принято решение заменить его на переменную
shouldAddResults и использовать везде.И в этот момент и была допущена ошибка: заменив инверсное условие, мы забыли поставить оператор отрицания: “!”. И на ревью никто не заметил этого.
Почему? Потому что иногда лучше быть чётким в своих условиях, пусть даже код и выглядит странно. Очевидно, решение было плохим, но оно хотя бы было прямолинейным и чётко описывало условие. Раз три человека это пропустило, значит, и подход к рефакторингу был неверным изначально.
Не нужно писать плохой код, но что ещё хуже — во имя благих намерений пытаться исправить плохо написанный, но рабочий код.
…и ещё пишите тесты, прежде чем влезать в логику старого кода, да.
#tdd #codestyle #refactoring
Stack Overflow Blog
What senior developers can learn from beginners
Over the last couple years, I’ve had the luxury of working with and mentoring quite a few beginners. While I’ve obviously witnessed my fair share of programming no-no’s, things are not as black and white as they may seem. There’s a handful of patterns and…
😁1
#статья дня
Смотрим на иллюстрацию. Узнали? Согласны?
Да не врите, каждый из нас в какой-то момент карьеры создавал мега-компоненты со всеми возможными антипаттернами.
А ещё некоторые антипаттерны когда-то назывались просто паттернами...
В общем, статья, ради которой вам придётся заварить чаю или кофе и потом даже в термос перелить: Алекс Кондов и его статья о недавнем рефакторинге слишком большого React-компонента.
Вот: https://alexkondov.com/refactoring-a-messy-react-component/
1. Покрываем тестами
2. Линтуем
3. Чистим мёртвый код
4. Переделываем хранение состояния
5. Разбиваем условия
6. Применяем принцип единой ответственности
7. Выносим бизнес-логику наружу
8. Переделываем загрузку данных
9. Выносим хуки
10. Отрабатываем граничные состояния, например, отмену загрузки данных
11. Упрощаем отправку формы
12. Валидация
Естественно, без библиотек не обошлось. Чтобы не быть обвинённым в раздувании кодовой базы, автор выделил в отдельный блок обоснование их использования.
В общем, это отличный пример.
#react #refactoring
Смотрим на иллюстрацию. Узнали? Согласны?
Да не врите, каждый из нас в какой-то момент карьеры создавал мега-компоненты со всеми возможными антипаттернами.
А ещё некоторые антипаттерны когда-то назывались просто паттернами...
В общем, статья, ради которой вам придётся заварить чаю или кофе и потом даже в термос перелить: Алекс Кондов и его статья о недавнем рефакторинге слишком большого React-компонента.
Вот: https://alexkondov.com/refactoring-a-messy-react-component/
1. Покрываем тестами
2. Линтуем
3. Чистим мёртвый код
4. Переделываем хранение состояния
5. Разбиваем условия
6. Применяем принцип единой ответственности
7. Выносим бизнес-логику наружу
8. Переделываем загрузку данных
9. Выносим хуки
10. Отрабатываем граничные состояния, например, отмену загрузки данных
11. Упрощаем отправку формы
12. Валидация
Естественно, без библиотек не обошлось. Чтобы не быть обвинённым в раздувании кодовой базы, автор выделил в отдельный блок обоснование их использования.
В общем, это отличный пример.
#react #refactoring
👍21👎2❤1