Questions tagged «legacy»

有关遗留语言，代码或应用程序的问题。

6
淘汰过时的数据库列的最佳实践是什么？[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 2年前关闭。 我正在设计一个应用程序，它将在早期阶段从客户端收集数据A，B和C，但稍后将收集数据A，B和D。 A，B，C和D非常相关，现在作为单个数据库PostgreSQL表T的列存在。 一旦不再需要C，我想从我的应用程序中删除它的引用（我使用Django ORM），但是我想保留已经输入的数据。最好的方法是什么？ 我曾考虑过为ABD创建一个新表，但这意味着可能会导致引用表T的任何行出现问题。 我可以只保留C列，并删除代码中对它的引用，以使现有数据得以保留。 有没有我看不到的更好的选择？ 一些额外的细节： 行数不会很大，很可能每个用户1-2行。这是一个大众市场应用程序，但是当我从C切换到D时，用户群还不会很大。尽管有可能，但C和D可能不会同时收集。C和D可能分别代表多个列，而不仅仅是每个列。
3
支持旧操作系统的开发
我维护着大部分用C编写的遗留代码。此代码最初被编写为针对Windows 3 for Workgroups进行编译，后来创建了NT版本。这个旧版应用程序至今仍在使用，自90年代初开始在3.11和NT工作站上愉快地运行。它可以正常工作，并且可以完成预期的工作，而它们仍然存在的原因是，属于该解决方案的某些自定义硬件的驱动程序与以后的Windows不兼容。 我维护了另一个应用程序，出于相同的原因，该应用程序仅在Win2k上有效。 但是，随着事情的发展，运行这些旧环境变得越来越困难。现在，我保留安装了开发软件的物理机，因此可以在本机硬件上工作。但是这些可能会随时死亡（毕竟他们已经25岁了）。 所以我的问题是，从2016年开始，我有什么选择可以更稳定地维护这一古老环境？您可以将3.11迁移到云托管吗？ 我尝试了虚拟化，但是由于设置的特殊性，我无法使其与设备驱动程序一起使用，因此我认为可能需要按原样制作完整的操作系统映像，然后在一个操作系统中运行该映像。 VM开发软件？这样的事情可能对来宾操作系统版本一样古老WIN3和NT？ 是否有任何经验可以使类似的旧平台存活下来进行开发，但是我可以借鉴更现代，更安全的方式？ 我的目标是摆脱旧的物理机，然后转向虚拟化。
14 c  windows  legacy 
8
如何处理推动旧系统的管理？
我目前正在带薪实习中，并且负责维护由过去五年来由多个开发人员（在不同时间）开发的过时系统。管理层同意“该系统具有生命支持”，并且我从当前使用该系统的最终用户那里收到定期报告的错误报告。 管理层现在希望将该项目再延长一年，在此过程中，用户群几乎增加了两倍。 作为一名实习生（或任何入门级职位），我该如何“退缩”？我已经写了一份报告，陈述了我的担忧，尽管它是开放式文档。是否有用于建议更改的协议或文档类型？我是否可以提出建议，还是应该继续支持旧系统？ 要澄清的是，软件开发不是我公司的主要业务。因此，不存在内部协议。此外，该项目根本没有正式文档，也没有需求文档。发展是非常特别的。
3
如何处理“软件寿命终止”情况？
当供应商宣布不再打算为某个软件提供任何支持或服务时（并表示打算退出该业务-不提供升级途径），客户可以使用哪种资源？ 请考虑从 客户的角度。客户的IT员工可能只会考虑技术选择，但是客户也可能会追求非技术选择。另外，客户可以提前采取什么样的合理步骤来最大程度地减少中断，例如合同条款？ 我能想到的事情： 需要购买备用硬件并设置备用环境，软件可以在该环境下继续运行。 不需要卖方参与的各种数据导出方法。（这可能包括诸如检查商品数据库后端中存储的数据之类的琐碎技术，以及诸如屏幕抓取，打印到图像然后重新扫描等更复杂的技术） 工作人员将手动或半自动将旧数据复制到新系统的并行系统 以法律手段，以防卖方出现财务问题（例如，源代码托管） 还有其他想法吗？ 假设不涉及“规避”（没有DRM，没有DMCA），数据恢复或逆向工程是否合法/可以接受？ 编辑说明： 它是几个轶事，但真实的故事的结合。我没有直接参与其中的任何一个。我只是想了解一般如何处理“软件报废”情况。我不想使原始故事听起来太“难”而无法解决。
3
穷人的依赖注入是将可测试性引入旧版应用程序的好方法吗？
在过去的一年中，我使用依赖注入和IOC容器创建了一个新系统。这教会了我很多关于DI的知识！ 但是，即使在学习了概念和正确的模式之后，我仍然认为将代码解耦并将IOC容器引入旧版应用程序是一个挑战。该应用程序足够大，以至于真正的实现将是压倒性的。即使理解了价值并准予了时间。谁有时间抽出这样的东西？ 当然，目标是将单元测试引入业务逻辑！ 与防止测试的数据库调用交织在一起的业务逻辑。 我已经阅读了这些文章，并且了解了这篇Los Techies文章中描述的穷人依赖注入的危险。我了解它并没有真正分离任何东西。 我知道它可能涉及很多系统范围的重构，因为实现需要新的依赖项。我不会考虑在任何大小的新项目中使用它。 问题：可以使用穷人的DI 将可测试性引入旧版应用程序并开始滚动吗？ 另外，使用穷人的DI作为真正依赖注入的基层方法是否是教育该原理的需求和收益的有价值的方法？ 您是否可以重构具有数据库调用依赖关系的方法，并将该调用抽象到接口后面？简单地拥有这种抽象将使该方法可测试，因为可以通过构造函数重载传递模拟实现。 将来，一旦获得支持者的支持，就可以对该项目进行更新以实现IOC容器，并且构造函数将在那里使用抽象。
5
破旧/旧版单元测试
我在一家大公司工作，负责一个带有数千个junit测试的大型Java应用程序。自从我担任这个职位以来，已经有200到300个失败的测试（可能是多年失败的测试）。这些测试既旧又脆弱，并且杂乱无章，通常以实时沙盒数据结尾。 我的目标是100％通过测试，这样我们就可以打破单元测试失败的基础，但是直到解决了失败的测试之后我才能做到。我的预算很少，因为维护预算主要用于支持，但是我的团队已经确定并修复了低挂的水果测试（主要是配置/本地资源问题），而我们的测试只有30-40个非常丑陋。 对最佳实践有何看法？我认为测试不是有价值的，但是我也不知道他们正在测试什么，或者为什么他们不钻研就无法工作，这需要我们花费很多时间和金钱。 我想我们应该用我们知道的任何东西记录破损测试的状态，然后完全删除或忽略破损测试，并输入一个较低优先级的错误/工作项来调查和修复它们。然后，我们将达到100％的水平，并开始从其他测试中获得真正的价值，如果我们有维护/重构的意外之财，我们将能够再次进行选择。 最好的方法是什么？ 编辑：我认为这是一个不同于该问题的问题，因为我对我们应该编写的测试有明确的方向，但是我继承了遗留失败的测试，以便在当前的大量测试变得有意义之前解决这些问题。
3
非IT经理应如何确保必需的旧版软件的长期维护和开发？
我们是一家规模很小，非常专业的福利管理公司，拥有非常有用，功能强大的软件集合，其中一些是用COBOL编写的，但大多数是用BASIC编写的。在过去的30多年中，有两名全职顾问稳定地维护和改进了该系统。不用说他们即将退休。（他们中的一个人已经迫切退休了，但是忠于错误，所以尽管丈夫坚持高尔夫应该优先考虑，但他们仍然坚持下去。） 我们开始了向该系统的转换，该系统由该国仅有的三家提供我们所用软件类型的公司之一开发。我们现在认为，尽管该公司理论上有能力完成转换过程，但是他们没有及时完成转换的资源，并且我们已经开始相信他们将无法提供我们需要的那种服务我们的业务。（没有什么能够设定自己的优先级并有权按自己认为合适的方式分配资源的。） 硬件不是问题-我们能够在现代服务器上非常有效地进行仿真。如果COBOL和BASIC是现代语言，我们愿意冒着风险，可以为未来的现有顾问找到替代品。 一家IT支持公司似乎应该有一种业务模型，该公司应专注于这样的旧平台，并提供编程和软件开发人才来支持像我们这样的系统，从而避免了寻找合适的编程人才的风险。说服年轻的程序员，他们可以有一个富有成果的，有回报的职业，这项工作的一部分是使用一种古老的，非性感的语言（例如BASIC）。 简而言之，作为非IT经理，我们如何最好地管理这一过渡？
13 legacy 
5
解决由于重构引起的合并冲突
最近，我参与了有关如何处理重构的讨论（这本身就是一个有趣的话题）。最终提出了以下问题： 一个人如何处理由于某人对一部分代码进行重构而其他人在为同一段代码开发功能时发生的合并冲突呢？ 基本上，我不知道如何有效地处理这一问题。在这方面是否应遵循任何最佳做法？对于具有大量旧代码的系统，应该如何处理呢？
2
将单元测试添加到旧的普通C项目中
标题说明了一切。我公司正在将微控制器设备的旧固件项目重复使用，完全用纯C语言编写。 有些部分显然是错误的，需要更改，并且这些部分来自C＃/ TDD背景，我不喜欢无测试地随机重构内容以确保功能保持不变的想法。此外，我已经看到，在很多情况下，通过微小的更改就引入了难以发现的错误（如果使用回归测试，我相信这是可以解决的）。为避免这些错误，需要格外小心：很难在代码周围跟踪大量的全局变量。 总结一下： 在重构之前，如何在现有的紧密耦合代码中添加单元测试？ 您推荐什么工具？（重要性不高，但仍然很高兴知道） 我没有直接参与编写此代码（我的责任是一个可以通过多种方式与设备交互的应用程序），但是如果有可能使用它们时，如果抛弃了良好的编程原则，那将是很糟糕的。
6
大型机有哪些优势？[关闭]
按照目前的情况，这个问题并不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 8年前关闭。 大型机的缺点是被践踏的；昂贵，遗留，日渐萎缩的社区等。 我对不利因素并不特别感兴趣，但是我很好奇大型机硬件/软件是否比当前的Intel / AMD和Linux / Windows环境有任何好处。 有人告诉我，在I / O负载很重的情况下，MF特别好（并且比当前服务器还要好）。这仍然是真的吗？
11 legacy  mainframe 
12
作为年轻的开发人员，我应该担心在工作中必须使用“过时的”技术吗？[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 5年前关闭。 我是应届毕业生（去年五月！）。当我还在学校时，我想确保自己在毕业之前有一份工作，而且很早（可能太早）在求职中，我定了一个我希望本科毕业后要搬到的地区。 但是，由于几个原因，我几个月来一直在猜测这个决定。一个是我在工作中并没有受到很大的挑战，而且我觉得自从从这里开始以来，我在编程方面并没有太大的进步。不过，我总是可以抽出时间来从事开源工作（过去有过工作），所以我确实有一个机会来解决这一失望的问题。更重要的是，我担心我的工作基本上是在一个破旧的Perl Web应用程序上工作（使用Mason和一个奇怪的内部ORM）。 我是不是通过使用不再流行的技术来打我自己的脚，将来真的无法帮助我找到工作吗？我很少看到Perl的工作，而当我这样做时，通常是做我不感兴趣的事情（前端Web开发的东西）。 系统编程，可视化，网络编程或至少后端Web开发方面的东西是我真正喜欢的工作类别-似乎我目前的工作经验并没有帮助我完成这些工作。
11 legacy  perl 
5
在旧版应用程序中启动一致的体系结构
我负责基于Asp.Net的大型网站。目前，它是一个网站（不是Web应用程序），一些Windows服务和许多类库。 数据层使用LLBLGEN 和Linq To LLBGen 的混合物，以及许多尚未重构的传统内联SQL实例。 有一些管理器类型的实现，但是在许多情况下，该应用程序都具有Smart UI反模式（即，类背后的代码中的业务逻辑过多） 该站点的流量相当大，性能还不错，但是我们正在将开发能力提高到大约10个团队，并且越来越明显的是，我们需要在现有中间件之上进行总体分层设计。 我的问题是从哪里开始？我们有10年的代码（其中有些实际上仍然只是在迁移ASP Classic东西），许多不同的方法和样式。 重构整个代码库是不现实的，并且可能是不希望的 我知道这不是一个新情况，关于如何解决这个问题是否有有用的想法或概念？
3
重构大型方法以确保我不会破坏任何内容时，会有什么帮助？
我目前正在重构大型代码库的一部分，而没有任何单元测试。我试图以残酷的方式重构代码，即试图猜测代码在做什么，什么更改不会改变它的含义，但是没有成功：它随机破坏了整个代码库的功能。 请注意，重构包括将旧版C＃代码移动到更具功能性的样式（旧版代码未使用.NET Framework 3和更高版本的任何功能，包括LINQ），在代码可能会从中受益的地方添加了泛型，等等。 考虑到要花多少钱，我不能使用形式化方法。 另一方面，我认为至少要严格遵循“任何重构的遗留代码都应带有单元测试”的规则，无论它要花多少钱。问题在于，当我重构500 LOC私有方法的一小部分时，添加单元测试似乎是一项艰巨的任务。 什么可以帮助我了解哪些单元测试与给定的代码相关？我猜测对代码进行静态分析会有所帮助，但是我可以使用哪些工具和技术： 确切知道我应该创建什么单元测试， 和/或知道我所做的更改是否以与现在不同的方式影响了原始代码？
4
如何更新大型遗留代码库以满足特定的质量标准？
关于用于改进遗留代码库的工具和技术的信息很多，但是我还没有遇到任何成功的现实案例研究。大多数建议都是微观的，尽管很有帮助，但由于缺乏证据，因此无法说服很多人，因为它不能在宏观上提供帮助。 我正在专门寻找渐进式改进，这些改进已被证明在更新大型遗留代码库以满足当今的质量标准而不是完全重写时在现实世界中是成功的。 之前： 大：大于1MLOC 旧版：无自动化测试 劣质：高复杂度，高耦合，高逸出缺陷 后 自动化测试 更容易的更新/维护 高质量：降低复杂度，解耦代码，避免一些缺陷 在现实世界中，已经证明了哪种增量步骤可以成功更新大型遗留代码库，以达到上述质量标准，而无需进行完全重写？ 如果可能，请在回答中包含一个示例公司或一个大型旧项目的案例研究，该项目已通过“成功的”质量改进过程以进行备份。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.