问题标签 [refactoring]

我一直在重构我和其他人的代码。当我在一个分支而不是 Trunk 工作时，这有时会导致一些极其痛苦的合并，尤其是如果我不定期合并回 Trunk（分支的代码会慢慢从 Trunc 移开，当人们修改 Trunk 我必须手动弄清楚如何将其应用于分支）。

我知道的解决方案是

1. 不断地合并到 Trunk 和从 Trunk 合并 - 减少痛苦的合并，但是为什么要在分支中工作呢？
2. 每当您需要重构某些东西时，切换到 Trunk，在那里进行重构并合并到您的分支 - 我觉得这不是很实用，因为每次重构切换环境的实际成本是巨大的。

你做什么工作？

虽然我的问题可能看起来很抽象，但我希望不是。假设我开发了一个应用程序，一个 ASP.NET MVC 站点，然后我的任务是为这个应用程序构建一个 Winforms 客户端，我可以从现有应用程序中重用多少以及如何重用？

我定义了模型，定义了控制器和视图。他们都运作良好。

现在老板来要求一个 Winforms 客户端，我希望我可以重用模型和控制器（前提是我将它们放在不同的程序集中），而不仅仅是重用视图（ASPX 视图）。

这可以做到吗？如何？

我每次都使用右键>重构>封装字段来获取我的访问器。问题是当我创建新类时，我可以拥有超过 10 个属性，并且每个访问器都需要 1 对 1 的时间。有没有更快的方法来创建它们？

感谢您的时间。

它是否处于实际有用的状态并且可以做的不仅仅是重命名类？

我正在重构“意大利面条代码”C 模块以在多任务 (RTOS) 环境中工作。

现在，有很长的函数和许多不必要的全局变量。

当我尝试用局部变量替换仅存在于一个函数中的全局变量时，我陷入了困境。每个全局变量都表现得像本地“静态” - 例如，即使您退出并重新进入函数，也保持其值。

对于多任务处理，“静态”本地变量是全局变量中最差的。它们使函数不再重新输入。

有一种方法可以检查函数是否在保留变量值重新进入而不跟踪所有逻辑流的情况下进行中继？

背景：在我的工作中，我们使用 SVN、C# 和 VisualStudio。我的部分任务经常涉及全局重命名。在重命名某些内容然后合并更改后，我经常会得到一个损坏的构建。

问题：是否有解决方案可以查看我的更改，注意全局重命名，然后将其应用于其他人在合并时所做的编辑？

获得相同效果的另一种方法是某种重构日志，然后将其应用于传入的编辑。

该工具不一定是完美的，即使它只是在他们的编辑中注意到任何引用我编辑过的东西的引用都是有价值的。

编辑我知道 VS 的重构工具。我正在寻找的是允许我在重构我的工作副本之后，将相同的重构应用于我现在需要合并的其他人的编辑的东西。

理想的解决方案是确保在我进行重构时没有未完成的编辑，但这会阻止其他人在下一周或更长时间内完成任何工作。（因为他们必须在下周每隔半小时左右同步一次）

几周前，我与一些同事就重构进行了讨论，我似乎属于少数人，他们认为“尽早重构，经常重构”是一种防止代码变得混乱和不可维护的好方法。许多其他人认为它只属于项目的维护阶段。

如果你有意见，请捍卫它。

在 ASP 经典项目的代码库上加快速度确实让生活变得困难的一件事是包含文件的情况有点混乱。我有时会发现我正在寻找的函数包含在一个完全不相关的包含文件中。有没有人对如何重构这个有任何建议，这样如果他们需要找到一个函数，就可以更容易地知道它在哪里？

编辑：我忘了问一件事：vbscript 是否有任何机制来防止文件被包含两次？有点像 C 中的#ifndef？

我有一个很大的代码库，我想重构包结构，以便大量交互的类放在同一个包中。

似乎应该可以创建一个可以查看类之间交互的工具，然后将那些交互频繁的类组合在一起。然后，这些分组可能会建议包的良好层次结构。

这样的工具存在吗？（开源是首选）。

我被要求进行代码审查并报告在我们的一个新产品中添加新功能的可行性，这是我迄今为止没有亲自参与过的产品。我知道挑剔别人的代码很容易，但我会说它的状态很糟糕（同时试图尽可能客观）。我的代码审查中的一些亮点：

• 线程的滥用： QueueUserWorkItem线程通常被大量使用，线程池委托具有无意义的名称，例如PoolStart和PoolStart2。线程之间也缺乏适当的同步，特别是在 UI 线程以外的线程上访问 UI 对象。

• 魔术数字和魔术字符串：一些Const' 和Enum' 是在代码中定义的，但大部分代码都依赖于文字值。

• 全局变量：许多变量被声明为全局变量，可能会或可能不会被初始化，具体取决于遵循的代码路径和发生的顺序。当代码也在线程之间跳转时，这会变得非常混乱。

• 编译器警告：主要解决方案文件包含 500 多个警告，我不知道总数。我收到了来自 Visual Studio 的警告，它无法再显示任何警告。

• 半成品类：代码被处理并添加到这里和那里，我认为这导致人们忘记了他们之前所做的事情，所以有一些看似半成品的课程和空存根。

• Not Invented Here：该产品复制了其他产品使用的通用库中已经存在的功能，例如数据访问帮助程序、错误记录帮助程序和用户界面帮助程序。

• 关注点分离：我认为有人在阅读典型的“UI -> 业务层 -> 数据访问层” 3 层架构时将这本书颠倒了。在这个代码库中，UI 层直接访问数据库，因为业务层部分实现但由于没有充分充实而大部分被忽略，而数据访问层控制着 UI 层。大多数低级数据库和网络方法都在对主窗体的全局引用上进行操作，并直接显示、隐藏和修改窗体。在实际使用比较薄的业务层的地方，它也倾向于直接控制 UI。大多数低级代码也使用MessageBox.Show在发生异常时显示错误消息，并且大多数会吞下原始异常。这当然使得在尝试重构之前开始编写单元测试以验证程序的功能变得更加复杂。

我只是在这里触及表面，但我的问题很简单：花时间重构现有代码库，一次只关注一个问题，还是考虑从头开始重写整个事情是否更有意义？

编辑：澄清一下，我们确实有项目的原始要求，这就是为什么重新开始可能是一种选择。我的问题的另一种表达方式是：代码是否可以达到维护成本大于丢弃和重新开始的成本的地步？