Контроль версий, мерж/пул-реквесты и работа в команде

Общие принципы, проектирование, модуляризация, темплейты и шаблоны
Ответить
kichay.d
interested
interested
Сообщения: 2
Зарегистрирован: 11 июл 2022, 20:20
Версия LabVIEW: 2021
Благодарил (а): 1 раз
Поблагодарили: 1 раз
Контактная информация:

Контроль версий, мерж/пул-реквесты и работа в команде

Сообщение kichay.d »

Всем доброго дня.

Заинтересовал меня вопрос об организации командной работы над проектом, представленным в виде G-кода. Предположим:
1. Проект представляет из себя набросок алгоритма в виде некоторой шаренной библиотеки (dll/so), функии которой подключают в какой-то конечный продукт на стадии обкатки алгоритмов.
2. Обкаткой алгоритмов занимается несколько человек одновременно, среди них есть как новички, так и бывалые.
3. Внутри команды хотелось бы обсуждать применяемы решения, критиковать их итд...

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

Как я понимаю, для нахождения diff старой и новой версии внутри VI нужно:
1. Графическое представление объектов на диаграмме со связями как-то представить в виде кода (получить, например, UML Component Diagram в формате yaml)
2. Получить классический "текстовый" diff для текстового представления
3. Перестроить VI так, что бы каждое изменение полученное по diff было внесено в case структуру управляемую константой boolean (что бы можно было листать кейсы и смотреть, что было, и что стало)

В связи с моим предположением у меня вопросы:
1. Есть ли что-либо готовое со сторона NI для командной работы?
2. Есть ли вариант экспорта VI в какой-либо документированный формат?
3. Есть ли какие либо варианты импорта в LabVIEW из документированных форматов?
Аватара пользователя
Kosist

Activity Gold
expert
expert
Сообщения: 1226
Зарегистрирован: 21 фев 2011, 23:44
Награды: 2
Версия LabVIEW: 2013-2020
Благодарил (а): 23 раза
Поблагодарили: 29 раз
Контактная информация:

Re: Контроль версий, мерж/пул-реквесты и работа в команде

Сообщение Kosist »

kichay.d писал(а): 11 июл 2022, 20:55 Хотелось бы обеспечить как-то возможность контроля версий для проекта по аналогии с git, как минимум для возможности ведения нескольких веток продукта, возможностей слияния веток и хоть какого-то ревью. Какие варианты тут можно предположить?
Если нужна аналогия git - гросто используйте git. Git - это софт для контроля версий. Плюс, в зависимости от git сервера, можно добавить "плюшки" для более удобного ведения разработки.
kichay.d писал(а): 11 июл 2022, 20:55 1. Графическое представление объектов на диаграмме со связями как-то представить в виде кода (получить, например, UML Component Diagram в формате yaml)
2. Получить классический "текстовый" diff для текстового представления
3. Перестроить VI так, что бы каждое изменение полученное по diff было внесено в case структуру управляемую константой boolean (что бы можно было листать кейсы и смотреть, что было, и что стало)
UML генератор есть, но он подходит для ООП-шных проектов. Логические связи внутри виаек им не построить.
В :labview: уже есть тула для графического сравнения кода Compare VIs и Merge VIs. Также, есть статьи на форумах/блогах, как их интегрировать в git клиент.
По своему опыту скажу - помогают слабо. Успех совместной работы над проектом - это умение разбить код на отдельные блоки, которые не связаны между собой. Таким образом, можно смело редактировать виайки не боясь конфликтов. А уже за связку компонентов отвечать должен один разработчик. Шансы создать конфликты есть, но потом они довольно малы, и конфликты можно решить проще.
3 пункт - вообще непонятен, и если даже будет реализован, внесет хаос. Структурируйте код правильно, и будет счастье. Если нужно временно скипать код - используйте Disable Structure, или Conditional Disable Structure.
kichay.d писал(а): 11 июл 2022, 20:55 1. Есть ли что-либо готовое со сторона NI для командной работы?
2. Есть ли вариант экспорта VI в какой-либо документированный формат?
3. Есть ли какие либо варианты импорта в LabVIEW из документированных форматов?
1. У NI продукта такого нет. Git в помощь.
2. Можно написать свой парсер виайки в другой формат. Но вопрос - зачем? Все кейсы все равно покрыть будет очень тяжело, и в итоге такой парсер не будет использоваться.
3. Готовых решений нет. Опять же, можно писать свою тулу - но это долго, нудно, и тяжело.

Я работал в комманде, и мы делали маленькие и большие проекты, активно используя git. При правильном построении кода, соблюдении принципов SOLID - проблем нет. Поверьте, пункты 2 и 3 Вам не нужны для работы.
Мы делили апельсин - много наших полегло...
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «Модели программирования»