我们应该从头开始重写我们的软件吗? [英] Should we rewrite our software from scratch?

查看:87
本文介绍了我们应该从头开始重写我们的软件吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们有一个用C编写的项目。这是大约70K行代码,已经写了十多年。多年来,功能和选项已添加到原始功能中。该应用程序是在微控制器上运行的实时固件,它有一些非常精心设计的中断处理程序和其他关键代码。一些代码已经过优化,可以处理2us延迟。



随着功能多年来的发展,一些模块现在有大约3个功能。一些模块和一般结构现在变得纠结。它可以做更多的评论,一个新的程序员说很难进入代码。



固件由大约2名工程师不断处理,因此,每当创建功能或客户特殊版本时,每天都会有效地进行运行和测试。



有一些已知的错误,我们会在有时间的情况下完成这些错误。大约每年一次客户向我们报告我们不知道的错误。



此固件每年的使用量约为1000个。 />


经理(非技术人员)说固件太麻烦,需要使用像Misra这样的方法从头开始重写。他们说,通过这样做,代码将是无错误的,我们将拥有更强大和可维护的代码。



***

是这个合理吗?



你会从头开始重写吗?这是最好的事吗?有没有更好的策略?



如果我们从头开始重写你认为我们能够消除所有的错误吗?



您认为使用Misra编码标准重写70K线需要多长时间?



每70K行每年有一个客户错误报告代码过多?其他人看到的错误率是什么?



我是一个完整的新手。我希望这是一个合适的帖子。



我的尝试:



我问过Misra的市场需求是什么,并被告知如果我们这样做,如果有人要求它,我们可以说他有它。我从来没有听过有人要求我们使用Misra标准。

We have a project written in C. It’s about 70K lines of code and has been written over ten years. Features and options have been added onto the original functionality over the years. The application is real time firmware to run on a microcontroller and it has some very carefully crafted interrupt handlers and other critical code. Some of the code has been optimised to work with 2us latency.

Some of the modules now have about 3 features in them as the features have grown over the years. Some of the modules and the general structure has now become tangled. It could do with more commenting and a new programmer has said that it is difficult to get into the code.

The firmware is constantly worked on by about 2 engineers, and so effectively gets run and tested every day as features or customer special versions are created.

There are a few known bugs, which we work through when we have time. Also about once a year a customer reports a bug to us that we didn't know about.

This firmware is used in quantities of about 1000 per year.

A manager (who is not technical) has said the firmware is too buggy and needs to be rewritten from scratch using a methodology like Misra. They say that by doing this the code will be bug free and we will have more robust and maintainable code.

***
Is this reasonable?

Would you rewrite from scratch? Is that the best thing to do? Is there a better strategy?

If we rewrite from scratch do you think we will be able to eliminate all the bugs?

How long do you think it would take to rewrite 70K lines using Misra coding standard?

Is one customer bug report per year per 70K lines of code excessive? What do other people see as a bug rate?

I’m a complete novice at this. I hope this is an appropriate post.

What I have tried:

I asked what the market requirement for Misra was and was told that if we did then if someone asked for it we could say that he have it. I've never heard anyone ask us for Misra standard.

推荐答案

Quote:

一位经理(非技术人员)表示固件太麻烦,需要使用像Misra这样的方法从头开始重写。他们说,通过这样做,代码将是无错误的,我们将拥有更强大和可维护的代码。

A manager (who is not technical) has said the firmware is too buggy and needs to be rewritten from scratch using a methodology like Misra. They say that by doing this the code will be bug free and we will have more robust and maintainable code.



嗯...没有无bug代码这样的东西因为您无法控制嵌入式系统中的非软件因素,以及它们如何影响微处理器或其他硬件的性能和功能,从而将损坏的或不合规格的数据提供给它。



Misra不是一种方法论。 MISRA是一个协会。他们为汽车行业的嵌入式系统开发了一套软件指南和合规性规范。像有利于人类安全而非车辆财产之类的事情。而已。它没有描述开发方法。这就是敏捷,Scrum,Rational Unified的领域......



所有其他问题都是无法回答的。只有您和您的团队才能回答。


Ummm... there is no such thing as "bug free" code simply because you cannot control non-software factors in your embedded system and how they affect the performance and functionality of a microprocessor or other hardware feeding corrupted or out-of-spec data to it.

Misra is not a methodology. MISRA is an association. They put out a set of guidelines and compliance specifications for software developed for embedded systems in the automotive industry. Things like "favor human safety over vehicle property". That's it. It does not describe a development methodology. That's the realm of Agile, Scrum, Rational Unified, ...

All of your other questions are unanswerable. Only you and your team can answer them.


如果不查看代码,很难回答。根据您的描述,有两位工程师或多或少永久地处理代码。因此,他们显然理解了代码 - 可能并非所有部分都有,并且可能希望他们在一年中对文档和代码清理投入更多。尽管如此,这并不是一个糟糕的起点。



另一方面:当从头开始重写时,必须保证新代码能够满足所有功能和现有代码的时间标准 - 完全不是一项微不足道的任务。您甚至可能希望能够将其运送到您现有的客户群。在这种情况下,你必须非常确定重写在所有这些位置完美无缺。正如Jeron1已经指出的那样,你可能很容易最终得到一个比现有产品更多的错误(至少在开始时)。无论如何,这将是一项重大的开发工作。



我可能会做什么:彻底分析您现有的代码 。无论如何,即使您后来决定进行重写,也必须这样做。然后相应地记录您现有的代码,甚至是您不喜欢的部分(将是分析的结果)。然后决定要重写的部分 - 根据你的分析结果,这可能是从几个模块到完全重写的任何东西。



无论如何我会在真正理解现有代码的作用,它的弱点是什么,所有(未记录的)特性和要求是什么之前,不要做出决定。
This is difficult to answer without taking a look at the code. From what you describe there are two engineers working on the code more or less permanently. So they apparently do understand the code - perhaps not in all parts and perhaps wishing they had invested more into documentation and code cleanups over the year. Nevertheless, that is not a bad starting point at all for improvement.

On the other hand: When rewriting from scratch one has to guarantee that the new code fulfills all functions and timing criteria of the existing code -- not at all a trivial task. Probably you want even to be able to ship it to your existing customer base. In that case you must be VERY sure that the rewrite performs at all those locations flawlessly. And as Jeron1 already pointed out, you could easily end up with a rewrite that has more bugs (at least in the beginning) than your existing product. In any case this is going to be a major development effort.

What I would probably do: Analyze your existing code thoroughly. That would have to be done anyway, even if you later decide to do a rewrite. Then document your existing code accordingly, even or particularly the parts you don't like (will be a result of the analysis). Then decide which parts to rewrite - depending on the results of your analysis this might be anything from just a few modules up to a complete rewrite.

In any case I would not make a decision before really understanding what the existing code does, what its weaknesses are, what all the (undocumented) features and requirements are.


引用:

我们应该从头开始重写我们的软件吗?

Should we rewrite our software from scratch?



我们在最糟糕的地方给你通知,因为我们没有详细信息关于该代码及其问题。工作的2位工程师可能对这个问题有更好的了解。


We are at the worst place to give you informed advices because we don't have details on that code and its problems. The 2 engineers working on it probably have a better idea on the question.

引用:

他们说这样做这个代码将是无错误的,我们将拥有更强大和可维护的代码。

They say that by doing this the code will be bug free and we will have more robust and maintainable code.



充其量,那些是虔诚的嚎叫

无错误:有史以来计算机,除了最简单的程序之外没有任何程序一直没有bug。

向NASA询问他们对无bug软件的看法,上帝知道bug对他们来说是致命的。

火星气候轨道器 - 维基百科 [ ^ ]

更强大和可维护的代码:它完全取决于编写它的人。没有人可以保证你有这种好处。


at best, those are pious whishes
Bug free: In history of computers, no program beyond the simplest ones have been bug free, ever.
Ask NASA what they think about bug free software, and god knows how a bug can be deadly for them.
Mars Climate Orbiter - Wikipedia[^]
more robust and maintainable code: it fully depend on the people writing it. Nobody can ever guaranty you about this kind of benefits.

引用:

每年大约一次客户报告一次我们不知道的错误。

Also about once a year a customer reports a bug to us that we didn't know about.



我会说价格相当低。



我的回答:如果你的实际软件没有重大问题,请不要从头开始重写。

我宁愿应用静态分析等现代工具来帮助校对代码并提示错误。

确保代码完整记录也是个好主意。


I would say the rate is rather low.

My answer: If you don't have major problems with actual software, don't rewrite it from scratch.
I would rather apply modern tools like static analyze to help proofing the code and hint bugs.
Ensuring the code is fully documented is a good idea too.


这篇关于我们应该从头开始重写我们的软件吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆