bhagman Ответов: 3

Должны ли мы переписать наше программное обеспечение с нуля?

У нас есть проект, написанный на языке Си, это около 70 тысяч строк кода, и он был написан более десяти лет. Функции и опции были добавлены к оригинальной функциональности на протяжении многих лет. Приложение представляет собой прошивку реального времени для работы на микроконтроллере, и в нем есть некоторые очень тщательно разработанные обработчики прерываний и другой критический код. Часть кода была оптимизирована для работы с задержкой 2us.

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

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

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

Эта прошивка используется в количестве около 1000 штук в год.

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

***
Разумно ли это?

Вы бы переписали с нуля? Это самое лучшее, что можно сделать? Есть ли лучшая стратегия?

Если мы перепишем с нуля, как вы думаете, сможем ли мы устранить все ошибки?

Как вы думаете, сколько времени потребуется, чтобы переписать 70 тысяч строк с использованием стандарта кодирования Misra?

Является ли чрезмерным один отчет об ошибке клиента в год на 70 тысяч строк кода? Что другие люди считают ошибкой?

Я в этом деле полный новичок. Я надеюсь, что это подходящий пост.

Что я уже пробовал:

Я спросил, каковы рыночные требования к Мисре, и мне ответили, что если бы мы это сделали, то, если бы кто-то попросил об этом, мы могли бы сказать, что у него это есть. Я никогда не слышал, чтобы кто-то просил нас о стандарте Мисры.

jeron1

Является ли это "критическим для жизни" типом приложения?

bhagman

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

jeron1

Трудно сказать, если код - это нечитаемый кошмар для обслуживания, «только один человек в мире может с ним работать», fustercluck, тогда, возможно, следует переписать. Если эти ошибки влияют на способность продавать ваш продукт или отрицательно (в значительной степени) влияют на бизнес, возможно, стоит переписать. Тем не менее, выполнение перезаписи не обязательно является решением проблемы. Он может быть переписан плохо, так что у вас будет больше проблем, чем раньше, многое зависит от опыта команды разработчиков. Ошибки в каждой строке кода действительно не имеют значения, пользователя меньше заботят строки кода. Может случиться так, что обзор кода (и добавление большого количества документации) и какое-либо изменение тестирования приведет к большему, чем полное переписывание. Только мои 0,02 доллара.

[no name]

Есть ли какие-то планы по обновлению оборудования?

3 Ответов

Рейтинг:
0

Dave Kreskowiak

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

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

Мисра - это не методология. Мисра-это ассоциация. Они выпустили набор руководящих принципов и спецификаций соответствия для программного обеспечения, разработанного для встраиваемых систем в автомобильной промышленности. Такие вещи, как"отдавать предпочтение безопасности человека, а не собственности транспортного средства". Вот и все. Он не описывает методологию разработки. Это царство Agile, Scrum ,Rational Unified...

На все остальные ваши вопросы нет ответа. Только вы и ваша команда можете ответить на них.

Рейтинг:
0

nv3

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

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

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

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

bhagman

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

&ГТ;&ГТ;&ГТ;&ГТ;&ГТ;&ГТ; это трудно ответить, не взглянув на код.
Вы знаете о коде столько же, сколько и менеджер!

nv3

&ГТ;&ГТ;&ГТ; вы знаете, как много о код, как менеджер делает!
Как еще это мог быть. И того немногого, что мы знаем, недостаточно, чтобы принять твердое решение. Если вы сами недостаточно опытны, вы можете нанять независимого эксперта, чтобы он взглянул на ваш код и помог вам и менеджеру принять это решение. Это может сэкономить вам много денег в долгосрочной перспективе и, возможно, предотвратить полную катастрофу с переписыванием с нуля, которое не работает должным образом.

Рейтинг:
0

Patrice T

Цитата:
Должны ли мы переписать наше программное обеспечение с нуля?

Мы находимся в худшем месте, чтобы дать вам информированные советы, потому что у нас нет подробностей об этом коде и его проблемах. 2 инженера, работающие над ним, вероятно, имеют лучшее представление об этом вопросе.
Цитата:
Они говорят, что, сделав это, код будет свободен от ошибок, и у нас будет более надежный и ремонтопригодный код.

в лучшем случае это благочестивые желания
В истории компьютеров ни одна программа, кроме самых простых, никогда не была свободна от ошибок.
Спросите НАСА, что они думают о свободном от ошибок программном обеспечении, и бог знает, как ошибка может быть смертельной для них.
Марс Климат Орбитер - Википедия[^]
более надежный и ремонтопригодный код: он полностью зависит от людей, пишущих его. Никто никогда не может гарантировать вам такого рода преимущества.
Цитата:
Кроме того, примерно раз в год клиент сообщает нам об ошибке, о которой мы не знали.

Я бы сказал, что ставка довольно низкая.

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