Месяц: Май 2024

Дипломники, блин

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

Во-первых, оба дипломника в этом году проявили какую-то феноменальную неспособность написать текст работы со сквозным «сюжетом» — а ведь в околоинженерном дипломе это очень просто:

— все было плохо;
— циферки, почему все плохо;
— пришли мы и сделали что-то получше;
— циферки, почему стало получше;
— мы молодцы, поставьте нам хорошую оценку!

Детали могут отличаться — где-то ценным будет описание того, что именно сделано, где-то — методика определения этого «хорошо» и «плохо» и измерения циферок, но в принципе такая структура работы — чуть ли не самоочевидная. Но нет, выцеплять элементы этого сюжета приходится по частям, студенты либо начинают лепить длинный список «технологий», скатываясь в пересказ википедии (явно с целью нагнать объема — но об этом дальше), либо многословно пишут что-то в духе «я деляль» (даже не «сделяль») — но зачем это все и для чего — упорно молчат.

Про рузскей языг даже упоминать не надо, наверное — сначала еще пытаешься следить за употреблением терминов и прочим синтаксисом с грамматикой, но где-то к десятой странице понимаешь, что дело это совершенно безнадежное и смотришь лишь за тем, чтобы студенты не копировали твои сообщения из чатика (где допускаешь некоторые вольности).

Во-вторых, при подготовке бакалаврских дипломных работ их уже испортили необходимостью соблюдения совершенно дегенератских требований — они начинаются от объема «точно в 60 страниц, не больше, ни меньше» (это самое простое) и продолжаются процентом оригинальности по данным какого-то из сервисов антиплагиата (пережить можно, если работа пишется самостоятельно — то даже 10% заимствований не наберется), и наконец, на днях меня выморозило вот такое требование к списку литературы, текст оригинала сохранен:

Количество литературы — не более 40 с актуальным сроком информации не старше 5 лет.

Как думаете, что спросит у руководителя испорченный бакалавриатом студент? Разумеется, «А что делать, если у меня 41 пункт и есть ссылка на ГОСТ 23089.14-88?» — и хорошо, что спросил, а не побежал исправлять список литературы!

Привычка «все проверять антиплагиатом» приводит и к совершенно безумным вещам вроде «рерайта» — попытке «механически» увеличить «оригинальность», читаемости тексту работы это не добавляет. Вероятно, проистекает она из стремления «написать побольше» — в результате вместо «введения» получается безумный пересказ википедии, как было сказано чуть выше. А где пересказ википедии — там и некорректные заимствования, так сказать.

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

Испытываю странное чувство

Хотел в продолжение предыдущей телеги написать, что DO-178 — самый аджайловый из аджайловых стандартов, а за меня это сделали чуваки из Airbus:

https://hal.science/hal-02156357/document

Впрочем, пригодится :)

Про CI/CD

Прочитал студентам проповедь про CI/CD в embedded, поделюсь и тут:

Как учат нас всякие нормативные документы — возьмем, например «авиационный» стандарт DO-178B или в русском переводе — КТ-178B — «интеграция» — это процесс, в рамках которого «исполняемый код загружается в целевой вычислитель» (раздел 5.4) — то есть примерно то, когда вы в Riot выполняете команду make flash или в каком-нибудь красивом IDE типа Keil или IAR (ну или в крайнем случае Arduino IDE) нажимаете кнопку «Run», которая делает то же самое — ваш проект компилируется и загружается в подключенное к вашему компьютеру через отладчик устройство. Это может быть устроено немного более сложно, но пока такого представления об этом всем достаточно.

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

Исходя из результатов испытаний вы понимаете, что программа работает неправильно, возвращаетесь к кодированию — и все повторяется заново, стандарт описывает это словами «Процессы жизненного цикла ПО могут иметь итерационный характер, то есть, могут повторяться» — примерно так, как это показано для «компоненты Z» на этом рисунке:

«Наивный» подход к разработке ПО (свойственный инженерам-электронщикам, кстати говоря) — это то, что показано для «компоненты W» — формулируем требования, выдаем их кодеру, он пишет код, потом заливаем его в целевое устройство, …, PROFIT! Проблема в том, что он… не работает, но при этом широко применяется, вот довольно яркое описание принятых у электронщиков рабочих процессов в программировании:

Качество кода? Ревью? Разделение задач? система контроля версий? Да о чем вы! Высрал бинарник в пизженом кейле и отдал на производство. Человек ушел, работы не приняли, новый начинает с нуля все заново.

https://mbr.livejournal.com/606449.html

Так вот, «непрерывная интеграция» — это в точности то, что сделано в Riot’овских тестах, запускающихся на базе iotlab:

— основная «ветка» безо всякого участия программиста компилируется (это результат «процесса кодирования», пункт 5.3.2 в документе), причем «эталонным» компилятором (я видел, как некоторые проекты «ломались» от смены версий gcc);
— выполняется «процесс интеграции» (раздел 5.4);
— дальше проводится то, что в КТ-178 называется словом «испытания» (программисты скорее будут использовать слово «тестирование») — «выхлоп» программы сравнивается с ожидаемым.

Хочу обратить внимание, что верификация этим не исчерпывается, это немного более сложная штука, но как минимум часть задач верификации тестированием закрывается. Главное — то, что все это делается полностью автоматически, и программист не может намеренно «обойти» эти процессы, потому такая интеграция и называется «непрерывной».

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

В embedded это все особенно ярко видно, потому что «целевой вычислитель» — вот он у вас, в руках или на столе в виде отладочной платы.

Понятно, что все эти вещи можно делать разными средствами — да хоть даже «вручную» — написал код, выполнил команду make или нажал Compile, отдал получившийся бинарник тестировщику (и все это еще оформить документально журналом по принципу «сделал — запиши, не сделал — запиши два раза» — в принципе, и такие «процессы» возможны), но если можно автоматизировать эту работу — то почему бы и нет? Заодно в какой-то степени из процесса испытаний исключается человеческий фактор, все, что можно проверить автоматически — будет проверено, в идеале — для каждого существенного изменения в вашем гитлабовском репозитории (а контроль версий на языке тех же стандартов входит в то, что называется «управлением конфигурациями»).

Собственно, именно это и называется «непрерывной интеграцией», а вовсе не бездумное использование GitLab, Docker и прочих Ansible — важны не инструменты, а то, что вы с помощью этих инструментов делаете. Более того, если строго следовать требованиям КТ-178 — то используемые в процессе валидации инструменты должны быть «квалифицированы», то есть разработаны в рамках предъявляемых стандартом требований. Разумеется, такие программные продукты тоже есть, стоят дорого, как и все авиационное — но возможно, и с ними в жизни придется встретиться.