круть 👍

закину туда рефакторинг последней главы

@ZeroBias мержай как будешь готов

замержил

☄️

🤔

напоминаю, что права доступа в репозиторий даются, чтобы не тратить время на согласования)

принято. Но ревью мне нужно

Господа, подскажите пожалуйста хорошие статьи по DX

статьи тут не помогут, нужно профильные книги читать

Я не против книг = ) ПРосто для меня совершенно новая тема, не знаю куда копать. Может есть на примете что-то что запомнилось?

Я могу скинуть свою мысль вступительную, которую писал к презентации по эффектору

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

Приходя на работу, у многих проскакивала мысль, что они занимаются не тем. Что  прокидывание пропсов и подключение к стору компонентов, в совокупности с написанием бесконечного, бессмысленного, бойлерплейта не приносит удовольствие. Что логика в компонентах уже на столько размазана по проекту, что отключается восприятие реальности. Каждая новая фича или баг-трекинг начинается с распятия и заканчивается повешением всего отдела разработки. Вот так всё плохо. Я думаю, вы, понимаете о чем я говорю. Использование в проекте Redux и его экосистемы. Куча, по-моему мнению, бесполезных либ и решений, которые не решают проблемы, а решают проблемы Redux. Пока отложим это и пойдем дальше.

Так вот, все плохо, нужно кардинально что-то менять. В нашем случае, Я буду говорить о том, как разработчики могут улучшить свой DX, это во первых, а во вторых, как мы сможем улучшить разработку фич и их поддержку, чтобы ПМ не сидел на антидепрессантах.

Начну с DX. DX - Developer Experience - такой опыт, который влияет на продуктивность, мотивацию, заинтересованность разработчика. Разработчик получает этот опыт при взаимодействие с проект. Сложно втащить новую фичу (негативный), нет документации (негативный). Легко развернуть проект (позитивный), Нет проблем обновлением зависимостей, закрытием задач.

Позитивный DX дает такие вещи как:

- Легко ввести нового человека в разработку
- Разработчики не стараются сменить рабочее место побыстрей
- Больше мотивированы и продуктивны
- Реализовать фичу больше не оккультный обряд
- Баги решаются за условные 15 минут
- Рефакторинг не начинается с созданием нового репозитория

Т.е такие вещи, которые не несут убытки бизнесу и ПМ перестает пить таблетки или просто пить, т.к сроки больше не горят.

Теперь про бизнес. Это второе. Почему он идет вторым? Сначала надо было рассказать, про DX, чтобы дальше не объяснять, почему разработчики меняют работодателей и проекты. Мы люди, не роботы, пока что :). Мы можем выгорать, поэтому это очень важно, иметь позитивный DX проекта.
Как же смена инструмента поможет бизнесу?

Т.к взаимодействие бизнеса и разработчика происходит непосредственно через постановку задач. (то как задача поставлена так она и выполнена, нене, не об этом)

Бизнес требования описываются в виде какого-то сценария или пользовательской истории, которую нужно реализовать в приложении. И вот то, как бизнес требование написано в самом приложении и помогает бизнесу быть на плаву. Добавлять, изменять, удалять, прорабатывать концепцию

DX повышается, UX не изменяется. Идеальная абстракция

ммм?

Я к тому, что решение проблем девелопера не должно заставлять пользователя страдать. Эффектор в этом плане прям идеален

ааа

Так оно и есть

Поэтому тут многие и топят, чтобы в View не было логики