最近也在帮助朋友处理一些问题的时候，对这个功能也有了进一步的了解。

monkey patch是从“游击队”的英文"guerrilla"里转变过来的，他表面的意思其实和用法一点都不相关。他是一种处理机制，一种紧急的动态热修补很好的方法。改动量小，处理比较快速，适合于线上需求快速变化而不动底层的解决方案。

在实际的运用中，经常会有调用底层类或者第三方包类时，对其功能不满足，从而需要改写的情况。这时候就可以对其进行patch。

Foo.get_sum = get_sum
Foo().get_sum

上面是对原类进行动态替换的一个简单例子，我们可以改原来类，代价比较大，而且不单单是去改原类增加if else那么简单，我们需要对其进行分析抽象化，这才是对底层基类最合适的修改。
可能有人会问为什么不做子类，继承重新改方法。这是可行的，但是忽略了使用monkey patch的前提，尽可能的少改动代码，做动态的替换。

其实，解决这个问题有很多的方法，如果我可以对基类重新分析重构，我会使用hook对这个case进行挂钩处理。但是在最快的时间最简单的处理模式，还是monkey patch合适一些。

它对那些临时提需求，想把各种效果看完而又不下单的客户来说是性价比最高的解决方法。

尽管monkey patch还能做很多的事情，有些也超出我所掌握的范畴。但在这个应用方面上，我其实是有一点的排斥的，我们不能因为有了这个"贴膏药"式的补救措施，就忽略了对模块架构的长远布局，“膏药”越贴越多，逻辑也会越改越混乱，这些对于一个系统来说是不会有任何提升的。

反而我们对底层进行架构的时候就应该提前考虑他的通用性与扩展性，哪怕临时做了补丁，后面稳定了也方便对底层进行更新。这才是一个优秀程序员的良知和义务。