有什么理由不重构它，让它更简单

本文关键字：更简单 重构 什么 理由 | 更新日期: 2023-09-27 18:32:05

>我在遗留代码库中遇到了这个问题：

string[] deptNo = UPC.getDept().Split(new Char[] {'.'});

。并认为这会更直接：

string[] deptNo = UPC.getDept().Split('.');

。但是，如果点的表征有可能造成一些"魔术"，如果我进行此更改，将导致整个意大利面条屋滑落，则不想更改它。

更新

针对给出的警告：是的，我知道你的意思是，在吃多年的意大利面时需要非常谨慎。对此代码的一个看似无害的更改：

private void comboVendor_SelectedValueChanged(object sender, EventArgs e)
{
    try
    {
        if ((comboVendor.SelectedIndex >= 0) && (cmbVendor.Text != comboVendor.Text))
        {
            string t = comboVendor.Text; 
            t = t.Substring(0,maxVendorChar);
            t = t.Substring(0,substrLen);
            t = t.Trim();
            cmbVendor.Text = t;
            cmbVendor.Focus();
        }
    }
    catch (Exception ex)
    {
        Duckbill.ExceptionHandler(ex, "frmInv.comboVendor.SelectedValueChanged");
    }               
}

。即，将"Trim（）"附加到"的实例中。文本"，导致错误消息"指定的参数超出有效值的范围"，因为"maxVendorChar"不大于被子字符串的字符串的值。所以我不得不将其更改为此以使其工作：

private void comboVendor_SelectedValueChanged(object sender, EventArgs e)
{
    int substrLen;
    try
    {
        if ((comboVendor.SelectedIndex >= 0) && (cmbVendor.Text.Trim() != comboVendor.Text.Trim()))
        {
            string t = comboVendor.Text.Trim(); 
            substrLen = GetLowerInt(t.Length, maxVendorChar);
            t = t.Substring(0,substrLen);
            t = t.Trim();
            cmbVendor.Text = t;
            cmbVendor.Focus();
        }
    }
    catch (Exception ex)
    {
        Platypus.ExceptionHandler(ex, "frmInv.comboVendor.SelectedValueChanged");
    }               
}
private int GetLowerInt(int first, int second)
{
    return first < second ? first : second;
}

在远处，我听到一只乌鸦在呱呱叫"永远"，但我不确定他在说什么。

更新 2

每当人们注意到这个项目有多滑时，他们几乎总是建议我重构它;然而，如上所述，有时一点重构会引发一系列震耳欲聋的爆炸声，让我希望我一个人呆得够多了。真正的解决方案是完全重写这个项目，使用更好的方法和至少不太古老的技术。这就是我的愿景;不过，就目前而言，维护模式似乎是当务之急。

有什么理由不重构它，让它更简单

如果您正在处理"一个大泥球"，那么最好不要管（假设它的行为正确）。

取决于你在寻找的是哲学原因还是技术原因。

没有技术原因。没有魔法，两种说法是一样的。split 的方法参数使用 params 关键字来允许可变数量的参数语法：

public string[] Split(params char[] separator)

有关将 params 关键字添加到方法参数的目的，请参阅此讨论：为什么使用 params 关键字？

从哲学上讲，重构它可能没有任何真正的好处。作为一般规则，您可能不想仅仅因为可以就清理，尤其是在没有测试的情况下。

听起来你需要一些单元测试来让你对重构的代码有信心。最佳做法是在重构之前添加它们。

我们看不到Split()方法的方法签名，但如果它使用 varargs，那么您的重构在理论上是安全的。

假设getDept()返回一个字符串，第一种方法的优点是更容易包含新字符作为拆分器。您只需将它们添加到 char 数组中即可。第二种方法修复分隔字符。在第二种方法中，'." 也是一个字符，不像 "."，它是一个字符串。如果该方法getDept()返回一个具有 Split(char[] splitters) 方法的自定义类，除非该方法的重载为 Split(char splitter)，否则您将遇到麻烦。在一个完全不相关但很重要的一点上，实现版本控制系统可能是一个好主意，这样当某些事情失败时，你可以"重新滚动"更改（即返回到以前的"提交"）。

我认为重构此代码没有任何价值，因为我在这里看不到这项工作的任何附加值。

此外，我也会保留当前代码，因为它允许我在将来添加更多分隔符。

相关文章：