寻找猴子修补有什么问题的具体示例？
我听过很多关于猴子修补是如此酷或者猴子修补是地球上最糟糕的事情的赞叹。 我的想法是，如果您编写一些代码，然后其他人更改其功能以执行其他操作，那就不好了。 但我正在寻找一个具体的例子来说明这可能真正伤害你的情况。 我的意思是，我一直在编写代码，然后我的同事对其进行更改。 那么，猴子修补与此有何不同呢？ 可能发生的最坏情况是什么？
I've heard a lot of oohs and aahs about how monkey patching is so cool or monkey patching is the worst thing on earth. I have the idea that it's not good if you write some code and then someone else changes its functionality to do something else. But I'm looking for a concrete example of a situation where this could really hurt you. I mean, I write code all the time and then my coworkers make changes to it. So, how is monkey patching any different from that? What's the worst that could happen?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
编程已经缓慢但稳定地远离了需要理解全局状态来理解局部行为的编码实践。 一些示例：
远距离编码以查看如何到达特定行。
猴子修补意味着如果不查看程序中的所有其他代码行，就无法知道一行代码的作用。 快速完成某件事可能很有用，但它会使大型程序变得难以理解。 由于许多大型程序都是从小程序开始的，因此猴子修补可能是您想要改掉的习惯。
Programming has had a slow but steady movement away from coding practices that require understanding global state to understand local behavior. Some examples:
code far away to see how you get to a particular line.
Monkey patching means that there is no way to know what a line of code does without looking at every other line of code in the program. It might be useful to get something done quickly, but it will make large programs impossible to understand. Since so many large programs start as small programs, monkey patching is probably a habit you want to get out of.
猴子修补会向对象的其余部分以及对象的文档隐藏对对象的更改。 使用该对象非常容易，检查它的文档以确保它符合您的预期，然后发现它并不完全那样工作。
如果您从事的项目有开发人员流失，那么这尤其糟糕，您需要更多地担心如何让新开发人员跟上您的代码库的速度。 新开发人员不会意识到补丁的细微差别，因此您将很难从中获得好的代码。
至于可能发生的最坏情况，如果您的应用程序中存在错误，可能发生的最坏情况是什么？ 有人会因为设备功能不正常而死亡吗？ 您是否可以通过向某人发送错误的账单或向他们的帐户收取过多费用来破坏他们的信用评级？
Monkey patching hides changes to an object from the rest of the object, and from the object's documentation. It's very easy to go use that object, check it's documentation to be sure it does what you expect, and then find out later it doesn't quite work that way.
This is especially bad if you work on a project that sees developer churn, where you need to worry more about how to bring new developers up to speed with your code base. New developers won't be aware of the nuances of your patches and you'll have a harder time getting good code out of them as a result.
As for the worst that could happen, what's the worst thing that could happen if there's a bug in your app? Could someone die because of a piece of equipment functions incorrectly? Could you ruin someone's credit rating by sending them the wrong bill or charging too much to their account?
这在某种程度上取决于环境，即您是否与其他人共享代码。 不过，请考虑一下可以在 Smalltalk 等中完成的操作：更改
+运算符的含义。 如果我引入一个+函数，例如，从一个参数中减去另一个参数，事情就会以华丽且意想不到的方式发生变化。It kind of depends on the environment, ie, are you sharing code with anyone else. Consider, though, something that can be done in, eg, Smalltalk: change the meaning of the
+operator. If I introduce a+function that, say, subtracts one argument from another, things are going to break in florid and unexpected ways.嗯，这实际上取决于你的意思......
有什么要求？ 无论是现在还是以前。 如果需求发生变化并且生成的代码集必须更改，这称为维护或增强。 在现实世界中，我很少能遇到“猴子补丁”有效的代码，尽管它也很大程度上依赖于代码的编写者、多久前等。太多的变量无法给出真正有效的答案。 简而言之，如果这是您需要做的，以便在客户需要时为他们提供他们想要的东西，那么这可能是一个很好的“哦，最好这样做”。 这一切都与您的观众有关。
Well, it really depends on what you mean by...
What are the requirements? Both now and before. If the requirements have changed and the resulting set of code must change, this is called maintaining or enhancing. It is rarely I am able to meet a piece of code in the real world where "Monkey Patching" is effective, though it also relies heavily on who wrote the code, how long ago, etc. Too many variables to give a really effective answer. In short, if it is what you need to do to give your customers what they want when they want it, then it is probably a good 'ooh, better do it'. It is all about your audience.