Questions tagged «refactoring»

重构是一种用于重组现有代码主体,在不更改其外部行为的情况下更改其内部结构的有纪律的技术。

15
我如何说服我的团队使用较小的类/方法?
免责声明:我是新来者(这是我工作的第三天),我的大多数队友比我更有经验。 查看代码时,我会看到一些代码气味和不良的工程实践,例如: 命名准则有些不一致 可能时属性未标记为只读 大型类-我注意到一个实用程序类,其中包含数百个扩展方法(对于许多类型)。它超过2500行! 大型方法-我正在尝试重构一种150行长的方法。 后两者似乎是一个真正的问题。我想说服队友使用较小的类和方法。但是我应该这样做吗?如果是,那怎么办? 我的团队从主要团队(我们是卫星团队)中获得了导师。我应该先去找他吗? 更新:由于一些答复询问该项目,因此请知道这是一个有效的项目。恕我直言,这么大的类/方法总是不好的。 无论如何,我永远不想惹恼我的团队。这就是为什么我问-我应该这样做,如果是的话,那么我该如何轻轻地做到这一点? 更新:我决定根据公认的答案做某事:因为我是新来者,所以我以“新鲜的眼睛”看到一切,我会记下我发现的所有代码气味(位置,为什么不好,我们怎么做)更好,...),但此刻,我只是努力争取团队的尊重:写出“更好的代码”,认识人们,知道我们为什么这样做...在适当的时候,我会尝试向我的团队询问一些新的代码策略(命名准则,较小的类,较小的方法等),并在可能的情况下重构一些旧代码。它应该工作,恕我直言。 谢谢。

5
如何将OO程序重构为功能性程序?
我很难找到有关如何以功能样式编写程序的资源。我可以在网上找到讨论的最高级的话题是使用结构化类型来减少类层次结构。大多数只处理如何使用map / fold / reduce / etc替换命令式循环。 我真正想找到的是深入讨论非平凡程序的OOP实现,其局限性以及如何以功能样式重构它。不仅是算法或数据结构,还有一些具有不同角色和方面的东西-也许是电子游戏。顺便说一句,我确实读过Tomas Petricek撰写的《现实世界的函数编程》,但是我还想要更多。

4
重构以更高的LOC结束是否有意义?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 去年关闭。 在某些情况下,比起更简洁的代码,更冗长的代码(如更逻辑的语句)更干净吗?

12
同事不愿使用单元测试“因为要编写更多代码”
一位同事不愿使用单元测试,而是选择快速测试,然后将其传递给用户,如果一切顺利,它会实时发布。毋庸置疑,某些错误确实可以解决。 我提到我们应该考虑使用单元测试-但是一旦意识到必须编写更多代码,她全都反对。这使我无法修改某些内容,并且不确定输出是否相同,尤其是因为她的代码是意大利细面条,因此我会在有机会时尝试对其进行重构。 那么对我来说最好的前进方向是什么?

5
当所有开发都在分支机构上时,如何重构?
在我公司,我们所有的开发(错误修复和新功能)都在单独的分支机构进行。完成后,我们将其发送给质量检查人员(QA),由该人员在该分支机构对其进行测试,当他们给我们开绿灯时,我们会将其合并到我们的主分支机构中。这可能需要一天到一年的时间。 如果我们尝试压缩分支上的任何重构,我们将不知道它会“退出”多长时间,因此在合并回它时会引起许多冲突。 例如,假设我要重命名一个函数,因为我正在使用的功能正在大量使用此功能,而我发现它的名称确实不符合其用途(再次,这只是一个示例)。因此,我四处寻找该函数的每种用法,并将它们全部重命名为新名称,并且一切正常,因此将其发送给质量检查人员。 同时,正在进行新的开发,并且我的重命名函数在main分支的任何分支上都不存在。当我的问题重新合并后,它们都会崩溃。 有什么办法解决吗? 并不是说管理部门会批准仅重构的问题,因此必须将其与其他工作联系在一起。它不能直接在main上进行开发,因为所有更改都必须经过质量检查,而且没人愿意成为打破main的混蛋,以便他可以执行一些不必要的重构。

7
Scrum中是否允许随机重构代码
背景 我的团队使用Scrum 我目前没有分配任务 积压中没有其他待处理任务 今天是我的客户的劳动节。 今天没有很多事情要做,我想开始重构一些代码,我一直在我正在处理的项目中看到这些代码,但是目前我没有分配给任何sprint任务来进行任何大规模重构。 如果我开始随机重构已经拥有的代码并且一直没有写出总是困扰我但又没有时间因为其他日子的分配而修复它的代码,在Scrum中可以吗? 那我在两次冲刺之间有空闲时间的其他日子呢? 实际上,我确实相信连续重构。我总是在分配故事时使用我正在工作的代码段,但是我看到的其他一些当前与当时正在处理的代码无关的代码又如何呢?

7
避免过于复杂的方法-循环复杂性
不确定如何使用这种方法来降低环复杂性。声纳报告为13,而预期为10。我敢肯定,保持这种方法不会造成任何危害,不过,这只是挑战我如何遵循Sonar的法则。任何想法将不胜感激。 public static long parseTimeValue(String sValue) { if (sValue == null) { return 0; } try { long millis; if (sValue.endsWith("S")) { millis = new ExtractSecond(sValue).invoke(); } else if (sValue.endsWith("ms")) { millis = new ExtractMillisecond(sValue).invoke(); } else if (sValue.endsWith("s")) { millis = new ExtractInSecond(sValue).invoke(); } else if (sValue.endsWith("m")) { millis …

4
如何进行进行中的重构?
因此,我有一个大项目,正在由我进行重构。我正在更改很多东西,因此没有机会让它尽快编译。我住在我命名的特殊git分支中cleanup(master当然,最终将合并到该分支中)。 问题是,我/我们有一个永远不要提交非编译代码的策略(理想情况下,它也应该起作用,但至少必须编译和链接)。因此,在完成这项艰巨的任务之前,我什么都做不了(审查或簿记)。 这不是我喜欢的工作方式(我相信大多数人每天至少要做一次)。 你怎么看?我有没有解决的办法? 以后可以告诉git汇总提交或其他内容吗?只要它们停留在cleanup分支中,我就可以忍受未编译的提交。 编辑 关于推送/提交的主题:我知道这是一个巨大的差异,但是稍后,当我将自己的内容合并到中时,修订版本将不完整master。因此,如果您浏览历史记录(或git bisect...),那么“本地”修订将可在世界范围内访问。因此,仅在本地提交而不进行推送不是最佳解决方案,因为这将在以后(当主题关闭并忘记一段时间后)给您带来麻烦。 简而言之:本地提交将最终被推送。全局历史记录不应显示未编译的提交。
23 git  refactoring 

11
重构或专注于完成应用
您会随身重构应用程序还是专注于首先完成应用程序?重构意味着应用程序的进度会变慢。 完成应用程序将意味着您以后可能很难维护应用程序吗? 该应用程序是一个个人项目。我真的不知道如何回答“什么驱动功能和设计”,但是我想这是为了解决现有软件的低效率问题。我也喜欢最小的易用软件。因此,我要删除一些功能,并添加一些我认为会有所帮助的功能。

1
我应该花多少时间重构代码?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我不知道这是否与我同在,但是当我开始重构一些代码时,我会浪费很多时间,而且它永远不会结束。 每次我再次阅读代码时,我都会发现有待改进的地方,代码重构就像是我的大脑陷入了无限循环,最终达到条件并没有满足感。 那么,我应该花多少时间重构代码?

1
重构在GitFlow分支命名模型中属于什么地方?
我最近开始使用由bitbucket实现的GitFlow模型。我有一件事还不完全清楚。 我们试图通过积压,计划和实施重构任务来定期解决我们的技术债务。这样的重构分支以合并到中的拉取请求结束develop。我的问题是重构分支在哪里属于GitFlow? 使用feature前缀似乎是最合乎逻辑的方法,但是感觉并不完全正确,因为重构不会添加任何新功能。 但是,使用bugfix前缀似乎并不正确,因为没有实际的错误重构修复程序。 另一方面,如果不过度设计,则创建自定义前缀看起来很复杂。 你有这种情况吗?您使用哪种做法解决此问题?请解释原因。

13
什么时候可以不修复损坏的窗户?
关于残破的窗口,是否有时最好将重构留给以后的活动? 例如,如果将一个向现有内部系统添加一些新功能的项目分配给了一个到目前为止尚未与该系统合作的团队,并且给出了一个可与之合作的时间表,那么是否有理由这样做?为了在这种情况下规定截止日期,将主要的重构推迟到现有代码吗?

7
当成为团队的新成员时,您如何处理现有集成和单元测试的质量?
我在职业生涯中遇到的一个反复出现的主题是成为新的开发人员加入团队,并很快对现有的单元和集成测试套件产生内在的不信任。 在面试过程中,管理层告诉您,他们“大力支持单元测试”,并公开鼓励他们进行测试。他们可以,但是关于测试本身的一切都是错误的。就像他们声称拥有100%集成测试覆盖率但少于10%可重复单元测试覆盖率时声称100%覆盖率这一事实。我发现了一些其他问题: 在什么是单元测试和什么是集成测试之间没有明确的指示。单元测试和集成测试在同一个类别中混合在一起。 尚未声明对特定环境的数据库中非常特定的动态数据有明确依赖关系的集成测试。 非事务集成测试,基本上是可能会或可能不会麻烦自行清理的测试,有时需要手动数据库“清理”以使测试可重复。 绝不进行任何模拟,而应用程序代码则需要进行大修,以使模拟成为可能。换句话说,设计时不要考虑测试。 没有明确的命名约定可以快速查看测试名称并大致确定要进行的测试。 这并不是说所有测试都是无用的或不好的,很多测试都相当好并且值得保留,但是有时候感觉就像淘金。我故意避免运行测试,只是因为我担心为黑箱测试用例搞砸数据库。 从本质上讲,这使我对单元和集成测试产生了固有的不信任感,而我个人没有以某种方式编写或审查这些测试。在某种程度上,如果您对测试套件的质量不抱有信心,那么它实际上对团队或项目毫无价值。 当您发现自己处于这种情况时该怎么办?您认为最佳的攻击计划是应对此类问题? 是否应该在跨发行版的巨大努力下重构所有测试?您是否应该放弃这个旧项目可能会有一天可靠的单元测试范围的想法?

15
重构:这仅仅是清理代码的幻想吗?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 在马丁·福勒(Martin Fowler)的书《重构:改进现有代码的设计》问世之前,我们习惯将对代码的主要更改称为“重新架构”,而将较小的更改称为“清理”。IMO,重构技术都是常识/我们一直在做的显而易见的事情。 您认为重构曾经是新事物吗?也许只是一种诱使管理人员分配时间进行代码清理的方法?

4
如何大幅提高代码覆盖率?
我的任务是让遗留应用程序处于单元测试之下。首先介绍一下应用程序的背景知识:这是一个600k LOC Java RCP代码库,存在以下主要问题 大量代码重复 没有封装,大多数私有数据都可以从外部访问,一些业务数据也成为单例,因此不仅可以从外部更改,而且可以从任何地方更改。 没有抽象(例如,没有业务模型,业务数据存储在Object []和double [] []中),因此没有OO。 有一个很好的回归测试套件,一个高效的质量检查团队正在测试和发现错误。我知道如何从经典书籍(例如Michael Feathers)中对其进行测试的技术,但这太慢了。由于存在工作正常的回归测试系统,因此我不怕积极地重构系统以允许编写单元测试。 我应该如何着手解决问题以快速获得覆盖范围,以便能够向管理人员展示进度(实际上是从JUnit测试的安全网中开始赚钱)?我不想使用工具来生成回归测试套件,例如AgitarOne,因为这些测试不会测试是否正确。

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.