Questions tagged «legacy-code»

最初的遗留代码是指从作者或以前的程序/系统版本“继承”的代码。自从迈克尔·费瑟斯(Michael Feathers)出版了他的《有效处理遗留代码》一书以来,新的定义就出现了,没有测试的代码就是旧代码。

20
在即将走向失败的项目中,我应该如何表现为开发人员?
我是一个由5人组成的团队的开发人员,我相信我们的项目将要走向灾难。我稍后将描述原因,但我的问题是:我应该如何表现? 截止日期为1.5个月,我觉得无论我们做什么,这个项目都会失败。我认为我们应该只是终止项目并停止浪费我们的时间,但是从政治上我认为我们的经理不可能做到这一点。 在这种情况下我该怎么办?我应该付出额外的努力,还是应该轻松些?我该对经理说些什么? 该项目失败的原因: 随着截止日期的临近,许多必备功能尚未完成 应用程序不稳定且很难使用 系统非常复杂,代码很难理解,很难更改-数据模型太受复杂的关系数据库(100多个表)驱动 领导不清;经理对新信息做出重大更改 几乎没有自动化测试或单元测试 严重依赖于其他系统,但尚未进行集成测试 实际上,我们实际上是在1-2个月前从同一个经理下的另一个开发团队继承了这个项目(以及混乱),该团队已经工作了几个月。

9
估算旧版代码库中的时间成本
最近,我开始从事一个项目,该项目将一个非常古老的单片应用程序迁移到基于微服务的体系结构中。 遗留的代码库非常混乱(“意大利面条代码”),并且通常一个看似简单的函数(例如,命名为“ multiplyValueByTen”)随后将自身显示为“涉及3个不同模式的10个表的数千行验证代码”。 现在,我的老板(正确地)要求我估计在新架构中编写功能X所需的时间。但是我很难提出一个现实的估计。由于上述原因,我常常大大低估了任务,并因为无法及时完成而感到尴尬。 明智的做法似乎确实进入了代码,注意到每个分支并调用了其他函数,然后估算了时间成本。但是在记录旧代码与实际写下新版本之间确实有微小的区别。 我应该如何处理这样的情况? 尽管我完全理解了遗留代码重构的工作原理,但我的问题不是关于“如何进行重构/重写?”。但是要给出一个现实的答案:“重构/重写X部分需要多长时间?”

10
没有时间进行完整重构时,为遗留代码编写测试是否有意义?
我通常会尝试遵循《与Legacy Cod e 一起有效工作》一书的建议。我打破了依赖关系,将部分代码移到@VisibleForTesting public static方法和新类上,以使代码(或至少部分代码)可测试。并且我编写测试以确保在修改或添加新功能时我不会破坏任何东西。 一位同事说我不应该这样做。他的推理: 最初,原始代码可能无法正常工作。并且为它编写测试使将来的修复和修改变得更加困难,因为开发人员也必须理解和修改测试。 如果它是具有某些逻辑的GUI代码(例如〜12行,例如2-3 if / else块),则由于代码太琐碎而无法开始,因此测试不值得这样做。 类似的不良模式也可能存在于代码库的其他部分中(我还没有看到,我还很新)。一次大的重构就更容易清理它们了。提取逻辑可能会破坏这种未来的可能性。 如果我们没有时间进行完整的重构,是否应该避免提取可测试的部分并编写测试?我应该考虑这样做的不利之处吗?

8
如何反对降低传统代码库的质量标准?[关闭]
我们这里有一个庞大的遗留代码库,其中包含您无法想象的错误代码。 现在,我们定义了一些质量标准,并希望在全新的代码库中实现这些标准,而且还可以通过触摸旧代码来实现。 而且,我们使用Sonar(代码分析工具)来执行这些操作,而Sonar已经有数千次违规。 现在开始讨论降低对遗留物的侵犯。因为它是遗产。 讨论是关于可读性规则。像它可以有多少个嵌套的ifs / for..。 现在,我该如何反对降低传统代码的编码质量?

4
否定性“传统代码”的由来是什么
每个人都在谈论软件开发中的遗留代码,我听说过过去十年中用来将任何代码库描述为不良代码的术语。 对程序员一样具有如此强大内涵的这个术语从何而来? 我相信肯定有一些关于软件开发的书是这个学期的开创者。我很想找到术语“旧版代码”的由来。

2
历史增长的软件是否有命名的反模式?[关闭]
是否有一种反模式来描述一个历史悠久的软件系统,其中多个开发人员只是向系统添加了新功能,但没有人真正关注整个体系结构,也从未进行过重构? 我认为,当管理人员/客户不断要求新功能并且没有人重构任何东西而只是增加其他开发人员以前所做的事情时,就会发生这种情况。 原因还可能是开发人员对软件系统不知所措,并不真正了解它当前的工作方式,然后只是在最后添加/粘上了他的代码(而不是重构和更改代码)。 因此,随着时间的推移,维护系统变得越来越困难。 (我想知道是否有针对这种反模式的图片,以使所有编程人员都无法清楚了解它-就像一辆通过添加越来越多的功能而无需考虑整体设计而制造的汽车。就像有人需要拖曳拖车时向后骑,然后工程师只是将牵引杆焊接到汽车的前部。工作已经完成。但是现在,前围不再打开了。)

8
如何处理大量失败的测试?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我正在开发一个用Java编写的旧项目。我们有超过1000万个LOC,更糟糕的是,有4000多个功能测试。 由哈德森(Hudson)安排的测试由于每次较大的代码更改而疯狂,但都失败了。验证测试失败-如果是产品或测试中的问题,则需要几个月的时间。我们无法删除旧测试,因为我们不知道它们在测试什么! 我们能做什么?如何进行如此大量的传统测试?

6
处理遗留代码是否能帮助一个程序员发展?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我是一名Java开发人员,拥有超过一年的经验,这使我比初级人员高一些,但是还不是中级开发人员。最近,为我提供了一个长期项目,该项目涉及研究现有银行应用程序代码4个月,然后在需要时进行更改。作为一个经验不足的程序员,我正在寻找开发方法,我不知道这样的项目会给什么。 对于初学者来说,您是否认为处理大型且可能不太好的书面申请是一种好习惯?

5
如何避免过多的方法重载?
我们的应用程序源代码中有很多地方,其中一个类有许多具有相同名称和不同参数的方法。这些方法始终具有“上一个”方法的所有参数,再加上一个。 这是经过长期发展(遗留代码)和这种想法(我相信)的结果: “ 有一个方法M做A,我需要做A +B。好吧,我知道...我将向M添加一个新参数,为此创建一个新方法,将代码从M移到新方法使用一个以上的参数,在那儿执行A + B,然后使用新参数的默认值从M调用新方法。 ” 这是一个示例(类似于Java的语言): class DocumentHome { (...) public Document createDocument(String name) { // just calls another method with default value of its parameter return createDocument(name, -1); } public Document createDocument(String name, int minPagesCount) { // just calls another method with default value of its …

5
为什么要为将要重构的代码编写测试?
我正在重构一个巨大的遗留代码类。重构(我认为)主张: 为遗留类编写测试 摆脱困境 问题:一旦我重构了类,就需要更改步骤1中的测试。例如,以前是旧方法中的东西,现在可能是一个单独的类。一种方法现在可能是几种方法。遗留类的整个景观可能被抹杀为新的东西,因此我在步骤1中编写的测试几乎是无效的。本质上,我将添加步骤3。大量重写我的测试 那么重构之前编写测试的目的是什么?这听起来更像是为自己创造更多工作的学术活动。我现在正在为该方法编写测试,并且正在学习有关如何测试事物以及旧方法如何工作的更多信息。可以通过阅读旧代码本身来学习这一点,但是编写测试几乎就像在摸摸我的鼻子,并且在单独的测试中记录这种临时知识。因此,以这种方式,我几乎别无选择,只能学习代码在做什么。我在这里说的是暂时的,因为我会从代码中重构出乱七八糟的东西,并且我的所有文档和测试在很大程度上都是无效的,除非我的知识会留下来并使我对重构更加新鲜。 这是重构之前编写测试的真正原因-帮助我更好地理解代码吗?还有另一个原因! 请解释! 注意: 有一篇文章:没有时间进行完全重构时,为遗留代码编写测试是否有意义?但是它说“重构之前先写测试”,但没有说“为什么”,或者说“写测试”看起来像“很快就会被销毁的繁忙工作”该怎么办。

5
当他们的团队多年来缺乏产品创新,不使用项目mgmt方法并保持不良的软件开发实践时,如何做为开发人员?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 5年前关闭。 我有兴趣知道如何处理当前的软件开发流程,该流程多年未变,最终会导致产品和团队失败。是的,解决这个问题的更简单方法可能是换工作,但是有了这种经济,说起来容易做起来难。但是,如果您有特定的示例,并且在相同的情况下曾经或多次出现,并且认为解决这些问题的最佳解决方案是离开公司,那么请支持您的回答。关键是,这个问题确实有答案,特别是如果该主题的多个专家最终指出最好的路线是:路线A。 我知道成千上万的开发人员曾经或正在经历类似的情况。这是公司从在市场上排名第一变为最后甚至退出市场的主要原因之一。希望本文中的答案能够帮助其他面临类似障碍的开发人员。在小型或大型开发团队中,通常会发生以下情况: 一些开发人员似乎并不在乎并决定顺其自然,而宁愿让代码充满很多代码味道,保持开发流程不变, 其他人厌倦了不变,辞职并搬到另一家公司, 其他人似乎害怕说话,宁愿保持沉默, 有时,很少有开发人员或只有一个开发人员试图说出要改进产品的情况,并告诉团队遵循最佳编码实践的重要性和对客户,用户和团队的益处。这些类型的开发人员通常由于诸如公司提供的收益,软件公司提供的收益很少,产品具有很大的潜力等原因而决定留在团队中。 我们团队中的产品仅是公司从中获得收入的一小部分,因为它拥有大量产品(该公司不是软件/硬件公司;因此,至少在目前,没有持续的专利诉讼可创造工作机会)不稳定)。这些年来,我从其他开发人员的经验中学到的东西是,要真正认识一个开发团队,需要花费时间,而不是几天或几周,而是几个月。在面试过程中,团队是否要雇用您或需要您;它们使一切听起来很棒,并且它们可能会告诉您您想听的内容。但是,当您开始在该团队中工作并开始深入研究代码并迈向完整的SDLC流程时,现实就不同了。这是作为开发人员时,您开始看到自己从事的工作的现实。这种现实使得很难从一家公司转移到另一家公司,因为很难知道您所迁移的公司是好是坏。是的,您可以阅读Glassdoor的评论等。但是,这些在线评论中有多少是真实的,而不是来自HR? 考虑到经理从一开始就一直拒绝更改,而以前的开发人员已经这样做了多年,那么解决以下概述的问题的最佳方法是什么? 多年来缺乏产品创新:产品具有巨大的潜力,并为公司带来了可观的收入,但产品看起来像20年前制造的。一些用户抱怨该产品不友好,不直观,而另一些用户则提到该产品已用于Gmail等应用程序,并且由于不具有类似功能而在使用该产品时感到沮丧。这里的主要问题是,当您作为开发人员尝试对产品进行更改并开始将产品的主要元素移开几个像素(以使其更加用户友好或直观)时,经理会慌张并告诉您把它放回原处。如果您尝试添加对用户有利的功能,经理会要求您删除它,因为“用户习惯于按原样进行处理等。” 我认为您理解了变革,改进和创新的阻力(即使您作为开发人员提供了强有力的利益主张,经理也不愿意改变)。公司在该领域有一些竞争对手(其中的几个产品更具竞争力),但是公司以某种方式保持了现有客户多年。 缺乏项目管理协调:因此,一些项目交付较晚,存在错误,有些客户抱怨(客户也报告错误),或者在交付项目之前预算太快等。我已经提供了它们一些项目协调技巧,并且现在定期使用这些想法来跟踪项目和要完成的任务的进度。 不良的软件开发实践:在大多数(如果不是全部)文件上看到代码异味,没有文档,代码冗余,在同一文件上混合了前端层和后端,过时的开发工具,没有真实的测试环境或测试工具(只需复制和粘贴)文件从开发环境到生产环境,然后手动进行测试,看情况是否良好并发布)。我用于开发和测试的大多数开发工具都是团队不知道的,因为团队仅使用2个IDE进行代码开发,而源代码控制仅适用于开发环境。其他开发人员试图使用最新的框架来改善当前问题,但是经理不喜欢它,因为“如果离开,那么谁来维护该代码?让我们保持现状”,其中一些开发人员已经离开并搬到另一家公司。 综上所述,我确定其他公司的许多开发人员也会遇到类似的情况,但是由于情况不同,开发人员可能更愿意留在团队中而不是去其他公司,原因是(工作便利,工作灵活性,公司收益或只是因为还没有一个更好的机会)。我没有一家完美的公司,但是作为开发人员,您将如何处理和解决所有这些问题,以保持积极的态度,并最终促进变革,以改进产品并改善软件开发流程(无论您是否有很多)多年的开发经验还是仅几个)?我知道这是一篇很长的文章,但是我希望提供更多细节,以增加获得更多有用反馈的机会。 非常感谢您的反馈和时间

11
如果坚持使用经典ASP怎么办?[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,以使它成为软件工程堆栈交换的主题。 4年前关闭。 我曾经在一家非常小的外包公司工作(有4个程序员和老板),然后当压力和频繁的长期轮班使情况变得难以忍受时,我转而以更宽松的日程转向薪水更高的工作,这使我有更多工作要做。空闲时间。 但是,问题在于,大多数情况下,所有内容都在Classic ASP中进行编码,该代码与自定义的C ++排队系统对接,该系统将所有内容存储在AS400系统中。我的老板曾经是为此做出最初努力的开发人员之一,尽管越来越难以用昨天的工具来满足当今的业务需求,但我自然不会批准改用其他语言/技术。 在可预见的将来,我几乎无法使用Classic ASP进行编码,而我一直在努力寻找使它变得至少有趣的方法,因为我以前曾经使用过.NET和Java,而且我觉得我要去向后...有什么建议吗?

6
功能需求不足是否敏捷?
如今,每个人都希望变得敏捷。在与我合作的每个团队中,敏捷的形式都不同。有些事情很常见-例如日常站立或计划,但其他部分则有很大差异。 在我目前的团队中,有一个细节令我感到困扰。缺乏功能要求。不仅没有书面形式的期望,而且在任务中模糊地定义了需要完成的工作。 该项目的目标是使用新技术重写旧系统。旧系统也没有任何合理的文档。当然,最新的不存在。企业主对需求的描述是-让我们在新实现中以与旧实现相同的方式进行。似乎合理,但事实并非如此。旧系统是一种意大利面条式代码,从中提取业务需求非常昂贵。看来情况对计划产生了负面影响。当然,在新的实现中容易出错和出错(省略一些细节)。 因此,我在想-在重写旧系统的情况下,没有业务需求真的很敏捷吗?
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.