Comments 29
Привет Илья, полезная статья, обычно merge является критичной операцией, были бы интересны детали - именно кто отвечает за разрешение возможных конфликтов в коде, и в этой связи взаимодействие разработчиков и project leader
> Когда разработчик выполнил поставленную задачу, он заводит Merge Request для передачи изменений в основную ветку проекта
ps
Apollo 11 Code Review
All the source code has 64.992 lines. There are 40.202 lines of code. There are no files without comments, 31.443 of the lines contain a comment and there are 5900 blank lines used. The software was submitted by 1 person and approved by 6 other people.
Добрый вечер, Виктор
Перед тем, как заводить MR, разработчик вливает в свою ветку develop и разрешает все конфликты. Получающийся после этого коммит и отправляется на ревью. В этот момент код компилируется, проходит тесты. Если вдруг не проходит, то это задача разработчика поправить все ошибки.
Ревьювер проверяет код на логические ошибки и выполнена ли вообще задача, ради которой заводилась эта ветка. Если есть претензии к конкретным строчкам кода, то можно к ним оставить комментарии и обсудить в ветке Merge Request'а:
Чаще всего их правит разработчик. Но если там какая-нибудь мелочь, то и ревьювер может поправить.
Если ошибки логические или касаются задачи в целом, то их лучше обсуждать в соответствующей issue. У нас там собирается база знаний, схем, и т.п., к которым удобно возвращаться время от времени:
понятно, какой у вас порядок количества разработчиков зависящих от merge, и как часто merge происходит?
ps
типичный размер команды с которым приходилось иметь дело 30-60 человек, merge на основную рабочую ветку проекта каждые 3-4 дня, конфликты кода обычное дело из-за параллельной работы, все спорные вопросы - ответственность несет project leader (один или несколько), примерно так
pps "wc -l" = newline (\n) count
Мержи каждый день по мере завершения работы над issue.
Редко бывает, что разные люди работают над одними и теми же участками кода. Поэтому разработчик, завершив работу над задачей, заводит MR и переходит к следующей задаче, ответвившись от своей же ветки. На схеме выше это 273-E1B-tracking -> 274-E1B-modulation. Либо же к началу работы над новой задачей MR успевают принять, тогда он ветвится от develop
> Редко бывает, что разные люди работают над одними и теми же участками кода
это понятно, причин для конфликта может быть много, просто пытаюсь представить ваш рабочий порядок, наелся всего этого более чем достаточно за долгое время работы
Если конфликт уровня git merge, то кто мерджит, тот и разбирается.
А если конфликт уровня "моё решение лучше твоего", то такого и не бывает. Коллектив небольшой, код пишет дюжина человек. Очень редко пересекаются правки. А если пересекаются, то есть внутренняя субординация и взаимоуважение, разный опыт работы и уровень погружения в проект. До драки ни разу не доходило :)
> код пишет дюжина человек ... есть внутренняя субординация и взаимоуважение, разный опыт работы и уровень погружения в проект.
так примерно и думал, отличается от того к чему привык, т.е. большие довольно опытные команды, примерно 50/50 senior/principal, много нового кода каждый день, QA 24/7 занимается тестированием -> кроме прочего 2-3 bug fixing каждый день на человека, примерно так embedded systems делаются в us
А как PM успевает расписать задачи на 30-60 человек? Или они, разработчики, настолько универсальные бойцы, что могут брать любую задачу из бэклога и начинать работать? Мне последнее тяжело представить в радиотехнике. Когда я пишу issue, я представляю 1-3 человек, кто за неё может взяться. Исходя из прошлого опыта, уровня навыков и текущей загруженности.
Почему бы их не разбить на группы человек по 8-12 и развести по разным подпроектам?
> как PM успевает расписать задачи на 30-60 человек?
отличный вопрос, если PM имеется в виду manager, то его функции несколько другие, больше координация процесса, бюджет, через него идет общение с QA, проведение status meeting, вообще планирование, с технической стороны есть project leader (один или несколько) и consulting engineer (также может быть несколько, часто для нескольких проектов одновременно), собственно они определяют основные спецификации и контролируют качество кода, в начале нового проекта первое, что делает project leader это выясняет кто из инженеров хочет и может в нем участвовать, как правило добровольно, или возможно привлекает со стороны контракторов или новых сотрудников, это обсуждается с sw manager и sw director, когда основные части нового проекта прикрыты людьми или чуть раньше consulting engineer делает архитектурные спецификации и пошло-поехало, в процессе обсуждения спецификации участники проекта делят задачи между собой, в этой фазе конфликты редки, люди как правило знают друг друга долгое время по другим совместным проектам, не уверен ответил ли на Ваш вопрос, так как тема большая
ps
какие именно проекты делать зависит от многих факторов, но это уже уровень sw director и результат обсуждения с другими людьми его уровня
pps
> Почему бы их не разбить на группы человек по 8-12 и развести по разным подпроектам?
структура проектов функциональна, может быть 8-12, а может быть 30 и больше, спецификаций хватает, но обычно никто не расписывает задачи для других в явном виде, как-то без этого обходится, типа с опытом приходит
Дивный новый мир. В российских реалиях для встраиваемого ПО наша команда средняя или даже выше среднего по численности. При этом почти всегда идут несколько проектов параллельно, поэтому эффективная численность снижается. И я говорю не только про госкорпорации, но и про местные r&d центры иностранных компаний. Описываемая вами картина с трудом натягивается у нас даже на Яндекс или Сбер в части веба и корпоративных сервисов, не то что эмбэд. Могу предположить, что ваш опыт касается больших корпораций вроде Broadcom, Qualcomm, Intel, Infineon, Apple и т.д. Там мне пока не приходилось работать.
А вот эти senior/principal, составляющие основную массу разработчиков встаиваемого ПО, какой у них бэкграунд? Это MSc/PhD из EE или MSc CS? Они в курсе предметной области или их дело перевести спецификацию в код? Как именно работает система знает только consulting engineer? Насколько глубоко тогда consulting engineer и лиды расписывают спецификации? В духе "нам нужно дополнить систему таким-то режимом, вон описание от IEEE, действуй" или "нужно разработать функцию с именем x, входные и выходные интерфейсы y, тестовые сценарии такие-то, ограничения на память такие-то и т.д."?
В описываемую группу входят разработчики логических модулей (кремния или плис)? Или вы готовите ПО уже под готовый кристалл?
приходилось работать в разных компаниях, но хорошего уровня начиная с digital, все время embedded, в основном для сетей, практически с самого начала, вопросы заданы интересные, попробую ответить (в меру сил) -
> senior/principal, составляющие основную массу
образование уровня физтеха или mit, средний опыт 10-15 лет, как правило MS computer science, последнее время все чаще одновременно MS типа electrical engineering (жизнь заставляет), в общем серьезные люди способные работать самостоятельно, предметную область все знают по-разному, но на достаточно детальном уровне, людей уровня "перевести спецификацию в код" обычно не держат, если требуется что-то в этом роде - это дело контрактников, типа какой-нибудь редкий porting сделать, ничего ответственного им не поручают,
> Как именно работает система знает только consulting engineer?
consulting engineer это типа свободный художник, mentor, например заслуженный project leader, иногда держатель оригинальных патентов на что-нибудь, его роль передача опыта, часто присматривает за несколькими проектами одновременно, отвечает в том числе за выбор перспективной технологии на будущее, всключая hw архитектуру, asic и пр.,
в части понимания работы системы - обычно понимают все (возможно на разном уровне детализации), для крайних случаев больших систем - пытаются понять все, но не у всех получается, примерно так :)
> Насколько глубоко тогда consulting engineer и лиды расписывают спецификации
как требуется для понимания работы, но все интерфейсы довольно детально, сильно зависит от конкретного проекта, но информация никогда не дублируется, типа ссылка на соответствующие rfc, этого достаточно, если предлагается что-то новое, тогда все детали,
> "нужно разработать функцию с именем x, входные и выходные интерфейсы y, тестовые сценарии такие-то, ограничения на память такие-то и т.д."
обычно нет, но бывают исключения если ресурсы ограничены, типа для основного рабочего цикла, могут быть детальные временные оценки требуемой производительности, времени реакции и тп. , если к примеру закрытые прерывания влияют, это рассматривается детально, включая измерения,
> В описываемую группу входят разработчики логических модулей
нет, это отдельно, обмен спецификациями и взаимодействие есть как требуется, но в общем случае на уровне project leader
А теперь главный вопрос: как собрать 30-60 выпускников MIT с опытом 10-15 лет, способных работать самостоятельно, в одну компанию на линейные должности? Почему они при таком бэкграунде всё ещё не лиды, CTO, consulting engineer'ы? Не могут же таких людей мотивировать только деньги, должно быть что-то ещё.
Они выращиваются в компаниях второго эшелона и рассматривают возможность поработать в таком коллективе как промежуточный шаг? Или это MIT и привлекательность США так фильтрует кандидатов? Может это нежелание заниматься менеджерской рутиной и любовь к своему делу? Или возможность прикоснуться к большому проекту и увидеть результат своего труда во всех магазинах?
Если проецировать на мою индустрию, спутниковую навигацию, то на всю Россию людей подобных качеств примерно столько, сколько у вас в одной описываемой команде. Обычно это лиды отдельных коллективов, на которых держатся целые компании или отделы. В коллективы очень редко кто-то приходит с улицы на полноценные рабочие позиции, чаще это выращивание людей со студенчества с постепенным расширением зоны ответственности.
> главный вопрос: как собрать 30-60 выпускников MIT с опытом 10-15 лет
"образование уровня физтеха или mit" необязательно получено в mit, в us порядка 20 университетов и колледжей примерно такого уровня (включая stanford и пр.), но вопрос правильный, imho комбинация интересной работы и относительно высокой компенсации включая stock options, заметим vesting которых зависит от стажа работы, бонусы работают также, конечно сильно амбициозные люди уходят и приходят, но в разумных пределах
All the source code has 64.992 lines. There are 40.202 lines of code.
Я использовал следующую методику:
git clone https://github.com/chrislgarry/Apollo-11.git
cd Apollo-11/Luminary099/
find . -name '*.agc' | xargs wc -l
-> 64830 total
Удалено
Класс! Больше ничего сказать не могу. Очень все изящно и красиво сделано.
Вы все десять лет шли к этому решению или сколько времени вы работали именно над этим вариантом? Немножко историю эволюции тестирования в этом проекте можете рассказать?
P.S. A и еще, это я так понимаю гос. учереждение. А финансируется проект частниками или из бюджета? Я к чему веду. Просто в коммерческой среде на создание нормальных решений как правило нет времени, нет времени чтобы спокойно все обдумать а потом спокойно все реализовать. В коммерческом секторе нередко все начинается с того что хотят быстро накидать тестовое покрытие, и только потом понимают, что тесты есть - толку нет.
Там в статье есть кат с описанием первых трех вариантов. И даже ностальгические скриншоты. Желание автоматизировать проверки было всегда, т.к. железо/софт сложные и все время стремятся разложиться. Стоит что-то оставить без присмотра - оно обязательно протухнет.
Первые попытки не достигли устойчивого использования, но создали нужные наработки:
- покрытие юнит-тестами
- библиотеки для настройки приборов и получения с них данных
- симуляционное окружение для прошивки
- понимаю узких мест, того, что чаще ломается и что не дает системе прижиться
Пандемия резко обострила потребность в системе автотестирования. Мы стали часто работать удаленно, а надо как-то проверять Merge Request'ы перед вливанием в основную ветку.
Зимний сноубордический сезон 2020/2021 свел меня с синьор-помидор-qa-автоматизатором из Яндекса. Так новогодними вечерами под глинтвейн я подтянул знания о Jenkins, worker'ах и современных системах для решения подобных проблем.
В феврале 2021 мы взяли под разработку автотестов бойкую девушку, мою бывшую студентку. Я включал воображение и проектировал в голове будущую систему, она пыталась это натянуть на Gitlab CI/CD. Судя по git blame, 30 марта 2021 года у нас в основном репозитории программного комплекса появился первый gitlab-ci.yaml. Через некоторое время ей в подаваны взяли ещё 2 человек (ребята ещё студенты-третьекурсники, но толковые).
Новая система прижилась, без неё уже не представляю разработку. В новых проектах, даже если там нет задач по написанию прошивок, первым делом заводим CI.
Там в статье есть кат с описанием первых трех вариантов
Я прочитал этот отрывок но не заострил на нем внимания потому что не увидел взаимосвязи в прогрессии. (Кстати там материал по ссылке на srns закрыт для посторонних) Больше похоже на эксперименты без наличия четкого видения цели. А потом прям принципиальный скачок получился. А теперь я понимаю как это произошло. Это вы с правильными людми поговорили, и они вас "на нужную частоту настроили" :)
Еще такой вопрос, если можно: система подразумевает возможность полностью удаленной работы. Что вы делаете если прошивка запарывает устройство, есть какой-то способ экстренного восстановления работоспособности устройства, без личного присутствия? Или архитектурно сделано так, что прошивкой нельзя запороть устройство до такой степени, чтобы оно перестало принимать прошивки? И вы тогда, например, просто откатываете на базовый образ.
Санкционный Zynq... какие перспективы у проекта?
Тема тестирования GNSS приемников - специфическая и интересная.
Я вижу специфику в том, что тут:
embedded
Система реального времени - тут не поставишь точку останова
Вообще, интересно какой именно набор тестов вы используете (на сколько глубоко тестируете регулярные изменения).
Понятно, что в теории можно придумывать много.
Нововведения в блоке вторичной обработки сигнала проверить относительно просто. Низкий темп обновления данных и их относительно маленький объем дают простор для фантазии. Тут даже можно уходить в сторону unit тестирования. Более того, можно даже постараться и входные данные для теста сформировать один раз и по одному, когда то давно записанному логу, проверять все нововведения (т.е. в тестирование можно удалить этап записи нового лога, что существенно ускорит процесс).
А вот как проверять блок первичной обработки? По точке на карте? Это надо очень жестоко накосячить чтобы навигация слетела. А как проверить маленький косяк, который просто ухудшит характеристики модуля, не ломая его (например, время от времени срывается слежение за фазой на одном из сигналов)?
Эта задача кажется не тривиальной. Тут есть проблемы:
высокий темп обновления целой кучи данных (много каналов, а 1 мс - это уже эпоха ПСП)
в этом блоке наблюдается тесное взаимодействие с аппаратной частью (управление опорным сигналом в блоке корреляторов)
конечно первичку можно тестировать. Самое простое, это смотреть вторые разности на 0-базе - это позволит оценить СКО фазы, кода, частоты.
Это вариант не плохой, но он не совсем удовлетворяет . Не хватает детализации, что ли.
Я смогу увидеть что то не так, но что это было: переполнение в сумматорах, просто петля слежения сломалась, неправильная битовая синхронизация или ещё что - догадываться только по контексту комита можно.
На живом приемнике тестов пока не так много: выдача наблюдений по заданному типу сигналов, выдача навигационных данных по заданному типу сигналов, наличие решения по заданному типу сигналов. Это высокоуровневые требования, уровня ТЗ.
Технически все есть, чтобы опускаться глубже. Пропускной способности интерфейса хватает, чтобы забирать данные с систем слежения с темпом 1 мс. Но число проверок начнет расти как снежный ком, да и руки пока не дошли.
Думаю, правильным было бы ввести статистические метрики и для начала построить дашборд с ними. То есть не просто проверять, что TTFF решения укладывается в 60 секунд, а смотреть его динамику от коммита к коммиту. Или скорость разрешения неоднозначности на нульбазе. Или среднее время обработки прерываний. Или число каналов, что вмещаются в ПЛИС. Если в софте действительно появляется какая-то проблема, то она проявится на таких характеристиках. А если она не наблюдаема, то она второстепенна. Мысли у меня об этом крутятся, но построение дашбордов в нашей системе пока не реализовано.
Теперь банановый
Сняли видео ролик по материалам статьи: https://youtu.be/9ITrzCq-YKI
Автоматизация тестирования при разработке прошивок радиоэлектронных устройств