软件重写与运行成本分析

我作为程序员工作的IT部门围绕着一个有30多年历史的代码库(Fortran和C).代码处于不良状态,部分原因在于30多年来特别缺乏深思熟虑的变化,但我也怀疑很多代码与进行更改的程序员的能力有关(顺便说一下,他们仍然是周围).

依赖于该软件的业务每年运行363天,每天运行20小时.不幸的是,有很多次中断.这是我工作的第一个地方,有开发人员随叫随到将操作代码修复程序应用于生产系统.当我第一次出现时,生产服务器上实际上有一个源代码和开发工具的副本,以便可以实时应用更改; 谢天谢地,这种做法现在已经停止了.

我已经暗示了几次管理,该停工的成本,具有呼叫,额外的业务人员,unsatisifed客户等开发商都花费了业务多了很多在中期,甚至可能是短期的,会比以推出全心努力,重新写/重构/替换整个事情(代码底座约30万线).

理想情况下,它们可能是一些外部咨询,可以进入并运行规则的质量规则以及保持运行与重写/重构/替换它所涉及的成本.我的问题是企业应该如何对软件进行这种成本分析,并且能够对该分析有信心？街头的第一批IT顾问可能会声称能够进行分析,但管理层如何能够对内部员工告诉他们的内容感到满意？

我们最近决定从头开始完全重写我们的大部分业务代码,但它并没有像我们希望的那样好.我已经看到很多引用说你永远不应该尝试从头开始重写任何东西,现在我明白了为什么.我建议从小开始 - 不要试图一次重写整个事情.确定大问题区域,并专注于一次重构系统的一小部分.由于系统中有超过30年的工作量,因此需要很长时间才能使其恢复到合理的状态.我们有大约5 - 8年的工作要重写,而且很难.我无法想象30多年的工作!

首先想到的是你过早地解决了重写/重构/替换参数.我建议的第一步两步将是:

单元测试

QA

实现这些是完全在工程范围内的.在可能进行任何合理的重构或重写之前,单元测试是必不可少的初步步骤.通过'单元测试',我的意思是用相应的代码包装每个函数调用,证明代码适用于所有已知条件.在复杂的改造中,这可能实际上并不是最精细的,但任何自动化测试都会有很大帮助.

QA - 拥有一支独立(积极)的质量保证团队,在生产前严格测试beta版本.他们的测试计划和测试程序对于任何类型的更换工作都至关重要.

一旦您掌控了代码,您就可以在业务上合理地考虑大规模变更.

只是关于您对外部顾问的评论的说明 - 没有咨询公司会对代码提供足够的关注以提供真实的质量保证.质量保证最终与捍卫公司底线的企业结婚.它最终是一个内部功能,外部顾问提供的不仅仅是让你真正开始.

首先,您需要的顾问资料非常具体.除非您能找到使用相同语言在类似域中工作的人,否则不要雇用他.

其次,有99%的概率(我喜欢戏剧性的数字)分析将如下:

顾问探索了该应用程序

顾问确实理解了10%的申请

时间到了,报告的时间到了

顾问建议完全重写(不重构,简单重写)

因此,您也可以使顾问的经济成本降低.

这里只有两个解决方案:

保持实际的源代码,但确定解决问题的正确方法,以便您有一个很长的运行重构,由那些知道应用程序的人进行重构

让一个辅助团队制作一个新的应用程序来替换旧的应用程序

如果我谈论一个二级团队,那是因为你不能只带一个架构师来制作新的应用程序并让老团队与他一起工作:

他们在旧应用程序上太忙了

会有摩擦,因为新人无疑会低估手头的任务

我从经验谈起,相信我.

如果你去"新申请"的方式不要把你的希望太高.您最终会得到一个功能不到当前功能的一半的应用程序,因为您无法将30多年的特殊情况和特殊情况修复到新设计的软件中.

哦,如果您的开发人员碰巧告诉您他们有计划,请务必听取他们的意见.他们很可能知道他们在说什么.