标签: legacy

加入已经存在大型代码库的现有团队可能会令人生畏.什么是最好的方法;

• 宽; 尝试从代码中全面了解所有内容如何链接在一起
• 狭窄; 一次关注一小部分代码,了解它们如何完全工作
• 选择一项功能,随着您的发展和学习
• 尝试从类图和uml中获取洞察力(如果有的话)(并且是最新的)
• 还有别的吗？

我正在研究目前大约20k行的C++应用程序和库(编辑:在宏观方案中很小!).在工业界,我想你会得到一位经验丰富的程序员的介绍.但是,如果不是这种情况,您可以做些什么来尽快开始增值？

-
答案摘要:

• 在调试模式中逐步执行代码以查看其工作原理
• 与比你更熟悉代码库的人配对,轮流成为编码人员和观看/讨论的人.在团队成员之间轮换合作伙伴,以便知识得到传播.
• 写单元测试.首先断言您认为代码的工作方式.如果结果如你所愿,你可能已经理解了代码.如果没有,你有一个难题要解决,或者要进行调查.(谢谢Donal,这是一个很好的答案)
• 以与上面类似的方式,通过现有的功能代码单元测试
• 阅读UML,Doxygen生成的类图和其他文档,以获得对代码的广泛感受.
• 进行小编辑或错误修复,然后逐步建立
• 记下笔记,不要跳进去开始开发; 花时间理解比生成凌乱或不合适的代码更有价值.

这篇文章是一个部分重复的 - 最好的方式 - 熟悉自己与继承的代码库

我们有一个用C语言编写的大型多平台应用程序(只有少量但不断增长的C++)多年来,它已经发展了许多你期望在大型C/C++应用程序中使用的功能:

• #ifdef 地狱
• 大文件使得难以隔离可测试代码
• 功能过于复杂,无法轻松测试

由于此代码是针对嵌入式设备的,因此在实际目标上运行它需要大量开销.因此,我们希望在本地系统上以快速周期进行更多的开发和测试.但我们希望避免"在您的系统上复制/粘贴到.c文件,修复错误,复制/粘贴"的经典策略.如果开发人员要麻烦这样做,我们希望以后能够重新创建相同的测试,并以自动方式运行.

这是我们的问题:为了使代码重构更加模块化,我们需要它更易于测试.但是为了引入自动化单元测试,我们需要它更加模块化.

一个问题是,由于我们的文件太大,我们可能在文件中有一个函数调用同一个文件中的函数,我们需要将它们存根以进行良好的单元测试.看起来这不是一个问题,因为我们的代码变得更加模块化,但这还有很长的路要走.

我们想到的一件事是用注释标记"已知可测试"的源代码.然后我们可以为可测试代码编写脚本扫描源文件,将其编译在单独的文件中,并将其与单元测试链接.我们可以在修复缺陷和添加更多功能时慢慢引入单元测试.

但是,有人担心维护这个方案(以及所有必需的存根函数)将变得太麻烦,开发人员将停止维护单元测试.所以另一种方法是使用一个工具,为所有代码自动生成存根,并将文件链接到该工具.(我们发现这样做的唯一工具是昂贵的商业产品)但是这种方法似乎要求我们所有的代码在我们开始之前都要更加模块化,因为只有外部调用可以被删除.

就个人而言,我宁愿让开发人员考虑他们的外部依赖关系并智能地编写他们自己的存根.但是,对于一个可怕的过度生长的10000行文件来说,这可能是压倒性的.可能很难说服开发人员他们需要为所有外部依赖项维护存根,但这是正确的方法吗？(我听到的另一个论点是子系统的维护者应该维护子系统的存根.但是我想知道"强迫"开发人员编写自己的存根会导致更好的单元测试吗？)

的#ifdefs,当然,再添全尺寸的问题.

我们已经研究了几个基于C/C++的单元测试框架,并且有很多选项看起来很好.但是我们还没有找到任何方法来缓解从"没有单元测试的代码毛球"到"单元可测试代码"的过渡.

所以这是我对其他任何经历过这个问题的人的问题:

• 什么是一个好的起点？我们是朝着正确的方向前进,还是我们错过了一些明显的东西？
• 哪些工具可能有助于过渡？(最好是免费/开源,因为我们现在的预算大致为"零")

注意,我们的构建环境基于Linux/UNIX,因此我们不能使用任何仅限Windows的工具.

我们的工作情况是,在已经感染了意大利面条代码的现有代码中添加新功能时,处理遗留(核心)系统的开发人员正在被迫使用GOTO语句.

现在,我明白可能存在使用"只需一个小GOTO"的论据,而不是花时间重构一个更易于维护的解决方案.问题是,这个孤立的"只有一点GOTO"并不是那么孤立.每周至少一次左右有一个新的"一点GOTO"要添加.由于代码可追溯到1984年或之前的GOTO,这使得许多Pastafarians认为它受到了Flying Spaghetti Monster本身的启发,因此这个代码库已经令人恐惧.

不幸的是,这里编写的语言没有任何现成的重构工具,因此更难以推动'Refactor以后提高生产力',因为短期胜利是这里唯一值得关注的胜利......

有没有其他人经历过这个问题,即每个人都同意我们不能添加新的GOTO来将2000行跳到一个随机区域,但是Anaylsts一直坚持这样做只是这一次并让管理层批准它？

tldr;

如何解决开发人员被迫(强制)不断添加GOTO语句的问题(通过添加,我的意思是添加跳转到随机区域多行),因为它" 更快地获得该功能"？

我开始担心我们可能会失去有价值的开发人员而不是这个...

澄清:

去 here

alsoThere:不,我在谈论那种从一个子程序中跳出1000行到另一个子程序中途的goto.去 somewhereClose

there:我甚至没有谈论你可以合理阅读的那种类型,并确定一个程序正在做什么.去 alsoThere

somewhereClose:这是制作肉丸的那种代码midpoint: 如果第一次在这里转到 nextpoint detail:(每一个几乎完全不同)转到 pointlessReturn

here:在这个问题中,我并没有谈论偶尔使用goto.去there

tacoBell:它刚刚回到绘图板.去 Jail

elsewhere:当分析师每周花一些时间来解决程序正在做什么时,你的代码库就会出现问题.事实上,我实际上取决于我的,hell:如果不是最新的goto goto 4转换goto detail pointlessReturn: goto tacoBell

Jail:实际上,只是一个小胜利的小更新.我花了4个小时一次重构这个特定程序的一部分单个标签,因为我去了svn中的每次迭代.每一步(其中约20)为短小,逻辑和足够容易转到 bypass nextpoint:自发地跳出你一顿,并在您完成一些奇怪的那种面条,肉丸磁性的屏幕.转到 elseWhere bypass:合理地验证它不应该引入任何逻辑更改.使用这个新的更易读的版本,我与分析师坐下来,现在几乎完成了所有这些变化.去 end

4:第一次*如果第一次在这里转到hell,没有第二次,如果第一次在这里转到 hell,没有第三次,如果第一次在这里转到 hell第四次现在最新转到 hell

end:

我将OS X升级到Yosemite,现在我的IntelliJ IDE没有启动.

这是错误消息:

要打开"IntelliJ IDEA",您需要安装旧版Java SE 6运行时.

我目前正在开发一个大型和旧的C++应用程序,在我之前有许多开发人员.项目,类和函数中有很多"死代码",任何人都不会使用它们.

有哪些工具可用于C++分析大型代码库以检测和重构死代码？注意:我不是在谈论像gcov这样的测试覆盖率工具.

你如何在项目中找到死代码？

您如何将一个相当大(> 300K),相当成熟的C代码库转换为C++？

CI的类型被分为大致对应于模块的文件(即,比典型的基于OO类的分解更少的粒度),使用内部链接代替私有函数和数据,以及公共函数和数据的外部链接.全局变量广泛用于模块之间的通信.有一个非常广泛的集成测试套件,但没有单元(即模块)级别测试.

我想到了一个总体战略:

1. 在C++的C子集中编译所有内容并使其正常工作.
2. 将模块转换为大型类,以便所有交叉引用都由类名限定,但将所有函数和数据保留为静态成员,并使其工作.
3. 使用适当的构造函数和初始化的交叉引用将巨大的类转换为实例; 根据需要使用间接访问替换静态成员访问; 让它工作.
4. 现在,将项目作为一个错误的OO应用程序来处理,并编写单元测试,其中依赖项是易处理的,并分解为不属于它们的单独类; 这里的目标是在每次转型时从一个工作计划转移到另一个工作计划.

显然,这将是相当多的工作.关于这种翻译,是否有任何案例研究/战争故事？替代策略？其他有用的建议？

注1:程序是一个编译器,可能数以百万计的其他程序依赖于它的行为不会改变,所以批量重写几乎不是一个选择.

注2:来源近20年,每年可能有30%的代码流失(线路修改+增加/以前的总线路).换句话说,它被大量维护和扩展.因此,其中一个目标是增加可持续性.

[为了这个问题,假设转换为C++是强制性的,而将它留在C中则不是一种选择.添加这个条件的重点是清除"留在C中"的答案.]

我听说很多开发人员将代码称为"遗留".大多数情况下,代码是由不再在项目上工作的人编写的.是什么让代码,遗留代码？

更新回应:"从祖先或前任或过去传下来的东西" http://www.thefreedictionary.com/legacy.显然你想知道其他的东西.你能澄清或扩展你的问题吗？美国洛特

我正在寻找遗留代码的症状,使其无法使用或使用噩梦.什么时候扔掉它更好？我认为应该更频繁地抛弃代码,重新发明轮子是开发的宝贵部分.不重新发明轮子的学术理想是一个很好的理想,但它不是很实用.

另一方面,显然遗留的代码值得保留.

当您在遗留代码库中工作时,随着时间的推移会产生哪些影响,从而提高代码库的质量？

• 删除未使用的代码
• 删除重复的代码
• 添加单元测试以改善覆盖率低的测试覆盖率
• 跨文件创建一致的格式
• 更新第三方软件
• 减少静态分析工具(即.Findbugs)生成的警告

代码库是由许多开发人员编写的,他们多年来具有不同的专业知识水平,许多领域未经测试,有些领域不可测试,而且没有花费大量时间编写测试.

可能重复:
什么使代码遗留下来？

"遗留代码"的定义是什么？

我们目前使用Microsoft Access数据库引擎2010有一个主要问题.引擎有64位和32位形式,这很好.但是,如果主机进程始终是32位,显然您需要始终安装32位版本.好的,我们可以做到这一点.

我们的软件处理许多32位的遗留组件,其中大部分是VB6代码,它生成32位汇编.因此,我们假设驱动程序也必须安装为32位.实际上,当我们在64位计算机上安装32位驱动程序并运行我们的32位应用程序时,它可以正常工作.

但是,问题在系统上安装Office 2010 64位时开始.相信我,我们试图教育用户64位Office在很大程度上是不必要的,但无济于事.随着安装了64位版本的计算机下线,当我们的软件出现故障时,我们无法跟上支持请求.64位Office破坏了我们的安装,或者我们的安装破坏了他们的Office版本,但它不是两种方式.另一个问题是非传统软件有时会安装64位驱动程序(正如他们应该的那样),并且这两个版本根本不以任何合理的方式共存.要么我们的软件中断,要么他们的软件中断.

那么,有没有人设法找到一种方法使32位驱动程序与64位安装共存？我已经看到使用/passiveflag 安装允许安装两个,我们的安装程序确实使用被动.两者都在安装,但一旦在系统上,我们的软件不再工作,或Office不断修复其安装.有没有合理的方法来完成这项工作？