|
|
7 回复 | 直到 15 年前
|
1
19
向您的经理解释这些问题,指出除非您删除代码中的技术债务,否则支持成本将继续增加。建议他尽快去重写,以现有系统为模板进行功能,即1-1替换为目标。由于开发时间的很大一部分都是为了弄清楚您需要做什么,所以这不应该像最初的开发时间那么长。拥有一个称职的开发人员可能意味着只需要一小部分时间。 让你的经理完成他的工作——计算替换项目的投资回报率——并做出决定。 |
|
|
2
5
实际上,这取决于你所看到的东西的大小和范围。
看看上面的代码示例,似乎也值得将您的代码片段提交到dailywtf.com |
|
|
3
3
每个人都会时不时地继承坏代码。
不管怎样,你都得应付一段时间。我会尽你所能清理,或者-如果这是面向客户的-推动安全问题。如果代码像我从你发布的文章中怀疑的那样糟糕,那么它可能到处都是SQL注入之类的东西,再加上一些CSRF和XSS。因此,如果您将它用于任何需要安全的事情,您可以为“改进”它提供一个很好的理由。 |
|
|
4
2
向您的客户解释,以前的顾问可能在他们头上。代码是不可管理的,需要重写。如果你想解开这个烂摊子,那么解释一下,成本将超过从头重写。我以前不得不这么做。大多数时候重写比较容易。 |
|
5
2
|
|
|
6
1
维护代码。这很糟糕,但是你在这个行业工作的时间越长(并且被赋予维护的任务),你就越会意识到宝石并不是你见过的最糟糕的东西。。。 只要学会利用你所拥有的,并尽可能多地提供好处。当然,如果你真的对代码进行了深入的评估,并且仍然得出结论,你可以从头开始编写代码,比修复代码要快,那么就向你的老板提供(计划好的)时间表,看看它去了哪里。 |
|
|
7
0
我猜,正如你所知道的,这里没有简单的答案,处理遗留代码是我们行业中最令人沮丧的事情之一,但我们大多数人不得不经常处理。在你继续之前,我的建议是确保你了解项目的确切范围,将其分解为必备品和理想品。然后你可以先更密切地关注最重要的领域。就重用/重构/重写等的选择而言,这将真正取决于代码最初的糟糕程度以及代码的未来需求。 |
推荐文章