The usual favorites are the ones mentioned in Aaron Patterson's puts debugging methods. I have a vim shortcut (space + D) to put out these puts statements:
For sql, I have sample queries for quick reference that does all sorts of queries that I'd mostly require in my current project (CTEs, window functions, certain joined tables etc)
Recent favorite is testing a fix directly in production by monkey-patching the existing code with the fix (not recommended (but totally recommended)).
I'm a MonkeyPatch Debugger
Prasanna Natarajan ・ Sep 24 ・ 3 min read
The usual favorites are the ones mentioned in Aaron Patterson's puts debugging methods. I have a vim shortcut (space + D) to put out these puts statements:
For sql, I have sample queries for quick reference that does all sorts of queries that I'd mostly require in my current project (CTEs, window functions, certain joined tables etc)
If you write perfect patches maybe.
But if you're app use a shared state like the database, and your patch is wrong you might become nightmares.
The wrong states resulting for your mistake are left in the database. And worst is that normally the code is not made to handle inconsistent states.
If you note the mistake in the patch you can make a correction patch but also need an sql query to correct the wrong states.
Is you don't detect it son, the code might generate wormy states for the related entities and this situation spreads.
By the time you note the database might be so inconsistent that you better drop it.
Yes, I'm aware of the risks of this approach.
I mentioned it explicitly in the post too.
Even if I know how the patch works inside out, I don't ever try this when it involves database changes. Too risky.