caxapa.ru :: Каждый проект - отдельно. Ни грамма "общего" кода. Если какая-то библиотека используется в двух проектах, она храниться в двух независимых копиях.

Cкpипaч, пророк (31.01.2022 15:39, просмотров: 158) ответил VLLV на Господа, как вы проектируете ПО для семейства приборов с разной функциональностью на разных контроллерах?

Каждый проект - отдельно. Ни грамма "общего" кода. Если какая-то библиотека используется в двух проектах, она храниться в двух независимых копиях.

... но не любой ценой.

Ответить

- Может хранить библиотеку в гите, а в проект фетчить конкретную ревизию библиотеки? - LightElf(31.01.2022 15:59)
  - Можно и так. Главное - никакое изменение "внутри проекта" не дожно иметь ни малейшего шанса повлиять на другие проекты. Cкpипaч(191 знак., 31.01.2022 16:10)
- Это точно тупик. Сейчас образовались два таких пакета для приборов с разными интерфейсами, и 50 процентов времени уходит на копирование изменений из одного пакета в другой :( - VLLV(31.01.2022 15:46)
  - Сколько из этих пресловутых 50% уходит на ТЕСТИРОВАНИЕ? :о) - Cкpипaч(31.01.2022 15:58)
    - Проблему "общего кода" решает система контроля версий. В каждом проекте используется своя проверенная с данным проектом версия библиотеки. Исправление ошибок и доработка библиотеки выполняется при этом в "одном экземпляре". А добавить эти исправления в старый проект можешь по своему желанию. il-2(1 знак., 31.01.2022 16:08, ссылка)
      - У каждого свой путь. Можно "контроля версий", а можно просто проектные папки. Которые тоже запихнуть под контроль версий, но в виде строго отдельных проектов. Cкpипaч(239 знак., 31.01.2022 16:16)
      - Просто проблема перейдет в другую плоскость - какую ревизию библиотеки использовать ? - VLLV(31.01.2022 16:13)
        
        Расслабься, умные люди уже за тебя все придумали :-) В Mercurial эта штука называется subrepositories, в git - submodules(могу соврать - поправьте). Нормальная система контроля версий сама следит, какая версия библиотеки (субрепозитория) будет привязана к текущему коммиту основного репозитория проекта. Так что на бумажке ничего не прийдется записывать :-) - il-2(31.01.2022 16:24)
        
        Работаю с external svn, про бумажку знаю :) Смотри, имеется два проекта. В одном проекте нужно поменять общую библиотеку, в другом не обязательно, не меняем. А потом вдруг нужно в той же библиотеке поменять для проекта, в котором не менялось. Выбор: то ли дробить библиотеки, то ли вводить ненужные изменения. В максиме Скрипача о раздельных проектах есть рациональное зерно, только у него проекты трудоемкостью не 5 человеко-лет. - VLLV(31.01.2022 17:07)
        
        Библиотеки (субрепозитории) у каждого проекта свои (как любит Скрипач). Но внешний репозиторий библиотек у всех проектов один. Через него и идет обмен. il-2(890 знак., 01.02.2022 05:56)
        
        Вот на этом: "не забывать обновлять" и надо отбросить этот способ - редко не забывает. - symbions(01.02.2022 08:18)
        
        Я использую оба способа. В старых проектах - первый (т.к. там исторически либы были скопированы в каталог проекта, а с недавнего времени делаю ссылки в новых проектах. Дискомфорта не наблюдаю. Может потому, что при переключении на другой проект, первое и естественное движение - это глянуть в его репозиторий, чтобы узнать какой коммит в данный момент в рабочей директории. - il-2(02.02.2022 05:49)
        
        Нет. ПРосто Вы очень собранный и самодисциплинированный человек. Тут в институте ввели цифровую подпись, на каждом собрании говорили, что имя файла после подписывания менять нельзя, иначе файл не откроется. И что? Как минимум 30% вторых подписантов подписывают файл не "подписать_отчёт.odt.p2s" а файл "подписать_отчёт.odt (1)" - а автоматической системе учёта потом мозги сносит. И у нас в отделе (бывшем, правда) из 5 программистов, трое будут забывать всегда, 1 - через раз, symbions(97 знак., 02.02.2022 08:41)
        
        В новый проект - самую свежую. В старый проект - ту, с которой оно раньше работало. Если нужно перенести в старый проект фичи из свежей ревизии - втыкаешь свежую ревизию и смотришь что получилось. - LightElf(31.01.2022 16:17)
        
        А когда "новый" с минимальными правками получается из сделанного семь лет назад? - Cкpипaч(31.01.2022 16:29)
        
        На выбор. Можешь оставить старую, с которой заведомо работает. Можешь подтянуть новую и перетестировать проект, раз уж все равно в него залез. - LightElf(31.01.2022 17:03)
        
        В отдельной ветке. Главное - ты должен знать чего откуда растёт. Знать а не помнить. Т.е. иметь возможность в любой момент проверить этот факт одной командой. - =AlexD=(31.01.2022 16:31)
        
        Нет уж. Лучше сто независимых проектов. - Cкpипaч(31.01.2022 16:42)
        
        Да хоть миллион. Речь вообще не про проекты. - =AlexD=(31.01.2022 16:44)
    - Да не тестируем мы ни хрена! :) - VLLV(31.01.2022 16:02)
      - Мы - тоже! :) - Cкpипaч(31.01.2022 16:23)

Средства и методы разработки