Когда Вы решаете разделить крупные проекты на меньшие проекты?

У меня всегда есть несколько проектов (и, следовательно, решение), а не один проект со всем моим исходным кодом.

В некоторых случаях это неизбежно, потому что вы используете библиотеку с открытым исходным кодом и хотите иметь возможность отлаживать ее. Но, если говорить более прагматично, мои приложения обычно предоставляют функциональность через плагины. Это позволяет мне изменять поведение или предлагать выбираемое пользователем поведение во время выполнения. В случае отсутствия плагинов это позволяет вам обновлять одну часть вашей программы, не обновляя все. Также есть случаи, когда вы, по-видимому, можете предоставить основное и загружать модули / сборки только тогда, когда они вам нужны.

Еще одна причина заключается в том, что вы можете создавать меньшие тестовые приложения для проверки сборки, а не создавать очень большое решение и потенциально требовать от пользователя выполнения нескольких (и не относящихся к делу) операций с графическим интерфейсом пользователя, прежде чем даже достигнет части, которую вы хотите протестировать. И это не просто проблема тестирования - возможно, в вашей организации есть менее сообразительные пользователи, которые хотят, чтобы им были представлены только те части, которые их беспокоят.

Когда общая цель проекта остается прежней, но количество классов становится большим, я стараюсь создавать папки и пространства имен для улучшения групповой функциональности внутри проэкт. Классы, которые связаны друг с другом, как правило, находятся в одной папке / пространстве имен, поэтому, если мне нужно понять данный класс, связанные классы находятся рядом в обозревателе решений.Обычно я создаю новые проекты только в том случае, если понимаю, что конкретная часть функциональности сильно отличается по назначению или если существует общая зависимость между существующими проектами.

Я обычно заканчиваю несколькими относительно небольшими проектами Framework, которые определяют интерфейсы для слабой связи между другими проектами, с более крупными проектами для различных типов конкретной функциональности. Это всегда как минимум один проект для пользовательского интерфейса и один проект для логики и данных (часто делятся на два проекта, если уровень данных сам по себе становится очень большим).

Проекты должны быть связными . Логика должна быть взаимосвязанной и достигать аналогичной цели

. Этот ответ будет зависеть от размера продукта, который вы поддерживаете. В целом мы организуем наши проекты по предметной области и логике. И мы разделим их еще больше, чем больше вы разделяете, тем более организованным вы должны быть, иначе вы столкнетесь с ужасной проблемой рекурсивной зависимости.

Когда я решаю разделить проект, это происходит тогда, когда он становится слишком большим или две области становятся слишком похожими.

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

Возможность повторного использования - еще один отличный момент, чтобы сократить количество строк кода, а также представить новый проект. Однако будьте осторожны с тем, сколько «служебных» библиотек вы вводите, потому что они действительно влияют на удобочитаемость / понятность.

Я не думаю, что есть линия на песке, которая говорит, что если вы наберете 3k SLOC, у вас будет слишком много. Все контекстно.

Я перемещаю код в новый проект, если он имеет общие функции (теоретически), которые можно использовать и в других проектах. Если проект большой, потому что он представляет собой сложную проблему, то пространства имен предоставляют отличный способ навести порядок в коде. Здесь вы можете, например, ввести (под) пространства имен для каждой таблицы SQL и т. Д. И т. Д.