Questions tagged «refactoring»

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

5
如何处理代码重用的哲学?
在开始新项目时,我经常发现自己在考虑代码重用。 我应该在多大程度上使代码可重用? 我应该将其限制在应用范围内还是应该使其在项目外部可重用? 有时候,我觉得代码的可重用性可能会妨碍简单的设计。请分享您对代码可重用性的理解和方法。

1
如何重构一个Python“神类”?
问题 我正在一个Python项目中,该项目的主类有点“ God Object ”。有这么受诅咒的多属性和方法! 我想重构班级。 至今… 第一步,我想做一些相对简单的事情。但是当我尝试最直接的方法时,它破坏了一些测试和现有示例。 基本上,该类具有大量的属性列表,但是我可以清楚地查看它们,并认为:“这5个属性是相关的……这8个属性也都是相关的……剩下的就是这些。” getattr 我基本上只是想将相关属性分组为类似dict的帮助器类。我有种__getattr__理想的工作选择。因此,我将属性移到了一个单独的类,并且确实可以__getattr__很好地发挥其魔力…… 一开始。 但是后来我尝试运行其中一个示例。示例子类尝试直接设置这些属性之一(在类级别)。但是由于该属性不再在父类中“物理定位”,所以我收到一个错误消息,指出该属性不存在。 @属性 然后,我阅读了有关@property装饰器的信息。但是后来我也读到,self.x = blah当x父类的属性是子类时,它会给想要做的子类带来问题。 期望的 self.whatever即使父类的whatever属性不在类(或实例)本身的“实体位置” ,也要让所有客户端代码继续使用。 将相关属性分组到类似dict的容器中。 减少主类中代码的极端噪音。 例如,我不只是想更改此内容: larry = 2 curly = 'abcd' moe = self.doh() 变成这个: larry = something_else('larry') curly = something_else('curly') moe = yet_another_thing.moe() …因为那仍然很吵。尽管这成功地将简单的属性赋予可以管理数据的属性,但是原始属性具有3个变量,而经过调整的版本仍具有3个变量。 但是,我可以这样: stooges = Stooges() 如果查找self.larry失败,将检查stooges并查看是否larry存在。(但是,如果子类尝试larry = 'blah'在类级别执行此操作,那么它也必须起作用。) …

7
敏捷和瀑布式流程的时间表中,代码重构和优化应该放在哪里?
在项目管理团队中似乎有一种说法,指出“有效”意味着应该认为它已100%完成。大多数程序员都知道情况并非总是如此。如果我正在尝试其他方法来使某项功能正常工作,那并不一定意味着我找到了最好的解决方案,或者在与其他开发人员一起审阅后不需要进行任何重新设计。我经常会做一些事情,退后一步,然后问自己在满足业务规则后我能做些什么。这个“我可以做得更好”的时间是否应该真正放在时间轴内的某个地方?我认为最好的方法是,一定程度上,代码总是比发现时更好(这可能意味着启动后重构)。然而,

4
我需要将log4j升级到slf4j吗?
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,以使它成为软件工程堆栈交换的主题。 5年前关闭。 我们正在审查我们的JEE Web应用程序以进行一些计划的重构,其中一项建议是log4j用logback或替换slf4j 团队尚不清楚我们是否应该执行此操作-因为目前我们希望遵循该规则,否则不会在此区域进行修复。 编辑:我不是要比较日志记录框架,而是当我们对log4j非常满意时,更改框架是否是有价值的重构元素

3
与团队重命名,重构和打破变更的最佳实践
在团队环境中进行重构和重命名的最佳实践是什么?我提出了一些方案: 如果重构了通常引用的库,以对引用该库的任何库或项目进行重大更改。例如,任意更改方法的名称。 如果项目已重命名,则必须使用对它们的更新引用来重建解决方案。 如果通过引入文件夹并将现有项目或解决方案移至新位置来将项目结构更改为“更有条理”。 一些其他想法/问题: 是否应该像这样发生变化,还是所导致的疼痛表明结构出现了问题? 谁应该负责修复与重大更改相关的错误?如果开发人员进行了重大更改,那么他们应该负责进入受影响的项目并对其进行更新,还是应该提醒其他开发人员并提示他们进行更改? 这是可以按计划执行的事情还是应该尽可能频繁地执行?如果重构推迟的时间太长,则调解就变得越来越困难,但是由于一天中其他地方发生的变化,每天同时花费1小时来修复一个构建。 这是一个正式的沟通过程,还是有机的?

7
我可以采取什么方法来降低在复杂的旧版应用程序中引入新错误的几率?
在我工作的地方,我经常不得不在旧系统(.NET 1)中开发(和修复错误)谁的代码是完整的意大利面条-对变量名,程序结构或注释不加考虑。 因此,我花了很长时间才了解需要更改哪些位,并且由于进行了修改,我经常“破坏”现有软件。我真的真的想花几个月的时间(与同事),通过它去重构,但现有的开发人员都看不到需要-也不觉得孤单时间讨论这个(系统是巨大的)。 我担心必须处理它的代码,因为花几天的时间来修复某些问题,才发现我已经破坏了其他内容。这显然使我看起来不称职-那么我该如何处理呢?

3
我如何才能有意识地实践设计模式和重构?[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗? 更新问题,使它成为软件工程堆栈交换的主题。 4年前关闭。 我正在阅读《重构为模式》一书,想知道如何获得机会练习这些技能,因为如果不认真尝试重构和使用模式的新方法,我的技能将无法提高。 但是办公室工作需要我尽快完成每项任务。大多数时候,项目的设计和体系结构不受我控制,我只能遵循与现有代码类似的样式。有时有一个设计不良的项目,但是还有另一个开发人员的设计技能比我强,他已经拥有重构该项目的整个计划,所以我只是遵循他的计划。我如何获得练习的机会?

4
重构-只要所有测试都通过,简单地重写代码是否合适?
我最近看了RailsConf 2014的“ All Little Little”。在这次演讲中,Sandi Metz重构了一个包含大型嵌套if语句的函数: def tick if @name != 'Aged Brie' && @name != 'Backstage passes to a TAFKAL80ETC concert' if @quality > 0 if @name != 'Sulfuras, Hand of Ragnaros' @quality -= 1 end end else ... end ... end 第一步是将函数分解为几个较小的函数: def tick case name when 'Aged …

5
长方法重构:保持原样vs分离方法vs使用局部函数
假设我有这样长的方法: public void SomeLongMethod() { // Some task #1 ... // Some task #2 ... } 此方法没有任何重复的部分,应将其移至单独的方法或局部函数。 有很多人(包括我在内)认为长方法就是代码的味道。我也不喜欢#region在这里使用(s)的想法,并且有一个非常受欢迎的答案来解释为什么这很糟糕。 但是如果我将此代码分成方法 public void SomeLongMethod() { Task1(); Task2(); } private void Task1() { // Some task #1 ... } private void Task2() { // Some task #1 ... } 我看到以下问题: 用一个方法内部使用的定义来污染类定义范围,这意味着我应该在某个地方进行文档记录,Task1并且Task2只供内部使用SomeLongMethod(否则,每个阅读我的代码的人都必须推断出这个想法)。 污染将仅在单个SomeLongMethod方法中使用一次的方法的IDE自动完成功能(例如Intellisense)。 因此,如果我将此方法代码分成本地函数 …

1
寻找将深度架构重构与基于功能的开发相结合的更好方法
问题陈述: 鉴于: TFS作为源代码控制 繁重的桌面客户端应用程序,带有大量不良代码或几乎没有架构设计的旧代码。 客户不断要求具有音质,快速 交付的新功能,并不断抱怨用户界面不友好。 问题: 应用程序无疑需要深度重构。此过程不可避免地使应用程序不稳定,需要专用的稳定阶段。 我们尝试过: 通过从主节点(MB)到功能分支(FB)的定期合并在主节点中进行重构。(我的错误) 结果:许多不稳定的分支。 我们的建议: 链接到文章(pdf) 通过从MB到RB的合并,创建附加的重构分支(RB)使其与MB定期同步。RB稳定后,我们用RB代替master并创建新分支以进行进一步的重构。这是计划。但是在这里,我期望在将任何FB合并到MB之后将MB合并到RB的真正地狱。 主要优点: 大部分时间稳定掌握。 有没有更好的替代方法?

4
快速原型制作和重构
有时候,当我开始一个小项目(例如android应用)时,我不知道哪种方法最终会成功,而我只是尝试一种方法并尝试一下。但是,如果我以前从未使用过这种方法(对于我以前从未编程过的某种应用程序),那就像步入未知领域。我不知道要使用哪个库(也许我必须尝试几个库),而且有太多未知数(例如:如何在android中获取原始音频数据) 因此,我的开发过程如下: 编写一段代码,看看这种方法是否有机会。(方法越不确定,代码就会变得越丑) 如果可行,请进行大量重构,直到美观为止 如果我现在详细计划软件设计,那可能会浪费时间,就像计划没有地图的旅程一样。 这是敏捷开发的一部分吗?您如何处理软件开发中的未知领域?

3
用类替换类型代码(从重构[Fowler])
此策略涉及替换以下内容: public class Politician { public const int Infidelity = 0; public const int Embezzlement = 1; public const int FlipFlopping = 2; public const int Murder = 3; public const int BabyKissing = 4; public int MostNotableGrievance { get; set; } } 带有: public class Politician { public MostNotableGrievance …
9 c#  refactoring 

6
从2000年代开始的软件解决方案,我应该尝试修补还是重新制作整个产品吗?
我被派去讨论某个公司当前正在使用的系统以及应该如何处理。 该公司生产各种纸箱展示架。开发该系统是为了跟踪客户,订单和价格。自从创建系统以来,发生了很多事情,并且正如经理所描述的那样,系统现在已“ 锁定 ”和“ 有问题 ”,我将其翻译为“非动态”和“不稳定”。 有关系统的一些信息 它是在2000年左右开发的 相当小的系统,2-5个用户,6个表格,〜8个表,平均数据量 建立在早期的Visual Basic上,是通过拖放设计创建的表单。界面基本上只是一个带有菜单和某些形式的窗口 使用MSSQL数据库(SQL2005服务器)存储数据并使用ODBC驱动程序进行查询,在此系统之前,数据是从excel迁移而来,在excel之前,它是用手工和纸来处理,计算和编写的 用户在Microsoft XP环境(及更高版本)中工作 他们的主要问题是他们无法正确地调整和计算价格,无法添加新的纸箱类型等,因为它们无法(或者更确切地说,他们不知道如何)触摸服务器上的数据。 我建议了3种可能的解决方案 尝试修补当前系统 创建一个全新的界面(最好是类似的环境,基于VB.net或VB) 考虑到它是一个很小的系统,请将其重新带到Excel解决方案中 可能还有更多选择,但是这些是我能想到的。 我的问题是 我应该推荐什么,为什么? 这些替代方案的利弊是什么? 还有其他(可能更好)的选择吗?

7
如果我的LOC /天比率过高,是否应该打扰我?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 我目前正在从事一个独立项目,因此我没有进行整个人工测试或外部代码审查的全部精力–但是,我在当前代码中看不到任何困难的错误(我已将其修复,因为我看到了这些错误) ,而且在大多数情况下,它们只是错误的字段名称等,您需要在一两分钟之内解决的问题),并且在实现任何功能之前,我会先进行测试,然后再进行推送。最近,我的LOC号码每天大约为400(根据记录,它是C#),我不仅在实现新系统,还重写了我已经写的东西并修复了一些错误。 我应该打扰吗?这是否是我需要停止并查看我到目前为止一直在写的所有代码并对其进行重构的标志?
9 c#  refactoring 

8
重构或升级数据库以处理新功能
针对数据库模式问题的一些回答,建议使用一个附加表来规范不属于当前要求的功能的数据库(UserDepartment表允许员工/用户与他们可能在不同部门之间建立多对多关系属于。)。 不反对规范化。似乎在进行数据库设计时,大力推动包含他们“确定”某人将来会想要的功能。将表/字段添加到数据库以适应功能是否是如此困难,以至于过度工程化的趋势?如果需要,它们是否会像应用程序的其余部分那样进行重构或升级?重做从来都不是一件有趣的事,但是可以将数据从一个表转移到一个新表。只是不确定这种思路会在哪里结束。 编辑:对此有很大的反感,我想知道有多少项目最终没有添加需要进行重大数据库更改的功能,或者是否采取了非规范化的方法(例如添加DepartmentID2字段而不是新表)。员工需要多个部门是一个常见的领域问题。我只是没有注意到许多杂乱无章的数据库模式。

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.