软件重写与运行成本分析

Question

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

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

我已向管理层暗示过几次停机成本，开发人员随叫随到，额外的运营人员，不满意的客户等等，这些都使得企业在中等，甚至可能是短期内的成本要高得多。它会全力以赴地重新编写/重构/替换整个事物（代码库大约是300k行）。

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

Answer 1

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

Answer 2

首先想到的是你过早地处理了重写/重构/替换参数。我建议的第一步两步是：

1. 单元测试
2. QA

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

QA - 拥有一支独立（积极）的质量保证团队，在生产前严格测试beta版本。他们的测试计划和测试程序对于任何替换工作都是必不可少的。

一旦您掌控了代码，您就可以合理地考虑大规模的变更。

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

Answer 3

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

其次，分析的概率为99％（我喜欢戏剧性的数字）如下：

• 顾问探讨应用程序
• 顾问确实了解应用程序的10％
• 时间到了，报告的时间
• 顾问建议完全重写（不重构，简单重写）

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

这里只有两个解决方案：

• 保持实际的源代码，但确定解决问题的正确方法，以便您有一个很长时间的重构，这是由知道应用程序的人进行的。
• 让一个辅助团队制作一个新的应用程序来替换旧的

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

• 他们在旧应用程序上太忙了
• 会有摩擦，因为新人无疑会低估手头的任务。

我从经验谈起，相信我。

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

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

Answer 4

我认为您的描述提供了有关代码质量的所有必要信息（缺乏代码质量）。需要如此多的支持资源这一事实也表明维护现有系统所涉及的高成本。

当我回答here时，一个好的方法是一次重构一个系统，直到一切都在可接受的水平上。我同意Joel不要丢弃现有代码（请参阅Things You Should Never Do。部分代码可以正常运行，因此您应尽可能保留这些代码，并专注于导致停机的部分。

安迪也很重视从小开始。

要尝试的另一件事是审查系统周围的流程。执行此操作时，您应该尝试确定用户操作直接或间接导致的故障情况？是否存在配置或环境问题？如果您无法直接修复代码，那么您仍然可以通过更有效地处理外部问题来支持它。

Answer 5

代码已经存在了30年？

在过去的三十年中，发展模式已经在很多方面发生了重大变化，而且我认为，与您的困境最相关的是创建输入所需的时间（以人日为单位） - ＆gt;过程 - ＆gt;输出一些东西。

30年前300,000行代码，今天可能会达到10万行甚至更少，并且花费更少的工时（？）这对某些人来说似乎是乐观/荒谬的，但另一方面是可实现，具体取决于相关应用的类型。您没有给出系统分类的任何指示 - 它是一种实时的制造过程控制系统，其中包含传感器和执行器吗？航空公司预订系统？它会后处理一些积压的数据吗？换句话说，它可以用像Java这样的东西重建，并且很快会与一个激进的，小型团队一起重建吗？是否记录了要求，如果需要，是否需要从头开始更新或重新开发？人身安全是一个因素吗？

只是一个快速的理智检查，我认为你是否应该重建取决于（任何顺序意味着同样的事情）：

1. 所需的代码数量。
2. 这些家伙的专业水平。
3. 哪种语言不合适。
4. 适合哪种语言。
5. 在硬件和软件方面使用所选语言的费用是多少。
6. 业务依赖于此以保持活力。
7. 停机时间真的太多了，还是只是在挑剔？ （也许他们真的不在乎，而是假装）。

祝你好运！

Answer 6

1. 阅读书籍Working Effectively with Legacy Code（另请参阅short PDF version）并按照该书中的说明使用自动化测试包围代码。

2. 一点一点地重构系统。如果重写代码的某些部分，请一次执行一个小型子系统。不要试图制作Grand Redesign。