Questions tagged «legacy»

从目前的情况来看，这个问题不适合我们的问答形式。我们希望答案会得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 加入已经拥有大型代码库的现有团队可能会令人生畏。最好的方法是什么？ 广阔; 尝试从代码中获得所有内容如何链接在一起的一般概述 狭窄; 一次专注于一小段代码，了解它们如何充分发挥作用 选择一项功能，以在发展中学习和学习 尝试从类图和uml中获得见解（如果有）（并且是最新的） 还有其他东西吗？ 我正在研究目前大约有2万行的C ++应用程序和库（编辑：在宏伟的计划中占很小的空间！）。在行业中，我想您会得到经验丰富的程序员的介绍。但是，如果不是这种情况，您应该怎么做才能尽快开始增加价值？ - 答案摘要： 在调试模式下单步执行代码以查看其工作方式 与比您更熟悉代码库的人配对，轮流成为编码人员和观看/讨论人员。在团队成员中轮换合作伙伴，以便知识传播。 编写单元测试。首先声明您认为代码将如何工作。如果结果符合您的预期，则您可能已经理解了代码。如果没有，您将有一个难题需要解决，或者需要进行询问。（感谢多纳尔，这是一个很好的答案） 与上述类似，对功能代码进行现有的单元测试 阅读UML，Doxygen生成的类图和其他文档，以广泛了解代码。 进行少量编辑或错误修复，然后逐步建立 记笔记，不要跳进去开始发展；花时间理解比生成混乱或不合适的代码更有价值。 这篇文章是使用继承的代码库熟悉自己的最佳方法的部分重复

75 legacy  legacy-code  codebase 

我们有一个大型的，用C语言编写的多平台应用程序（使用的C ++数量很少，但数量在不断增长）。随着多年来的发展，它具有许多您希望在大型C / C ++应用程序中使用的功能： #ifdef 地狱 大文件使得难以隔离可测试代码 功能太复杂而无法轻松测试 由于此代码是针对嵌入式设备的，因此在实际目标上运行它会产生大量开销。因此，我们希望在本地系统上快速完成更多的开发和测试。但是，我们希望避免采用经典策略“将文件复制/粘贴到系统上的.c文件中，修复错误，然后复制/粘贴回”。如果开发人员要麻烦这样做，我们希望以后能够重新创建相同的测试，并以自动化的方式运行。 这是我们的问题：为了将代码重构为更具模块化，我们需要使其更具可测试性。但是，为了引入自动化的单元测试，我们需要使其更具模块化。 一个问题是，由于我们的文件太大，因此我们可能在文件中包含一个函数，该函数在同一文件中调用一个函数，因此需要对它进行存根以进行良好的单元测试。随着我们的代码变得更加模块化，似乎这将不再是问题，但这还有很长的路要走。 我们考虑做的一件事是用注释标记“已知是可测试的”源代码。然后，我们可以编写脚本扫描源文件以获取可测试的代码，将其编译为单独的文件，然后将其与单元测试链接。我们可以在修复缺陷和添加更多功能时慢慢介绍单元测试。 但是，令人担忧的是，维护此方案（以及所有必需的桩函数）将变得很麻烦，并且开发人员将停止维护单元测试。因此，另一种方法是使用一种工具，该工具会自动为所有代码生成存根，并将其与文件链接。（我们发现唯一可以执行此操作的工具是昂贵的商业产品），但是这种方法似乎要求我们所有的代码在开始之前都必须更加模块化，因为只能进行外部调用。 就个人而言，我希望开发人员考虑其外部依赖关系并智能地编写自己的存根。但是，如果将所有依赖项存根为一个严重过度增长的10,000行文件，可能会不堪重负。可能很难说服开发人员他们需要维护所有外部依赖项的存根，但这是正确的方法吗？（我听到的另一个论点是子系统的维护者应维护其子系统的存根。但是我想知道是否“强迫”开发人员编写自己的存根会导致更好的单元测试？） 的#ifdefs，当然，再添全尺寸的问题。 我们已经研究了几种基于C / C ++的单元测试框架，并且有很多看起来不错的选项。但是我们还没有发现任何简化从“没有单元测试的代码圈”到“可单元测试的代码”的过渡的方法。 因此，这是我对遇到过此问题的其他人的疑问： 一个好的起点是什么？我们是朝着正确的方向前进，还是缺少明显的东西？ 哪些工具可能有助于过渡？（最好是免费/开源，因为我们目前的预算大约为“零”） 注意，我们的构建环境是基于Linux / UNIX的，因此我们不能使用任何仅Windows的工具。

74 c++  c  unit-testing  unix  legacy 

我有一些旧代码的包装。 class A{ L* impl_; // the legacy object has to be in the heap, could be also unique_ptr A(A const&) = delete; L* duplicate(){L* ret; legacy_duplicate(impl_, &L); return ret;} ... // proper resource management here }; 在此旧版代码中，“复制”对象的函数不是线程安全的（调用相同的第一个参数时），因此const在包装器中未对其进行标记。我猜想遵循现代规则：https : //herbsutter.com/2013/01/01/video-you-dont-know-const-and-mutable/ 这duplicate看起来是实现复制构造函数的一种好方法，除了细节不是const。因此，我不能直接这样做： class A{ L* impl_; // the legacy object has …

9 c++  c++11  thread-safety  legacy  const-correctness 

对于具有旧版本的应用程序中的某些库代码，我具有IIFE函数，这些代码需要适用于IE10 +（无需加载ES6模块等）。 但是，我开始开发一个将使用ES6和TypeScript的React应用，并且我想重用我已经拥有的代码而不复制文件。经过一番研究，我发现我想使用UMD模式来允许这些库文件既可以作为<script src=*>导入工作，又可以让React应用程序通过ES6模块加载来导入它们。 我想出了以下转换： var Utils = (function(){ var self = { MyFunction: function(){ console.log("MyFunction"); } }; return self; })(); 至 (function (global, factory) { typeof exports === 'object' && typeof module !== 'undefined' ? factory(exports) : typeof define === 'function' && define.amd ? define(['exports'], factory) : (factory((global.Utils = …

9 javascript  reactjs  es6-modules  legacy  iife