何时从头开始重写代码库

Question

何时从头开始重写代码库

Jac*_*tti 61 architecture testing tdd

我想回到Joel Spolsky关于永远不会从头开始重写代码的文章.总结一下他的论点:代码不会生锈,虽然在许多维护版本发布之后可能看起来不太好,但如果它有效,它就可以了.最终用户并不关心代码的漂亮程度.

你可以在这里阅读文章:你不应该做的事情

我最近接管了一个项目,在查看了他们的代码之后,它非常糟糕.我立刻想到了我之前构建的原型,并明确声明它不应该用于任何生产环境.但当然,人们不听.

代码是作为一个网站构建的,没有任何关注点,没有单元测试和代码重复.没有数据层,没有真正的业务逻辑,除非你在App_Code中计算一堆类.

我已向利益相关方提出建议,虽然我们应该保留现有代码,并进行错误修复发布和一些小功能发布,但我们应该立即开始重新编写测试驱动开发并明确分离关注点.我正在考虑使用ASP.NET MVC路由.

我唯一关心的是从头开始重写可能需要的时间.这并不是完全复杂的,有会员资格的磨坊网络应用程序.

你们有没有遇到类似的问题？你采取了什么特别的步骤？

更新:

那么......我最终决定做什么？我采用了马特的方法并决定重构许多领域.

由于App_Code变得相当大,从而减慢了构建时间,因此我删除了许多类并将它们转换为类库.
我创建了一个非常简单的数据访问层,它包含所有ADO调用,并创建了一个SqlHelper对象来执行这些调用.
我实现了一个
更简洁的清洁日志解决方案.

虽然我不再参与这个项目[资金,政治,等等],但我认为它让我对一些项目的编写能力有了很大的了解,并且开发人员可以采取措施使事情变得更加清晰,可读和公正随着时间的推移逐渐变小,逐渐变平.

Answer 1

Mat*_*att 59

仅仅因为它现在有所有这些问题并不意味着它必须继续拥有它们.如果您发现自己在系统中进行了特定的错误修复,可以从新数据层中受益,那么请创建一个新的数据层.仅仅因为整个网站不使用它并不意味着你不能开始使用它.在修复错误时需要重构.并确保在更改之前准确了解代码的作用.

代码重复问题？下次必须修复重复代码中的错误时,将其拉出到类或实用程序库的中央位置.

并且,正如其他响应者已经提到的那样 - 现在开始编写测试.如果代码听起来像是耦合的话可能很难,但你可能从某个地方开始.

没有充分的理由重写工作代码.但是,如果您已经修复了错误,则没有理由不能使用"更好"的设计重新编写代码的特定部分.

+1.这是唯一明智的做法.你不需要太多的老板批准(我实际上正在修复bug /实现一个功能)并且你改善了事物的状态 (9认同)
这是一个非常棒的主意.有点重写它而不从头开始. (3认同)

Answer 2

cle*_*tus 18

乔尔的文章真的说明了一切.

基本上没有.

正如乔尔所指出的那样:你只会从头开始做太多的失败.这可能比你想象的要长,最终结果是什么？基本上做同样事情的东西.这样做的商业案例是什么？

这是一个重要的观点:从头开始写东西要花钱.你将如何收回这笔钱？许多程序员忽略了这一点仅仅是因为他们不喜欢代码 - 有时候是有理由的,有时候不是.

其中只有"性能问题"才真正重要.问题是什么？一个月的开发时间可以轻松购买具有32GB RAM的8核服务器.如果这样可以解决您的性能问题,请改为执行此操作.重写和不可避免的错误修正将采取更长的时间. (7认同)

Answer 3

swa*_*ord 18

"软件工程的事实和谬误"一书陈述了这样一个事实:"重用代码的修改特别容易出错.如果要修改超过20%到25%的组件,从头开始重写它会更有效率. " 这些数字来自对该主题进行的一些统计研究.我认为数字可能会因代码库的质量而有所不同,因此在您的情况下,考虑到此语句,从头开始重写它似乎更有效率.

这是一个组件,而不是一个完整的应用程序/代码库! (7认同)
我认为这实际上是一个重点.如果你必须在现有的,混乱的代码库上大幅增长,重新开始是有道理的.而不是重写"只是因为它看起来很糟糕"的东西 (2认同)

Answer 4

Mil*_*kov 11

我有这样的应用程序,重写是非常有益的.但是,您应该尝试避免"改进"陷阱.

当你重写所有内容时,添加新功能并解决一些你没有勇气去触摸的长期问题是非常诱人的.这可能导致功能蠕变,并且还可以极大地延长重写所需的时间.

确保您事先确定将要更改的内容以及仅重写的内容.

推论:确保您已知道可比较的标准.如果您开始重写以进行优化,则必须确保以前的代码有效,并且您编写的代码将重现旧代码的确切功能.否则,您正在制作新代码而不是改进旧代码. (3认同)

Answer 5

ste*_*r25 7

我有点不同意那篇文章.在大多数情况下,乔尔是正确的,但有反例表明有时(即使很少)重写是一个好主意.例如,

Windows NT(远离旧的DOS代码库.在此基础上构建了Win2k,WinXP和即将推出的Win7.是的,Vista也是.旧基础上的最后一个版本的Windows是臭名昭着的WinME)
Mac OS X(在FreeBSD上重建旗舰产品)
许多竞争对手取代事实上的标准的案例.(例如,Excel与Lotus 123)

我相信Joel的论点主要基于现有版本中编写得相当好的代码,可以通过后见之明进行改进.无论如何,如果你继承的代码真的那么糟糕,那就推动重写 - 那里有一些可怕的东西.如果它完全可以忍受并且工作得相当好,那么以较慢的速度逐步进入新的东西.

Windows NT 的很大一部分直接祖先可以追溯到 OS/2，它的创建是为了利用非常先进的 Intel 80286 CPU（16 MiB 地址空间，Intel 允许高达大约 12 MHz 时钟）并加强 IBM 的控制微软/英特尔/IBM PC 行业。* 经典 Mac 操作系统一直遇到越来越多的设计限制；与 OS X 相比，该操作系统适用于“非常”不同类别的硬件。 * 竞争对手产品替代是一种特殊情况，通常无论您多么想要，您都无法访问源代码。 (2认同)

Answer 6

sof*_*eda 7

我是一个小型专职团队的成员,该团队从头开始重写代码,包括早期代码的逆向工程业务规则.原始应用程序是用C++编写的Web服务(常规崩溃和严重的内存泄漏)和ASP.Net 1.0 Web应用程序,替换是基于C#2.0 asmx的Web服务和带有Ajax的ASP.Net 2.0 Web应用程序.这就是团队所做的一些事情并向管理层解释

在新代码准备好之前,我们支持生产中的现有代码库.
管理层同意重写(第一版)不会引入新功能,只会实现现有功能.我们最后只添加了1-2个新功能.
小团队由经验丰富的开发人员组成,他们具有出色的理解能力和合作.
在组织中获得C++人才更加困难,而C#被视为未来维护的更好选择.
我们同意了一个激进的时间框架,但同时对C#2.0,ASP.Net 2.0等工作充满信心并且积极主动.
我们有一个团队领导来保护我们免受高层管理人员的攻击,我们遵循scrum这样的流程.

该项目非常成功.它非常稳定,表现更好.稍后,添加新功能会更容易.因此,我相信在适当的资源和环境下,可以成功完成代码重写.

Answer 7

mmr*_*mmr 6

只有一个准合法的理由浮现在脑海中:政治.

我不得不从头开始重写代码库,这与政治有关.基本上,管理代码库的前一个程序员太尴尬了,不能将源代码发布给刚刚被雇用的新团队.她觉得每一个对代码的批评都是对她作为一个人的批评,结果,她只是在被迫时向我们其他人发布代码.她是唯一对源存储库具有管理访问权限的人,每当她被要求释放所有源代码时,她都会威胁要退出并掌握她对代码的所有知识并回家.

这个代码库已有超过15年的历史,并且有各种不同风格的不同人群的卷积和扭曲.这些风格中没有一个显然涉及评论或规格,至少在她发给我们的一小部分中.

由于只有部分代码和截止日期,我被迫完全重写.因此我被大吼大叫,因为据说我造成了严重的延误,但我只是低下头,完成了而不是争辩.

政治可能是一个巨大的痛苦.

归档时间：	16 年，2 月前
查看次数：	11129 次
最近记录：	7 年，9 月前