Itelma 8 июл 2020 в 12:16

Разработка критически важных алгоритмов: Реализация

17 мин

3.5K

Блог компании НПП ИТЭЛМАOpen source*Алгоритмы*Разработка робототехники*Транспорт

Перевод

Проектирование
Реализация
Интеграция

Когда я только начинал свой путь в профессиональной разработке, я не понимал зачем нужен open source. Я не понимал и сайд-проектов, если уж на то пошло. В конце концов, зачем отдавать ценную работу бесплатно? За прошедшие годы, поработав над проектами с открытым исходным кодом, а также благодаря работе с Apex.AI, ROS 2 и Autoware.Auto, я пришел к некоторому пониманию open-source.

Инженеры любят творить. Люди хотят признания и благодарности.

Когда вы соединяете эти факторы вместе, вы получаете путь к open source. Если я что-то строю для удовлетворения своих творческих потребностей, то почему бы не позволить всем остальным оценивать мою работу и находить в ней практическую пользу и ценность? В конце концов, я делаю это не ради денег.

Что касается сайд-проектов, то их очарование я понял только после того, как начал профессионально развиваться и более тщательно подходить к различным аспектам своей работы. Чтобы создать надежный продукт, за который люди будут платить, часто приходится искусственно ограничивать рабочие процессы. Анализ дизайна. Код-ревью. Стандарты написания кода, стайлгайды, метрики тестового покрытия, и так далее и так далее. Не поймите меня неправильно – все это хорошие вещи, которые, скорее всего, необходимы для разработки качественного продукта. Просто иногда разработчик хочет немного свободы. Разработчик может хотеть создавать то, что он хочет, как он хочет и когда он хочет. Никаких встреч, ревью или бизнес-кейсов.

Так как же объединить эти аспекты, когда дело доходит до разработки безопасных или высококачественных алгоритмов? Значительной частью очарования мира open-source является свобода, а практики, которые помогают обеспечить разработку более надежного кода, ограничивают эту свободу.

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

Планирование open source проектов

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

Этот специфический набор навыков может привести нас, инженеров, к некоторой перегрузке.

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

Именно здесь в игру вступает черная магия управления проектами.

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

И хоть мы и понимаем важность разных менеджеров, люди с такими навыками обычно не принимают участия в типичном open-source проекте, цель которого заключается в получении удовольствия.

Так что же нам тогда делать?

Ну, мы, разработчики, можем немного запачкать руки и потратить немного времени на предварительное планирование.

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

Возвращаясь к аспекту планирования проекта, мне нравится начинать с компонентов с наименьшими зависимостями (подумайте минутку!), а затем продолжать работу, добавляя заглушки реализаций там, где это необходимо для поддержания темпов разработки. При таком порядке работы вы, как правило, можете создавать множество тикетов (с некоторыми зависимостями в них, соответствующими вашим архитектурным зависимостям – если у вашего таск-трекера есть такой функционал). Эти тикеты могут содержать некоторые общие примечания, которые полезно иметь в виду прежде чем вы погрузитесь в какую-либо задачу более детально. Тикеты должны быть как можно более маленькими и конкретными. Давайте посмотрим правде в глаза – наши внимание и способность удержания контекста ограничены. Чем более гранулярно разбиты задачи разработки, тем легче – так почему бы не постараться максимально упростить трудные задачи?

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

Очевидно, что это значительно упрощенная версия управления проектами. В настоящем управлении проектами существует множество других аспектов, таких как ресурсы, планирование, конкурирующие бизнес-кейсы и так далее. Управление проектами в open-source может быть более простым и свободным. Возможно, в мире открытой разработки существуют кейсы полноценного управлениям проектами.

Открытая разработка

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

Тем не менее, многих факторов свободы, присутствующих в диком западе открытой разработки не должно быть в разработке безопасного кода. Вы можете избежать множества подводных камней, используя инструменты с открытым исходным кодом и соблюдая некоторую дисциплину (и имея друзей).

Я являюсь большим сторонником дисциплины как средства повышения качества работы (в конце концов, дисциплина стоит на 6-м месте в моей оценке на StrengthsFinder). Имея достаточно дисциплины, чтобы использовать инструменты с открытым исходным кодом, прислушиваться к другим, действовать в соответствии с результатами и придерживаться рабочих процессов, мы можем преодолеть многие недостатки, которые прокрадываются с ковбойскими подходами мира открытой разработки.

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

Тесты (или, что еще лучше, разработка, основанная на тестах)
Статический анализ
Непрерывная интеграция (CI/CD)
Код-ревью

Также приведу ряд принципов, которых я придерживаюсь при непосредственном написании кода:

DRY
Полное использование языка и библиотек
Код должен быть читабельным и ослепительно очевидным.

Я постараюсь связать этот текст с фактической реализацией алгоритма локализации NDT, которая была завершена за 10 мердж-реквестов моего хорошего коллеги Юнуса. Он слишком занят непосредственной работой, поэтому я могу повесить на себя несколько воображаемых медалей, написав о его работе.

Кроме того, для иллюстрации некоторых процессов и практик, я приведу в пример разработку open-source алгоритма для контроллера MPC. Он был разработан в несколько более свободном (ковбойском) стиле за примерно 30 с лишним мердж-реквестов, если не считать дополнительные правки и улучшения, внесенные после окончания основной работы.

Тестирование

Давайте поговорим о тестировании.

У меня были долгие и сложные (по моим меркам) отношения с тестированием. Когда я впервые получил должность разработчика и взялся за первый проект, я абсолютно не верил, что мой код работает, а потому я был первым в команде, кто начал писать хоть сколько-нибудь содержательные юнит-тесты. Впрочем, я был абсолютно прав в том, что мой код не работал.

С тех пор мои бурные отношения с тестированием прошли через множество поворотов, достойных фильмов для ночного эфира. Иногда мне нравилось. Иногда я все это ненавидел. Я написал слишком много тестов. Слишком много копипасты, слишком много избыточных тестов. Потом тестирование стало рутинной работой, еще одной частью разработки. Сначала я писал код, а потом к нему писал тесты, таким стал порядок вещей.

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

Что для меня изменилось, так это методы разработки основанной на тестах, которые я начал использовать в своем mpc-проекте.

Я вкратце рассказывал о разработке на основе тестов в предыдущем тексте, но еще раз приведу описание этого процесса:

Разработать спецификацию (варианты использования, требования и т.д.).
Реализовать API/архитектуру
Написать тесты на основе API и проектной спецификации; они должны проваливаться.
Внедрить логику; тесты должны пройти

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

Я много говорил о том, что перед реализацией нужно планирование, и разработка на основе тестов дает вам эту возможность. Отметили первый пункт. Затем вы думаете об архитектуре и API, и сопоставляете их со случаями использования. Это дает вам прекрасную возможность приблизиться к коду, но при этом подумать о проблеме в общем плане. Отметили второй пункт.

Дальше мы переходим к написанию тестов. Есть несколько причин пользы написания тестов перед реализацией, и я думаю, что все они важны:

Тесты должны быть написаны как объекты первой важности, а не как дополнение.
Тесты должны быть написаны только с учетом спецификации, без подробных знаний о реализации – таким образом тест проверит работу реализации.
Тесты позволяют вам играться с вашим API и увидеть, насколько удобно его использовать.
Вы можете убедиться, что ваши тесты корректны, если они провалится, когда ваш код не будет делать то, что вам нужно.

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

Вернемся к Autoware.Auto. Юнус, хотя и не придерживался методов разработки на основе тестов, писал тесты к каждому мердж-реквесту во время разработки NDT. При этом объем тестового кода был равен (а иногда и превышал) объему кода реализации, и это хорошо. Для сравнения: SQLite, который, вероятно, является эталоном в вопросах тестирования (не только по меркам проектов с открытым исходным кодом), имеет в 662 раза больше тестового кода, чем кода реализации. В Autoware.Auto мы пока не совсем на этом этапе, но если просмотреть историю мердж-реквестов, связанных с NDT, то можно заметить, что объем тестового кода медленно полз вверх, пока не покрытие не достигло 90% (хотя с тех пор оно упало из-за других разработок и внешнего кода).

И это круто.

Точно так же в моем проекте mpc есть тесты на все, в том числе и на сами тесты. Более того, я всегда аккуратно провожу регрессионное тестирование, чтобы убедиться, что ошибка исправлена и больше не проявится.

Я молодец.

Статический анализ

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

Такие «тесты» несколько болезненны и трудоемки в работе. В конце концов, проверка, проверка на использование табов/пробелов при выравнивании? Нет уж, спасибо.

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

Ну, мы можем – с помощью инструментов статического анализа.

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

В Autoware.Auto мы используем слегка уменьшенную версию набора ament_lint от наших близких друзей из ROS 2. Эти инструменты приносят нам много пользы, но, пожалуй, самое главное — это автоформатирование нашего кода, исключающее споры о стиле – беспристрастные инструменты говорят нам, что правильно, а что нет. Если вам интересно, то отмечу, что clang-format более строг, чем uncrustify.

В проекте mpc я зашел немного дальше. В нем я использовал флаг Weverything компилятора Clang, в дополнение ко всевозможным предупреждениям от clang-tidy и статического анализатора Clang. Удивительно, но для коммерческой разработки понадобилось отключить несколько параметров (из-за избыточных предупреждений и концептуальных разногласий). При взаимодействии с внешним кодом пришлось отключить многие проверки – они приводили к лишнему шуму.

В конечном итоге, я понял, что использование обширного статического анализа не сильно мешает нормальной разработке (в случае написание нового кода и после прохождения определенной точки на кривой обучения)

Сложно количественно оценить значение статического анализа, особенно если использовать его с самого начала. Дело в том, что сложно догадаться, существовала ли ошибка до внедрения статического анализа, или нет.

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

CI/CD

Как бы мне не нравились тщательное тестирование и статический/динамический анализ кода, все тесты и проверки ничего не стоят, если их не запускать. CI может решить эти задачи с минимальными накладными расходами.

Думаю, все согласны, что наличие инфраструктуры CI/CD является существенной частью современной разработки, равно как и использование системы контроля версий и наличие стандартов разработки (хотя бы руководств по стилю). Впрочем, ценность хорошего конвейера CI/CD заключается в том, что его операции должны быть воспроизводимы.

Конвейер CI/CD, как минимум, должен собирать код и запускать тесты перед включением кода в ваш репозиторий. В конце концов, никто не хочет быть тем парнем (или девушкой, или персоной), кто сломал сборку или какой-то тест, и должен быстро и позорно все исправлять. CI (и, следовательно, ваши дорогие инженеры DevOps) защищают вас от этого позора.

Но CI может сделать для вас гораздо больше.

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

Возвращаясь к первоначальному утверждению, наличие CI/CD конвейера (которым мы пользуемся в Autoware.Auto) в вашем open-source проекте поможет оседлать неуправляемость разработки. Код не сможет попасть в проект, если он не соберется или не пройдет тесты. Если при этом соблюдать строгую дисциплину тестирования, то всегда можно быть уверенным в том, что код работает.

В Autoware.Auto, CI:

Собирает код
Запускает тесты (стилевые, проверки линтеров, функциональные тесты).
Измеряет тестовое покрытие
Проверяет, что код задокументирован

В свою очередь, мой наспех собранный CI в проекте mpc:

Собирает код
Выполняет сканирование (статический анализ Clang)
Прогоняет тесты (но не останавливает CI в случае провальных тестов).

CI-конвейер, собранный опытным инженером DevOps (таким как наши Джей Пи Сампер или Хао Пень!) способен на гораздо большее. Так что лелейте своих DevOps-инженеров. Они делают нашу жизнь (как разработчиков) намного проще.

Код-ревью

Тесты, анализаторы и CI — это замечательно. Вы можете прогнать тесты, все проанализировать, и убедиться, что эти тесты проводятся с помощью CI, не так ли?

К сожалению, нет.

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

У меня, к сожалению, нет волшебных ответов. На самом деле, я возвращаюсь к старой инженерской методике, к рецензированию. В частности, к код-ревью.

Обычно считается, что две головы лучше, чем одна. На самом деле, я бы утверждал, что это понятие подкрепляется не только литературой, но и теорией.

Ансамбль методов в машинном обучении иллюстрирует эту теорию. Считается, что использование ансамбля методов является быстрым и простым способом повышения производительности статистических моделей (в качестве примера можно привести известный метод бустинга). Аналогичным образом, с чисто статистической точки зрения, дисперсия тем ниже (с предположениями), чем больше у вас есть образцов. Другими словами, вы, скорее всего, будете ближе к истине, если подключите больше сотрудников.

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

Если отложить в сторону теорию и тимбилдинг, код-ревью является важным и мощным инструментом. Неудивительно, что код-ревью является неотъемлемой частью любого процесса профессиональной разработки, и даже рекомендован стандартом ISO 26262.

Все это говорит о том, что всегда есть опасность того, что у одного дитя будет семь нянек. Более того, иногда может код-ревью вызывает определенные трудности.

Тем не менее, я думаю, что код-ревью могут быть приятными и безболезненными, если и рецензент, и рецензируемый будут помнить следующее:

Вы – не ваш код.
Вы говорите с другим человеком.
Будьте вежливы
Все работают для достижения одной и той же цели; код-ревью не представляет никакой конкуренции (хотя иногда в программировании такое бывает)

Многие более умные и приятные люди, чем я, написали о том, как правильно проводить код-ревью, и я предлагаю вам взглянуть на их работы. Последнее, что я могу сказать – вы должны проводить код-ревью, если хотите, чтобы ваш код был более надёжным.

DRY

Я подробно рассказал о процессах и средствах, с помощью которых можно сформировать окружение разработки: проверках и инструментах, которые проводят проверки и убеждаются, что код достаточно хорош.

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

Есть пара концепций, которые помогли мне значительно улучшить свой код. Одной из этих концепций было умение помнить о намерениях, семантике и читабельности, о которых я расскажу чуть позже. Другой – понимание ООП и принципа разделения проблем. Последняя важная идея – DRY (Don’t Repeat Yourself) или принцип «Не повторяйся».

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

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

Но DRY идет дальше проверок на то, что какой-то код следует вынести в функцию. Эта концепция также может служить основой для принятия некоторых архитектурных решений.

Хоть этот подход и пересекается с некоторыми архитектурными концепциями (такими как совмещение, связность и разделение задач), пример применения DRY к архитектуре можно увидеть в моем проекте mpc. Во время разработки mpc-контроллера я заметил, что мне придется дублировать какой-нибудь код, если я когда-нибудь напишу другой контроллер. Речь о шаблонном коде для отслеживания состояния, публикаций, подписок, преобразований и тому подобного. Другими словами, казалось, что это отдельная от mpc-контроллера задача.

Это был хороший признак того, что мне следует выделить общие конструкции и функциональность в отдельный класс. Окупаемость была двукратной: mpc-контроллер на 100% сконцентрирован на коде, связанном с mpc, а связанный с ним модуль — это только шаблон конфигурации. Другими словами, из-за архитектурных абстракций мне не придется все переписывать при работе с другим контроллером.

Мир состоит из оттенков серого, поэтому в эти проектные решения следует вникать с осторожностью и правильным мышлением. Иначе можно зайти слишком далеко, и начать создавать абстракции там, где они не нужны. Тем не менее, если разработчик помнит о тех концепциях, которые эти абстракции моделируют, DRY является мощным инструментом для формирования архитектурных решений. На мой взгляд, DRY является основной концепцией для поддержания чистоты и плотности вашего кода.

В конце концов, одно из ключевых достоинств кода заключается в его способности выполнять повторяющиеся задачи, так почему бы не переложить повторение кода на хорошо проработанные функции и классы?

Полное использование языка и библиотеки

DRY, на мой взгляд, является настолько важной и всеохватывающей концепцией, что этот пункт на самом деле является лишь продолжением разговора о DRY.

Если ваш язык что-то поддерживает, то вы, как правило, должны использовать встроенную реализацию, если только у вас нет очень веских причин от нее отказаться. И C++ имеет очень много встроенных вещей.

Программирование — это навык, и существует большая разница в уровнях владения им. Я лишь мельком уловил насколько высока гора этого навыка и в целом считаю, что люди, которые создают стандарты, реализуют общие паттерны лучше, чем я.

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

Тем не менее, это, как и многие другие, этот пункт является рекомендацией, а не жестким и срочным к применению правилом. Хотя и не стоит изобретать колесо заново, а хотя стандартные реализации, как правило, очень хороши, нет смысла пытаться втиснуть квадратную деталь в круглое отверстие. Думайте своей головой.

Читабельный код

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

Есть очень известная и широко рекомендуемая книга на эту тему, "Чистый код", так что я могу добавить по этой теме не так много. Здесь будут перечислены некоторые общие сведения, к которым я обращаюсь, когда пишу код и провожу код-ревью:

Старайтесь писать классы четкими и сфокусированными:
- Минимизируйте зацепление
- Максимизируйте сплоченность
- Сжимайте публичные интерфейсы до четко определенных и понятных концепций (Пример)
  - Соответствуют ли ваши интерфейсы или параметры соответствующими меткам const, noexcept? Являются ли они ссылками или указателями? (Пример, Пример)
Помните о состоянии объектов
- Знайте, что такое инварианты (Пример, Пример, Пример).
- Защищайте эти инварианты путем разумного выбрасывания исключений (Пример, Пример)
- Также помните о различных гарантиях исключений.
Функции должны делать только что-то одно
- Если в документации к функции вы используете «и», то это признак того, что вы можете разделить функцию.
- Функции должны быть краткими и читабельными (Пример, Пример).
- Избегайте слишком большого количества параметров функции (обычно это признак нехватки абстракции) (Пример).
Повторяетесь ли вы? (Пример)
- Может быть, это нужно вынести в функцию (Пример).
- Или, возможно, внутри гигантского класса есть некоторые концепты, которые стоит вынести в более мелкие классы (Пример, Пример).

Еще одним отличным ресурсом, в котором рассматриваются проблемы такого рода является руководство ISO C++ Core Guidelines.

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

Оглядываясь назад

Это были некоторые из инструментов, принципов и процессов, которые мы использовали при разработке и внедрении алгоритма локализации NDT, а также при работе над MPC-контроллером. Было сделано много работы, было весело, говорить об этом не столь интересно.

В целом, мы здорово использовали инструменты и практики, о которых я говорил, но мы не были совершенны.

Так, например, при работе над NDT мы не следили за идиоматикой разработки, основанной на тестировании (хотя у нас все отлично протестировано!). В свою очередь, в работе над MPC я действительно следовал методам разработки, основанной на тестах, но этот проект не выиграл от более мощного CI, встроенного в Autoware.Auto. Более того, проект MPC не был публичным, а потому не получал преимуществ код-ревью.

Оба проекта могли бы выиграть от внедрения статического анализа, более подробного тестирования и большего количества отзывов. Впрочем, речь идет о проектах, созданных одним человеком, так что я думаю, что проведенного тестирования и полученных отзывов достаточно. Что касается статического анализа, то лучшие и более пристальные его формы в целом попадают в сферу интересов продуктовой разработки и отдаляются от сообщества open-source разработчиков (хотя на горизонте могут появиться интересные идеи).

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

Я думаю, что мы проделали отличную работу по декомпозиции больших задач на более мелкие составляющие (хотя MR-компонент в алгоритме NDT мог бы быть и меньше), и провели тщательное тестирование. Думаю, предварительные результаты говорят сами за себя.

Движение вперёд

После внедрения приходит время интеграции. Необходимо осуществить подключение к более крупной системе с своими сложными компонентами. Эта система будет принимать ваши входные данные, переваривать их и выдавать результаты работы вашего алгоритма. Интеграция является, пожалуй, самой сложной частью разработки алгоритма, так как вам необходимо не терять из виду общий план системы и исправлять низкоуровневые проблемы. Любая ошибка в любой из ваших многочисленных строк кода может помешать интеграции вашего алгоритма.

Об этом я расскажу в третьем и последнем посте из этой серии.

В качестве превью, я скажу, что в процессе разработки не было обнаружено ни одной большой ошибки во время использования и интеграции mpc-контроллера. Правда, были некоторые проблемы со написанием скриптов, сборкой, тестами, была пропущена проверка входных данных, а также возникали проблемы с несовместимостью настроек QoS, но ничего ужасного в коде не было.

На самом деле, он был способен запускаться (минуя несовместимость QoS и настройку параметров) практически из коробки.

То же самое касается алгоритма NDT, который столкнулся с рядом мелких проблем вроде нестабильности ковариаций, ошибкой поиска строк в существующем коде, и неправильно выровненными картами. Несмотря на это, он тоже был способен работать из коробки.

Неплохо для продуктов, разработанных у всех на виду.

Подписывайтесь на каналы:
@TeslaHackers — сообщество российских Tesla-хакеров, прокат и обучение дрифту на Tesla
@AutomotiveRu — новости автоиндустрии, железо и психология вождения

О компании ИТЭЛМА

Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.

У нас много интересных задач от автопроизводителей и концернов, двигающих индустрию. Если хотите расти, как специалист, и учиться у лучших, будем рады видеть вас в нашей команде. Также мы готовы делиться экспертизой, самым важным что происходит в automotive. Задавайте нам любые вопросы, ответим, пообсуждаем.

Читать еще полезные статьи:

Теги:

Хабы: