Каковы принципы организации кода C ++ в Visual Studio?

Я опытный разработчик C ++ на новой должности. Мой опыт работы с * nix системами, и я работаю с Visual Studio впервые.

Я нахожу, что я постоянно борюсь с Visual Studio за вещи, которые я считаю тривиальными. Я чувствую, что я не прогнал, как я предполагаемый использовать VS; поэтому я стараюсь делать вещи «как я привык», что приводит меня в неловкое положение: неловкие обходные пути, потерянное время и постоянное разочарование. Мне не нужен учебник VS 101; что мне нужно, так это какое-то руководство по конвертации — «Вот способ VS делать вещи».

Это мой общий вопрос — «Как VS делать вещи?». Это может быть немного расплывчато, поэтому я опишу, что дает мне горе. В идеале я не ищу «Вот конкретный набор шагов, чтобы сделать эту конкретную вещь», а скорее «Вы ошибаетесь; вот термины и концепции, которые вам необходимо понять, чтобы эффективно использовать VS».

В C ++ я привык иметь большой контроль над организацией кода и процессом сборки. Я чувствую, что VS сильно работает против меня здесь:

• Я настоятельно склонен писать маленькие, изолированные строительные блоки, а затем большие куски, которые соединяют эти блоки в различные комбинации.
  • В качестве тривиального примера для данного подразделения или проекта я подчеркиваю, что между заголовками подразделений, предназначенными для включения клиента, существует сильное разделение; фактическая реализация подразделения; и любой код тестирования.
  • Скорее всего, у меня будет несколько разных тестовых проектов, некоторые из которых, вероятно, будут опираться на общий тестовый код (помимо самого тестируемого кода).
• VS делает обременительным фактически контролировать местоположение кода. Если я хочу, чтобы код проекта был разделен на include/ папка и src/ папка, это теперь серьезная проблема.
• Насколько я могу судить, концепция VS «проектов» кажется чем-то средним между тем, что я считаю «конечной целью сборки» и «промежуточной целью сборки». Насколько я могу сказать, в основном все, что я хочу разделить между несколькими проектами, должно также быть проектом.
  • Но если многие промежуточные объекты теперь становятся проектами, то я внезапно оказываюсь в тонне небольших проектов.
  • И управление кучей небольших проектов невероятно расстраивает. У каждого из них есть миллион настроек и определений (в разных конфигурациях и на разных платформах …), которые очень сложно перенести из одного проекта в другой.
  • Это побуждает меня объединять много несвязанного кода в одном проекте, чтобы уменьшить количество проектов, которыми я должен управлять.

Я борюсь с этим постоянно. Я могу найти решения для любой конкретной вещи, но для меня ясно, что мне не хватает более широкого понимания того, как Visual Studio как инструмент означало использоваться. Назовите это правильным рабочим процессом или правильной организацией проекта — любые решения или советы могут мне помочь.

(Замечания: как бы мне ни хотелось, «перестать работать с компоновочной цепью Visual Studio» на данный момент не вариант.)