问题标签 [refactoring]

我有这个 Perl 脚本，其中包含许多已定义的配置文件常量。例如：

我想减少 "/etc/app1" 和 "/var/log" 的重复，但使用变量不起作用。同样使用先前定义的常量在同一个“使用常量块”中也不起作用。例如：

不起作用。

使用单独的“使用常量”块可以解决这个问题，但这会增加很多不需要的代码。

这样做的正确方法是什么？

谢谢你。

我刚刚开始我的第一次大规模重构，并且需要将一个（不幸的是大）类分成两个，然后它们只能通过接口进行通信。（我的 Presenter 原来是一个 Controller，需要将 GUI 逻辑从 App 逻辑中分离出来）。在 VisualStudio 2008 和 Resharper 中使用 C#，实现这一目标的最简单方法是什么？

我要尝试的是a）收集新类的成员并“提取新类”b）清理产生的混乱c）“提取接口”d）追踪对类的任何引用并将它们转换为接口引用

但我以前从来没有这样做过，在我开始把所有东西都拆开之前，想知道是否有人知道任何好的技巧或陷阱......谢谢！

问题

我的问题是如何教授整理和重构代码的方法和重要性？

背景

我最近正在为一位同事进行代码审查。他们对久违的同事作品进行了一些修改。在新更改期间，我的同事曾尝试重构项目，但一旦遇到崩溃或其他问题就放弃了（而不是追着兔子往洞里找问题的根源），因此重新实现了问题代码和在此基础上构建更多。这让代码陷入了一堆变通办法和幻数之中，所以我和他们坐下来进行重构。

我试图解释我是如何确定我们可以重构的地方，以及每次重构通常如何突出新领域。例如，有两个变量存储了相同的信息——为什么？我猜想这是解决更大问题的一种解决方法，所以我取出一个变量并把兔子追到洞里，在我们进行的过程中发现了其他问题。这最终导致我们发现了一个问题，即我们多次循环相同的东西。这在很大程度上是由于使用了幻数大小的数组混淆了正在做的事情——修复最初的“双变量”问题导致了这一发现（和其他发现）。

当我和同事一起进行重构之旅时，很明显她并不总是能够理解我们为什么要进行某些更改以及我们如何确保新功能与原始功能相匹配，所以我花时间解释和证明通过与早期版本进行比较并在纸上逐步完成每个更改。我还通过示例解释了如何判断重构选择是否是一个坏主意，何时选择注释而不是代码更改，以及如何选择好的变量名。

我觉得坐在一起做这件事的过程对我自己（我必须了解更多关于如何最好地向他人解释事物）和我的同事（他们必须了解更多我们的代码和我们的编码实践）都是值得的但是，这段经历让我想知道是否有更好的方法来教授重构过程。

……最后……

我知道什么需要或不需要重构，以及如何重构它是非常主观的，所以我想避开那个讨论，但我有兴趣了解其他人将如何应对教授这项重要技能的挑战，如果其他人这里有类似的经历以及他们从他们身上学到的东西（无论是作为老师还是学生）。

我已经开始使用 Jython，因为它似乎是一种优秀的语言，并且到目前为止已经证明是这样。

我正在使用 dom4j 从磁盘上的一堆 HTML 文件的 DOM 中操作和检索数据。我编写了下面的脚本来检查使用 Xpath 的H1标签和抓取文本的 DOM，如果H1标签不存在于 DOM 中，它会搜索标题标签并从中获取文本。

我对 Jython 很陌生，但我确信有一种方法可以比下面的方法更优雅地执行所需的任务，如果我的想法是正确的，有没有人可以告诉我一个更好的方法来做到这一点？

如果有人可以提供帮助，那就太好了。干杯

我需要在一些旧脚本中添加单元测试，这些脚本基本上都是以下形式：

如果我尝试在单元测试中“要求”此代码，则代码的主要部分将运行，因为我希望能够单独测试“foo”。

有没有办法做到这一点而不将 foo,bar 移动到单独的 .pm 文件中？

我一直在研究一个 Eclipse 插件项目，我遇到了一种情况，我需要拆分项目以将测试用例与插件包分开。我使用 git 作为版本控制。

为了简单地描述这一点，我正在像这样对旧项目进行版本控制：

…而且我处于需要在单独的项目中进行插件测试的情况（这样就不需要将 jUnit 作为插件的必需捆绑包）。而且我希望存储库对工作区中的所有内容进行版本控制。像这样：

有没有一种简单的方法可以在不丢失旧项目历史的情况下做到这一点？

我有一个 Breadcrumb 类型的 IList，它只是一个具有 NavigationTitle、NavigationUrl 和 IsCurrent 属性的轻量级类。它缓存在网络服务器上。我有一个方法可以构建当前的面包屑跟踪，直到第一个将 IsCurrent 设置为 true 的面包屑......使用下面的代码。它非常丑陋，绝对是一个快速的垃圾袋威利解决方案，但我很好奇，这可以很容易地重构为 LINQ 吗？

背景

我正在研究一个遗留的小型企业自动化系统（库存、销售、采购等），它有一个由 SQL Server 2005 托管的数据库和一堆客户端应用程序。主客户端（所有用户使用）是一个 MS Access 2003 应用程序 (ADP)，其他客户端包括各种 VB/VBA 应用程序，如 Excel 插件和命令行实用程序。

除了大约 60 个表（大部分在 3NF 中）之外，该数据库还包含大约 200 个视图、大约 170 个 UDF（主要是标量和表值内联的 UDF）和大约 50 个存储过程。正如您可能已经猜到的那样，所谓的“业务逻辑”的一部分被封装在大量 T-SQL 代码中（因此被所有客户端共享）。

总的来说，系统的代码（包括 T-SQL 代码）组织得不是很好，可以说是非常抗重构。特别是，大多数表的模式都需要各种重构，小（如列重命名）和大（如规范化）。

FWIW，我有相当长且体面的应用程序开发经验（C/C++、Java、VB 等等），但我不是 DBA。所以，如果这个问题对你来说看起来很傻，现在你知道为什么会这样了。:-)

问题

在考虑重构所有这些混乱（当然是以和平方式）时，我提出了以下想法：

1. 对于每个表，创建一个“包装器”视图，其中 (a) 包含该表的所有列；(b) 在某些情况下，有一些基于表的“真实”列的额外计算列。

   这种附加计算列的一个典型（尽管很简单）示例是从产品的正常价格和折扣得出的产品销售价格。

2. 重新组织所有代码（T-SQL 和 VB/VBA 客户端代码），以便只有“包装器”视图直接引用表。

   因此，例如，即使应用程序或存储过程需要从表中插入/更新/删除记录，他们也会针对相应的“表包装器”视图执行此操作，而不是直接针对表。

所以，本质上这是关于通过视图将所有表与系统的其余部分隔离开来。

这种方法似乎提供了很多好处，尤其是从可维护性的角度来看。例如：

• 当要重命名表列时，无需一次重写所有受影响的客户端代码即可完成。

• 实现派生属性更容易（比使用计算列更容易）。

• 您可以有效地为列名设置别名。

显然，所有这些好处都必须付出一定的代价，但我不确定我是否看到了所有的陷阱。

有人在实践中尝试过这种方法吗？主要的陷阱是什么？

一个明显的缺点是维护“包装”视图与其对应表同步的成本（表中的新列也必须添加到视图中；从表中删除的列也必须从视图中删除；等等.)。但是这个价格对于使整个代码库更具弹性来说似乎很小而且很公平。

有谁知道其他更强大的缺点？

例如，使用所有这些“包装器”视图而不是表很可能会产生一些不利的性能影响，但这种影响是否足以让人担心呢？此外，在使用 ADODB 时，很容易得到一个不可更新的记录集，即使它仅基于几个连接的表；那么，“包装”视图是否会使事情变得更糟？等等等等...

任何评论（尤其是分享的真实经验）将不胜感激。

谢谢！

PS我踩到了以下讨论“包装器”视图概念的旧文章：

大视野神话

文章建议避免上述方法。但是......我真的没有在文章中看到任何反对这个想法的充分理由。恰恰相反，在创建视图的充分理由列表中，几乎每个项目都正是为什么为每个表创建“包装器”视图如此诱人的原因（尤其是在遗留系统中，作为重构过程的一部分） ）。

这篇文章真的很旧（1999 年），所以无论当时的理由是什么，现在都可能不再是好的（反之亦然）。听到最近考虑甚至尝试过这个想法的人使用最新版本的 SQL Server 和 MS Access 会很有趣......

我正在制作游戏，其中一种方法根据技能值计算角色的基本命中数。该方法目前单独计算每个值，因为每个技能都可以在短距离、中距离和长距离上使用。

我最初认为我可以将技能组合成一个元组并对其进行迭代，动态创建每个命中数。但我不知道这是否真的可能，因为我目前将每个命中数分配给它自己的变量。

我还考虑为每个范围创建一个方法，并将元组作为参数传递。我可以使用结果值创建一个新的元组或列表，然后将它们分配给各个变量，但我不知道这样做会比这样做更好，只是它看起来不会那么复制和粘贴.

这是我目前拥有的：

您将如何重构它以使其更具动态性？

编辑：我想我想做的是这样的：有一个元组（就像我注释掉的那个）并迭代它 3 次，每次根据每个特定的修饰符创建一个新值（对于每个技能）范围。然后将结果值自动分配给它各自的变量。

在我看来，这是有道理的。但是当我真正尝试编码时，我迷路了。我认为问题在于这是我编写的第一个“真正的”程序。我之前所做的只是小脚本。

这只是我程序的 0.1 版本，所以现在重构它并不重要。但是，手动执行此操作似乎非常不符合 Pythonic，我还想“面向未来”以防万一事情发生变化。

我想要您对以下伪代码的建议。请建议我如何改进它，是否可以使用一些设计模式。

我希望你明白这一点。问题是我有大量的id，每个都有自己的操作，我认为有 10 个包含大量if和else if 的代码屏幕有点难看。