А что в это время делает корпорация зла?

https://garrit.xyz/posts/2022-11-24-smart-move-google

Я уже не первый раз слышу, что подписчики жалуются, что подкаст "Под куполом" не доступен в РФ.

Я сейчас перенес подкаст на другую платформу.
Попробуйте воспроизвести без VPN!

https://podcast.sova.dev/

К сожалению, подкаст "Сова говорит…" не выпускался уже несколько лет и вряд ли будет продолжаться

Но все выпуски можно послушать на soundcloud
https://soundcloud.com/sergeysova

Нашел весьма полезные правила для онлайн общения в социуме.

Далеко не со всеми людьми хочется вести хоть какое-то общение, тупо из-за того, что им просто плевать на тебя.

https://www.recurse.com/social-rules

Зачем нужны паттерны проектирования

На собеседованиях их довольно часто спрашивают, очень часто применяют в ООП-like Java/C#/C++, конечно же функциональные паттерны, но действительно ли от них много толка в реальной имплементации задач бизнеса?

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

Я хочу описать еще одну крайне важную причину. Возможно, эта причина важнее всех остальных, хотя знатоки в подписчиках придут и поправят меня в комментариях, если я не прав.

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

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

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

Звучит конечно логично, но на практике достичь этого идеала не получается. Java превратила эту идею в догму, поэтому мы зачастую видим AbstractFactoryBuilderAdapter. Разумеется, он решает свою задачу, но теперь он крайне далеко от предметной области, которую мы собственно пытаемся моделировать.

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

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

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

Новый эпизод подкаста "Под куполом"
Архитектура и Feature Sliced


Зачем вообще использовать паттерны проектирования? Почему FSD не является архитектурой сама по себе? Почему я консультирую именно в экосистеме effector? Как научиться писать код?

Подписывайтесь на Youtube:
youtube.com/@sova

Выпуск можно послушать: Google, Yandex, Spotify, Apple.

https://podcast.sova.dev/episodes/feature-sliced-and-architecture-patterns

Причина по которой effector плавно переходит к sample для любых задач.

Даже $store.on() это далеко не самый удобный способ описывать бизнес-логику в коде.
Если бы я описал код выше через $store.on(), то в момент, когда мне понадобилось бы добавить условие, пришлось бы полностью заменить блок .on() на sample.
А так, в diff увижу изменения только одной строки.

Приятного вечера 🧡

Ребята, не все потеряно!

Выпущу портянку:
Про дефолты

Почему плохо
- У всех есть автоимпорт
- Переименование не гарантирует переименование импортов
- В целом, работа с именами дефолтных импортов - магия
- Возможность экспортировать анонимные функции
- Возможность указать любое имя при импорте значения
- В случае множественных импортов создается неконсистентность
- Многострочность
- Отсутствие строгости нейминга -> дубликаты имен

Почему именованые экспорты
- Гарантия корректности нейминга (TS)
- Унификация экспортов, отсутствие когнитивной нагрузки для принятия решения
- Лучшая читаемость, особенно при множественных экспортах (хотя это больше про export const foo vs export { foo } ) - для изменения значения не нужно скроллить туда-сюда, чтобы понять, экспортируется ли оно
- Public API
- Мы всегда можем увидеть, что экспортирует модуль без необходимости лезть внутрь
- Полная явность и открытость содержимого модуля
- Автокомплит
- Реэкспорты без алиасинга
- dynamic imports (кроме React.lazy/dynamic из некста)

Когда хорошо
- Библиотечный экспорт (те же реакт/лодаш)
- Специфичные потребители
- Требования фреймворков/библиотек (напимер, страницы в NextJS)
- Финальные компоненты для lazy динамик импортов
- Конфиги/схемы/etc. в том случае, когда их будет потреблять сокрытая автоматика (webpack, next, tailwind, etc.)

Ссылочки
Обзорные статьи (и канал в телеге хех) с аргументацией отказа от дефолтных импортом
- https://humanwhocodes.com/blog/2019/01/stop-using-default-exports-javanoscript-module/
- https://basarat.gitbook.io/typenoscript/main-1/defaultisbad
- https://news.1rj.ru/str/why_not_export_default
- RFC в гитлабе (там тоже был полный разворот от "только default" к "только named") - https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/20
Стайлгайды
- GitLab - https://docs.gitlab.com/ee/development/fe_guide/style/javanoscript.html#es-module-syntax
Google - https://google.github.io/styleguide/jsguide.html#es-module-exports

Делаете ли вы личные проекты по утрам?

Я вот решил податься в код-ген в стиле Unreal Blueprints.