Тем временем в Сообществе effector появились две статьи

- Лучшая часть effector
- Инструкция по тестированию

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

Тут в комментах Владимир процитировал Фаулера, а я заметил в цитате старую проблему с пониманием S из SOLID. Забавно, как долго Мартин пытается объяснить, что имел ввиду совсем другое, и как столь же долго практически вся индустрия отказывается принять изначальную трактовку и идёт по более простому пути. Обратимся к Мартину:

===============
«Из всех принципов SOLID наиболее трудно понимаемым является принцип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соответствующего сути. Услышав это название, многие программисты решают: оно означает, что каждый модуль должен отвечать за что-то одно.

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

Традиционно принцип единственной ответственности описывался так:

Модуль должен иметь одну и только одну причину для изменения.
…
Фактически принцип можно перефразировать так:

Модуль должен отвечать за одного и только за одного пользователя или заинтересованное лицо.
…
Окончательная версия принципа единственной ответственности выглядит так:

Модуль должен отвечать за одного и только за одного актора»

Чистая архитектура. Искусство разработки программного обеспечения
Мартин Р.
===============

Почему так случилось и почему изначальная трактовка важна? Для меня весь SOLID это прежде всего архитектурные принципы. Мы задаём границы, описываем правила их пересечения, направление движения данных и контракты. На этом уровне восприятия нас не волнует размер и сложность функций и классов, мы проектируем систему. И в контексте архитектуры системы S (в изначальном понимании Мартина) — очень важно.

Конкурс!

Мы разыгрываем два билета на Summer Merge 2022!
Ниже будет описание конференции, а сейчас я расскажу как бесплатно получить билет.

Чтобы получить билет нужно написать статью об effector☄️ или законтрибьютить в репозитории.

Подойдут платформы dev.to, medium, community.effector.dev и другие популярные. Если статья для вас это слишком сложно, а отдохнуть на Волге всё же хочется, спешу обрадовать, подойдет любой приятно написанный текст об effector и его преимуществах. Размер не так важен)

Также можно отправить PullRequest с новыми тестами, исправлениями или фичами в любой из репозиториев github.com/effector. Подобрать подходящие issue можно по лейблу good first issue.

Core-команда effector выберет 2 лучшие работы и вручит билеты!
Чтобы поучаствовать нужно выполнить условие выше, отправить ссылку на свою работу ответом на этот пост в канале Effector News до 20 августа!

———

Антиконференция Summer Merge 2022 - та самая летняя айти-тусовка, где соберутся все, чтобы вырваться из рабочей рутины, поболтать со старыми друзьями и как следует проводить лето ☀️

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

Если вы тоже устали от офиса и мечтаете отвлечься хотя бы на пару дней, тогда встречаемся 26-28 августа в эко-парке «Русский берег» 😉