#.net #projects-and-solutions
#.net #проекты и решения
Вопрос:
Ниже вы можете увидеть мою текущую структуру проекта. Но я не до конца доволен этим. Основная проблема заключается в том, что я не знаю, куда девать тестовые проекты.
Судя по названию, логично было бы поместить YML.Tests в папку YML. Но в этом случае я смешаю структуру проекта YML и папку проекта YML.Tests (это не критично, но мне это не нравится).
Другой способ — переименовать YML.Tests в YMLTests, и тогда будет меньше причин помещать YMLTests внутрь YML. Но тогда я захочу объединить YML и YMLTests в одну папку. И я должен придумать, как это назвать. YML? Тогда проект YML будет находиться внутри еще одной папки YML.
Хм… Есть идеи, как сделать это лучше?
Комментарии:
1. Почему для начала YML и YML.Tests находятся в папке «Feed»?
2. Потому что YML является стандартом подачи. Таким образом, в папке Feeds будут разные реализации поддержки каналов
3. @Idsa: Но это все разные проекты, верно? Я стараюсь поддерживать все свои проекты на верхнем уровне в рамках решения. Также не ясно, почему вы недовольны структурой в ее нынешнем виде.
4. Мне не нравится, когда какой-то проект и его тестовый проект находятся на одном уровне иерархии. Более того, иногда у меня есть два тестовых проекта для одного модуля: еще один тестовый проект для длительных тестов.
5. @Idsa: Почему тебе это не нравится? Это оба проекта, поэтому в этом отношении они равны друг другу. То, как вы сейчас это настроили, — это то, как я бы это сделал. Если вам нужен отдельный проект для длительных тестов (вместо простого использования категорий и т.д.), Вы можете просто настроить третий проект.
Ответ №1:
Организационная структура проектов в вашем решении должна быть разработана таким образом, чтобы максимизировать вашу производительность при работе в решении. Некоторые из факторов, влияющих на вашу производительность, — это размер проекта, логическая группировка и простота навигации.
В данном случае, я думаю, вы боретесь с двумя разными конкурирующими организационными концепциями:
- организация по функциям программного продукта (каналы, экстракторы и т.д.)
- организация по функциям разработки программного обеспечения (внедрение, тестирование и т.д.)
В результате вы могли бы создать отдельное дерево тестов, которое не «загрязняет» ваше дерево реализации, но это может создать большую проблему для удобства навигации, если вы будете постоянно переключаться между реализацией и тестированием для одной и той же области функций.
В конце концов, любая организационная структура вынуждена идти на некоторые компромиссы, но, учитывая, что вы, похоже, серьезно относитесь к разработке на основе тестирования, я думаю, что предложенная вами организация довольно хороша. Он широко используется, и хотя у него есть свои недостатки, он работоспособен и продуктивен для разработки в повседневном использовании.