[ARCHIVED] Переиспользуемые модули: куда класть?

[azinit]

Разработчики любят часто класть модули в shared, даже если они тривиальны или используются один раз - и в этом проблема

---

Мы, как разработчики, постоянно по работе пишем вспомогательные модули для проекта: компоненты, либы/хелперы и т.д.
Но отдельный вопрос - в каком месте из структурного дерева они должны располагаться?

Есть две крайности

1. Выносить все побочное сразу в shared

   "Я хочу, чтобы мой модуль (ui/lib/...) мог использоваться другими разрабами, и потому я выношу все побочные компоненты / хелперы сразу в shared/common"

   Плюсы / Минусы

   • 🟩 Если логика реализована один раз, она точно не потеряется для других разработчиков

   • 🟥Таким образом shared-папка разбухает, и в ней может лежать куча лишних реализаций

   • 🟥 Если мы сразу выносим модуль в shared (да и в принципе вниз по абстракциям), то его становится опаснее редактировать

     Гораздо предсказуемее эффект, если бы этот модуль лежал рядом с местом использования

   • 🟥 Сложно кастомизировать эту логику под случай, т.к. она "одна для всех использований"

2. Располагать все побочное максимально близко к месту использования

   "Я не выношу в shared - вещи, используемые один раз, или если они тривиальны по реализации. Лучше я расположу такие модули рядом с местом использования"

   Плюсы / Минусы

   Реверсивно с п1

   • 🟥 Из-за того что вся логика располагается на уровне использования - другие разработчики могут ее пропустить, из-за чего возможно будет несколько реализаций одной логики в проекте

     Но справедливости ради - если будет куча лишнего мусора в shared - то логика тоже может затеряться

   • 🟩 В связи с этим, в shared будет лежать действительно только то - что "переиспользуемо" и "нетривиально по реализации"
   • 🟩 Также, при таком подходе легче модифицировать сам модуль

     Повышается предсказуемость, т.к. изменения повлияют только на само место использования

   • 🟩 Т.к. логика чаще всего "уникальна для каждой фичи/страницы/..." - то такие модули легче кастомизировать под конкретное место использования, нежели они были бы в shared

Поэтому, лучше искать некий компромисс между подходами, чтобы было можно заметить сильное дублирование логики, и в то же время - не забивать shared лишними абстракциями

---

Oleg Isonen в своем React Berlin Talk отлично высказался по проблеме

Изменение shared-кода с 100% покрытием все равно что-то может сломать
Т.к. вы не можете знать, как будет использоваться ваша библиотека (потому сложно изменить библиотеку без последствий)

Когда стоит выносить в shared?

• Если используется минимум в 2 местах

  До этого - должно быть локально

• Содержит нетривиальную логику

  Иначе - это может быть легко скопипасчено локально

• Низкая вероятность изменений

  Если фича обновляется очень часто, то и этот модуль будет изменяться также часто - по итогу модуль не будет стабильным

[azinit]

Из последнего внутреннего обсуждения комитета (про shared и DRY)

@martis-git
Скорее упор на "уникальность функции", DRY - чаще как антипаттерн (хорош, но без фанатизма)

Т.е. функционал может немного повторяться, но за этим желательно следить, а также при реализации проверять наличие похожих модулей в shared или в features (по ключевым словам)

@sergeysova
DRY приветствуется без фанатизма, только для уменьшения кода необходимого к покрытию тестами.

Если следовать методологии и именованию, можно легко находить уже существующий код и внедрять новый

[azinit]

Лично мне кажется, что лучше действительно "располагать рядом к месту использованию", но с регулярными проверками - а есть ли где-то уже похожая реализация?

И выносить в shared - только в самый самый последний момент - когда не удается сдержать модуль в изоляции фичи/страницы и т.д.

Ну и про критерии от Oleg Isonen в основном посте - не стоит забывать

[mindyourlifeguide]

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