Php 什么时候修改一个函数，什么时候编写一个新函数。。。？

/是n00b吗

通过这里编码的知识和专业技能，我在学习编程基础知识的同时，尽最大努力避免n00b错误

我在PHP中尽可能使用函数，并在不同的include中对它们进行排序

我现在遇到的n00b问题是，现有功能的五分之四可能与新需求相关。可能有一组稍微不同的输入，或者序列中有一两个额外的计算，或者输出需要不同的格式/结构。。。但该函数的核心仍然适用

关于何时应该将垃圾添加到原始函数，何时应该（字面上）将大部分内容复制并粘贴到新函数中，并根据情况进行调整，是否有好的经验法则

---

一方面，我觉得复制代码很糟糕，另一方面，我觉得把现有函数与不总是需要的东西混在一起很糟糕…

一个好的经验法则是：永远不要复制和粘贴

如果功能A和B的四分之五相同，则将其拆分。让它们都调用一个新函数C来实现公共部分

---

如果您将代码显示在出现此问题的地方，我们可以建议如何最好地将其拆分。

我同意@Thomas的观点，但有一条限制条件，即在将公共位拆分为新函数之前，您需要对新函数和修改后的旧函数进行一些影响分析

如果您的漂亮代码目标是以对以前超出范围的应用程序区域进行重大回归测试为代价的，那么您的项目经理、测试团队和客户将不会感谢您

在这种情况下，如果没有时间/金钱在编码方面做“正确”的事情，我将不情愿地复制并粘贴或编写一个新函数，使用旧函数来弥补所需的额外1/5，并用注释围绕它

>>>>>HACKCIDENT ZONE, 
>>>>>NEXT TIME THIS CODE IS CHANGED THE OPPORTUNITY SHOULD BE TAKEN TO CORRECT THIS HORROR
.....
.....
<<<<END OF HACKCIDENT ZONE - move on nothing more to see here

>>>>>黑客袭击区，
>>>>>下次更改此代码时，应抓住机会纠正此错误
.....
.....
为什么你发现你的函数做了4/5相同的工作？显然，您没有很好的抽象和责任分离

一个函数应该总是做一件事，做得正确，做得好。让我们以一个平均值函数为例，该函数计算整数数组的平均值。一个简单的实现将所有元素相加，然后除以元素数。但是这个除法有一个问题，它知道如何对整数数组求和。这违反了上述约束。更好的实现是将Sum（）函数与Average（）分开，并让Average（）使用Sum（）来获得整数数组的和。“一个函数应该只做一件事”这句话的副词是“一个函数应该只知道如何做一件事。对于其他事情，它可能依赖于其他抽象（例如函数）。”

你能从清晰的抽象和责任分离中获得什么


代码的可组合性更好，编写新函数更容易
无需复制和粘贴编码，可能会在整个代码库中传播错误代码
更好的可读性，读者不会因为与函数应该做什么没有直接关系的事情的实现细节而分心
允许透明的性能优化
想干就干，想死就死——不要重复你自己，重复是邪恶的

把你的职能分开。如果您将一个函数的4/5复制到5个不同文件中的5个不同函数中，并发现其中一个函数中存在错误，那么您可能会忘记至少更新其中一个。
这不是函数中的哪些代码是相同的问题，而是函数的用途是什么，以及它是否符合您尝试创建的函数的目的

考虑一下，如果您有一个计算小部件数量的函数：

function count_widgets($widgets)
{
    // Counting functionality
}

你需要一个新的功能来计算它的价值，但是要共享这个功能。您可以创建一个计算小部件或其他内容的函数：

function count_widgets_or_whatsits($thing)
{
   if( $thing instanceof Whatsit )
   {
     // Special whatsit stuff
   }
   // Counting functionality
}

但这将打破功能的契约。相反，您应该创建一个新函数，并提取常用功能：

function count_widgets($widgets)
{
    return count_things($widgets);
}

function count whatsits($whatsits)
{
    // Special whatsit stuff
    return count_things($widgets);
}

function count_things($things)
{
   // Counting functionality
}

这将：

使您的代码对其他人更具可读性。（有人很容易猜到，
count_whatsits（）
将计算瓦特数）
在被调用的内容和正在发生的内容之间提供可靠的契约。如果计算whatsits的过程发生变化，您只需修改
count\u whatsits（）
功能，而不会影响小部件的计数方式
当您更改影响其他内容的内容时，可以为您节省数小时的维护问题
这个问题更多的是关于原则，而不是一个具体的例子。可能会有很多例子：-）我想我自己能做到。谢谢。这就是为什么测试驱动开发存在于kibibu@syup，如果你对遗留应用的每个领域都有测试的话。有很多代码没有让UTsI怀疑学习“编程基础”的人会有一个项目经理、测试团队和客户。但在现实世界中，这当然是一个很好的考虑。我不同意你的
HACKCIDENT ZONE
做法。根据我的经验，代码被修改的可能性很大，而且你无论如何都要进行重构。所以你最好在头脑清醒的时候马上做，这样可以节省bug和时间。@Thomas我也不同意，但在现实的、非理想的世界中，最后一分钟或imp后的更改需要是极简主义的。尤其是当你和我一样处理金融软件的时候。我还认为变化的影响分析是编程基础的一部分。？如果你发现你已经有一个方法做了十件事，你想把它拆分，考虑使用一个坚实的重构工具来帮助你。重构php并不容易，因为它不是静态编译的