Как правильно и удобнее всего разрабатывать модульное ПО?

Question

[Lapish72]

Разрабатываю один решение, состоящее из 25 связанных между собой проектов. Проекты — несколько .exe и 95% библиотек. Все это взаимосвязано и более-менее разнесено по слоям. Решение по мере развития находилось в одном репозитории с двумя origin ветками main, dev и иногда несколькими локальными. Сейчас перестраиваю решение и из 25 проектов будет ~35 и ~30к строк кода суммарно. Все это изначально раскладывал по папочкам насколько это возможно, но уже ощущаю неудобства при работе с таким количеством проектов.

Можете поделиться вашим опытом, как лучше организовать работу с десятками модулей, если работа ведется в одного? Одно из требований — частое изменение части кода любого модуля.

Я погуглил решения данных проблем и нашел 3:
1) Nuget Насколько я понял это самый лучший вариант для .net. Добавил локальный сервер, опубликовал пакет и вручную его скопировал в папку, поменял версию. Да, круто, что в решении не 30 проектов, но каждый раз публиковать, менять версию? Через тот же GitHub видел настраивают CI/CD, но я же могу с 10-го раза исправить что-то и мне теперь 10 раз пушить изменения? А как дебажить такой пакет?

2) SubModule. Очень понравилась эта идея, но насколько понял в ней есть главный недостаток — лавинообразное обновление версий подмодуля, если один зависит от другого, а тот еще от другого. И я не понял, можно ли репозиторий до локальной версии подмодуля, который изначально был добавлен через удаленную.

3) SubTree. Здесь столкнулся с проблемой, что внутри одного subtree был другой. Может я что-то сделал не так. Подробнее написал на SO: https://ru.stackoverflow.com/questions/1543339/%d0...

Структура проекта

Скриншот двухнедельной давности. Решение — клиент-серверное приложение (signalr) и очередная попытка создания луковичной архитектуры, но слои все же протекают. У клиента и у админа есть 4 главных блока (OS, Drive, Network, Hardware)
1) Apps — .exe файлы
2) Core.
Core.Domain — сущности клиента (ef).
Core.Application — базовые модули, совсем базовые сервисы (не связанные с UI) для админа и клиента.
Core.ServerApplication (не самое лучшее название, наверное) — общие модели между сервером и админом.
3) Infrastructure.
Infrastructure.Common — базовые сервисы, стили, хелперы, сервисы, но уже на уровне WPF. Использует и клиент и админ.
Infrastructure.Admin/Client — базовые вещи как в Common, но для модулей(далее) админа/клиента.
Infrastructure.Hardware/Network/OS — вынесение общих view, конвертеров между клиентом и админом.
4) Modules - Prism модули
Modules.Admin/Client — главные окна, инициализация приложения зависит от Modules.Admin(Client).Common.
Modules.OS/Drive/Network/Hardware — сервисы, view специфичные для админа/клиента

Проекты Admin/Client максимально пустые и состоят из нескольких файлов. Они добавляют все prism-модули и отдают инициализацию в Modules.Admin или Modules.Client.

P.S.
Сейчас решение большое и есть небольшой дискомфорт, но я могу перемещаться между проектами и изменять их.

Comments

[Kentavr16]

И прямо одновременно с несколькими нужно работать? Или в текущий момент не до конца ясна вся функциональность каждого модуля? Это сильно - 25 в 30 переписывать самому )

[Lapish72]

И то и то. Где-то подрефакторить, где-то баг подправить.

Answer 1

[Василий Банников]

25 проектов в решении - это вполне нормальное количество и ничего особенного с этим делать не нужно. (Видел решения, где их под сотню).
Хотя не исключаю вариант, что на самом деле такое разделение излишнее.

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

Лучше попробуй конкретизировать, как именно проявляется неудобство - тогда и будет вариант решения.
Подумай, почему у тебя вообще столько проектов?
Можно ли их объединить? Если нельзя, то почему ты так думаешь?

PS: из текстового описания вообще не понятно, что такое "слои" и почему между ними нужно как-то перемещаться. Попробуй добавить в вопрос пример иерархии папок из твоего репозитория.

Comments

[Lapish72]

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

[Василий Банников]

Lapish72,

А как скролить и переходить по папкам/файлам, когда их 100?

1. В рамках решения можно разбивать проекты по папкам.
2. А по папкам и файлам обычно руками ходить не нужно. Если работаем с уже существующими классами - к нему можно перейти по имени. Если нужно новый создать - обычно логически достаточно быстро можно перейти к нужной папке. Опять же прямо в solution explorer есть поиск.

В общем это проблема сводится к у ению пользоваться своей IDE и раскладыванию файлов по папкам.

[Lapish72]

Василий Банников, добавил описание с картинкой. Ну максимум можно объединить код из Modules.Admin/Client и Modules.Admin/Client.Common в просто Admin/Client, но тогда будет не легковесный проект, а небольшой монстр :d Но даже если сделать так, то это -4 проекта ну и еще -1/2 проекта, но не более. Все равно будет 30+ с новыми функциями

UPD:
Модули OS/Drive/Network/Hardware чаще всего имеют всего 6 файлов. Возможно их можно было бы объединить в один и удалить 6 проектов, но иметь в одном проекте view/vm с совершенно разным смыслом не было бы нарушением SRP? Или SRP применяется только к файлу, а не к проекту/решению?

[Lapish72]

Василий Банников, и все же если бы вам надо было выбирать nuget/submodule или subtree, то что бы вы выбрали при разработке в одного с постоянным изменением 20 проектов? На ru SO мне не смогли дать внятного ответа(

[OwDafuq]

+1 к тому, что 20-30 проектов - норма, текущий проект на работе буквально сейчас состоит из 26 проектов, но у меня там всего 3 exe, а остальное - dll.
Каждая dll должна отвечать за свое, например у нас это: 1 - общие классы для ответов от API (несколько API отдают одинаковые ответы (по формату т.е.)), exception и прочие штуки, 2- библиотека для авторизации через JWT, общие настройки JWT, пр., 3 - Unit of Work (который сам состоит из 3 проектов) и так далее. Сделано это для того, что бы не тащить ненужное в проекты, нужен сервис генерации рандомной строк (как пример) - добавил 2 библиотеки (в нашем случае 2, потому что есть интерфейс и его реализация в другой библиотеке) и используешь его везде.
Поэтому ваши 20-30 проектов, если сделаны грамотно, то никаких сложностей не доставят, наоборот повышают (ИМХО) гибкость ваших проектов.

[Василий Банников]

Lapish72, нейминг проектов и раскладка по папкам точно кривые.

Предлагаю аналогию с хранением столов в разобранном виде.
Логично хранить все детали для одного стола в одной коробке.
При этом крепёж ещё в пакетик положить

А инструмент для сборки всех столов тоже в отдельный ящик

Сейчас у вас есть коробка, в которой хранятся столешницы для каждого стола, коробка для всех левых ножек и так далее.

Обычно именуют так:
ОбщийПрефикс.Приложение.Модуль.Итд

Раз у тебя три приложения, то должно быть три папки для каждого + папка для общих компонентов.

В рамках папки для каждого приложения должен быть собственно основной проект и проекты для каждого из слоёв.

Но выделять каждый слой в проект есть смысл только в двух случаях:
1. Если ты используешь модификатор internal для того чтобы запрещать протекание абстракций.

2. Этот проект может использоваться самостоятельно

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

[Lapish72]

Василий Банников переделал решение. 27 --> 37. Вроде поудобнее стало)

Клик