3 ms·
Right to me personally I think maintaining a version of an external project is the less ideal of the two. I personally think Monkey Patching is a very elegant s
by kls 16y ago
Right to me personally I think maintaining a version of an external project is the less ideal of the two. I personally think Monkey Patching is a very elegant solution to modifying 3rd party code that should be treated like a black box. It keeps third party code and internal code cleanly separated and if the maintainers then patch their code it becomes very easy to go in and pull your monkey patches out when the problem has been addressed. Managing the versioning dependencies for an entire project just to keep a patch set seems like overkill to me when generally you only need to modify a few lines of code in an entire project.
For example, my company is working on a huge web project for IBM right now, it is a Javascript based front end, in which we use Dojo as the toolkit. It would be safe to say that there are more lines of Javascript code than Gmail has in this project and yet our Monkey Patch files probably consist of less than 20 lines of code. It would be overkill to maintain a branch of Dojo for those 20 lines of code, especially given the fact that most of the patches are to customize Dojo to do things the way we want it too and not true bugs. So they have no hope of making it back into Dojo proper. With Monkey Patching we just maintain our own Monkey Patch files along with our code base. We just upgraded the project from 1.5 to 1.6 which if we would have been maintaining our own version, it would not have been a 30 minute process.
That being said, if a developer is Monkey Patching his own or internal code, it should serve as a red flag that they may be doing something wrong.