#РазрабошнаяЧитает #SoftwareDesignPhilosophy Глубокие модули В предыдущей заметке, посвященной сложности, накапливающейся в программных системах, мы проговорили, что ключевыми причинами этого явления автор книги считает: - злоупотребление зависимостями; - неочевидность или полное отсутствие необходимой информации о системе. Звучит классно и очень логично, однако, без примеров не понятно, где именно начинается это самое злоупотребление? Неужели теперь каждый новый пакет считать будем? Да и по необходимой информации сразу так и не скажешь, какая именно информация нужна, и на сколько она очевидна) Давайте разберёмся на нескольких модельных примерах. - Необобщённый интерфейс. В репозитории над таблицей Users были добавлены методы SearchByName и SearchBySurname, etc., по одному поисковому методу на каждое интересующее поле. И вот настал тот самый момент, когда нужно искать пользователей и по имени и по фамилии. Получается, потребителю теперь нужно добавить новый метод, ищущий по двум полям? Или вызывать сразу два, а потом вычислять пересечение результатов в памяти? Как автор видел дальнейшее развитие репозитория? - Не приоритизированные сценарии использования. Для группировки данных на проекте применяется единственный метод, сигнатура которого принимает и селектор ключа и компаратор для ключа и проектор результатов и много чего ещё. Да, с таким методом можно реализовать любой сценарий группировки, однако вызывающий код вынужден в большинстве случаев слать кучу дефолтов вместо ненужных параметров. И хорошо, если значения для них очевидны, а что если нет? - Мелко нарезанная логика. Однажды в процессе рефакторинга было принято решение разделить один большой 200-строчный класс на 15 маленьких классов, использующих друг друга. Звучит классно, однако что если в получившуюся конструкцию потребуется внести правки? Не простая задача, особенно когда вместо одного стройного куска логики перед глазами клубок вызовов с пространными сигнатурами. - Мелко нарезанные данные. Мелко нарезать можно не только логику но и данные, в микросервисном мире это даже настоятельно рекомендуется. В принципе, можно даже дойти до того, что в базе каждого из сервисов лежит только одна таблица) Тогда каждый раз, когда нужна более или менее сложная выборка нужно сделать... что? Ходить в несколько сервисов и потом объединять результаты запросов в памяти? Создавать агрегаторы данных и обращаться к ним? Идеи по этому поводу можно накидывать бесконечно) На первый взгляд кажется, что перечисленный кейсы не имеют ничего общего, но на самом деле это не так. Все их объединяет излишне мелкое дробление кода и отсутствие надлежащего обобщения скрывающих этот код интерфейсов. Поэтому автор предлагает использовать в каждом подобном кейсе один и тот же прием - организовывать код в виде глубоких модулей, каждый из которых скрывает большой объем самодостаточного кода за обобщенным интерфейсом. Скорее всего, организовать код подобным образом сходу не получится, поскольку это реально не просто. Чтобы держать планку качества автор предлагает делать как минимум два подхода к дизайну системы, ибо первое пришедшее в голову решение, как правило, не самое лучшее. И, даже если все сразу работает как задумано, при наличии времени не стоит останавливаться на достигнутом, это будет инвестицией, которая почти наверняка окупится в будущем. Какой бы классной не казалась техника глубоких модулей, она не способна полностью обеспечить нас информацией, необходимой для развития кусков кода, "у которых есть история". А о том, что автор предлагает с этим делать, поговорим в следующей заметке. Stay tuned) Подписаться | Чат