Как организовать источники сложной программы? - PullRequest
3 голосов
/ 21 декабря 2009

Мы создаем очень сложную встроенную систему, и «исходники» содержат несколько проектов схем и печатных плат Visual C ++, IAR, Code Composer Studio и Altium Designer. Все это, возможно, может быть в нескольких версиях. Итак, какую практику вы могли бы посоветовать мне организовать все это? Спасибо

Ответы [ 7 ]

4 голосов
/ 21 декабря 2009

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

3 голосов
/ 21 декабря 2009

У меня такая же настройка, как и у вас.

Я использую Altium Designer для схем аппаратного обеспечения и проектирования печатных плат. Но у меня также есть исходные файлы прошивки и связанные утилиты. И у меня есть файлы механического дизайна.

Вот как я это делаю:

Project Name
    Firmware
        MainCpu
            trunk
            tags
            branches
        IoCpu
            trunk
            tags
            branches
    Hardware
        MainPcb
            trunk
            tags
            branches
        IoPcb
            trunk
            tags
            branches
        PowerPcb
            trunk
            tags
            branches
    Mechanical
        Chassis
            trunk
            tags
            branches
        Other
            trunk
            tags
            branches

Таким образом, все файлы проекта хранятся вместе в репозитории SVN. Единственный недостаток, который я обнаружил, это то, что вы не можете просто проверить Проект и получить последние файлы FW / HW / MEK. Вы должны проверить каждую голову FW / HW / MEK.

Причиной для отдельных подмодулей для FW / HW / MEK является то, что они получат отдельные теги версий.

2 голосов
/ 21 декабря 2009

Если ваши исходные файлы на C ++ многочисленны и охватывают несколько каталогов, то усилия, приложенные к созданию гроккинга Large Scale C ++ Software от John Lakos, могут стоить того. Основная тема книги - то, как ваша физическая структура программного обеспечения, то есть расположение файлов исходного кода в каталогах, ограничивает или расширяет ваши возможности по модификации программного обеспечения.

1 голос
/ 21 декабря 2009

Мне нравится иметь структуру каталогов, которая на верхнем уровне отражает каждую из программируемых частей (например, микроконтроллер, DSP1, FPGA1, FPGA2, ...)

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

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

0 голосов
/ 21 декабря 2009

(кроме простых вспомогательных классов) поместите по одному классу в каждый файл cpp / h и назовите файлы cpp / h такими же, как у класса.

Группируйте связанные файлы классов в папки (вы можете по желанию использовать иерархию пространств имен, которые соответствуют структуре папок. Подход .net здесь заключается в использовании пространства имен CompanyName.ProductName, при этом ваши файлы хранятся в проекте / подпапке ProductName вашей решение). Например, вы можете сгруппировать классы Math, I / O и Drawing в отдельные папки «подсистем».

В идеале, превратить эти отдельные разделы в библиотеки многократного использования (MyCompany.Math). Вы будете рады этому позже, когда захотите разработать новый продукт, который поделится частью кода. В этом случае «папки» верхнего уровня сами по себе становятся отдельными проектами, и вы можете начать работу по минимизации зависимостей между ними, чтобы реализовать, а затем реализовать гораздо лучший общий дизайн структуры в вашей кодовой базе.

Идеально в папках найти хороший баланс между беспорядком и разреженностью - старайтесь сбалансировать папки так, чтобы в них было по 5-15 файлов в каждой. Если меньше, рассмотрите возможность объединения папок; если больше, рассмотрите возможность добавления папок подкатегорий, чтобы уменьшить сложность.

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

Рискуя начать религиозную войну, я предпочитаю помещать заголовки и их исходные файлы в одну папку, чтобы при редактировании .cpp файл .h был легко доступен, а не перемещаться вверх и вниз по папка все время.

0 голосов
/ 21 декабря 2009

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

Что касается того, как упорядочить ваши файлы, я заметил, что в вашем списке есть Altium Designer, эта программа будет а) хорошо играть с контролем исходного кода и б) упорядочивать ваши файлы упорядоченным образом, если вы используете их целиком Файловая структура проекта. Рассмотрите возможность использования их «печатных плат» (если это то, что вы делаете) или «встроенных» проектов, когда вы создаете один, он создает контейнеры для хранения всех ваших различных типов файлов.

Даже если вы не хотите использовать Altium для своих файлов, создайте проект и посмотрите на их структуру каталогов, чтобы получить представление обо всех файлах, которые вам нужно отслеживать.

0 голосов
/ 21 декабря 2009

Уменьшите сложность!

У моего первого профессора-инженера была знаменитая первая лекция. Он состоял из одного уравнения, написанного на доске:

Совершенство = Простота

Проблема с системами контроля версий заключается в том, что они управляют сложностью, а также способствуют ее развитию.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...