Hacks can be good code too(brianschrader.com)
brianschrader.com
Hacks can be good code too
https://brianschrader.com/archive/hacks-can-be-good-code-too/
6 comments
I usually add a
// TODO: description what needs to be done where and why
I feel like adding TODOs for non-critical changes are a good braindump that you can come back to.
And it's fine to leave them there for years. It's still possible to solve them when actually needed.
I've recently thanked myself for a TODO note: "oh, that not done... because that's not done [yet]! [conscientiously, deliberately]"
I've recently thanked myself for a TODO note: "oh, that not done... because that's not done [yet]! [conscientiously, deliberately]"
won't go into the whole thing, but nearly 10 years ago I was part of a large project that needed to do very funky things with iframes, one of the things it did was to open an iframe with a different than http, https uri scheme - I want to say about uri scheme but I think it was something else - this was to get around security restrictions about writing to iframes - as it happened when content was written into these iframes you needed to be able to follow relative uris, so a link between one part of the iframe and another should cause scrolling to the target.
This worked. In Chrome and other browsers, except FF. So I suggested - well why would FF know to scroll when a link is clicked when the content we have written into the iframe doesn't have a mime type? Let's try to give it a data uri. That worked in FF, but in Chrome it raised the security issues you would run into if you were getting html from a different domain.
So in the end we had to do browser detection to load the non-FF with the about or other uri scheme (can't remember) and FF with data uri.
Actually the product of this large project is being phased out now, maybe they've gotten wind that hack isn't going to work anymore soon.
At any rate my hack was chosen by the guy who had to fix the bug because it could be done with one line of code, there was another hack suggested but we didn't explore if it would even work (it would have depended on JavaScript access to DOM in iframe which I suspect might not have worked either because if browser doesn't know mime type for iframe why would it waste memory building a DOM?)
This worked. In Chrome and other browsers, except FF. So I suggested - well why would FF know to scroll when a link is clicked when the content we have written into the iframe doesn't have a mime type? Let's try to give it a data uri. That worked in FF, but in Chrome it raised the security issues you would run into if you were getting html from a different domain.
So in the end we had to do browser detection to load the non-FF with the about or other uri scheme (can't remember) and FF with data uri.
Actually the product of this large project is being phased out now, maybe they've gotten wind that hack isn't going to work anymore soon.
At any rate my hack was chosen by the guy who had to fix the bug because it could be done with one line of code, there was another hack suggested but we didn't explore if it would even work (it would have depended on JavaScript access to DOM in iframe which I suspect might not have worked either because if browser doesn't know mime type for iframe why would it waste memory building a DOM?)
Initial Code, Optimise Later. (ICOL)
This makes me think of Polaris Methodology I heard from a french tech team: Sometimes you just need to get the code working to advance in your feature or whatever you are trying to build so you add a TODO to your code; The problem is that you never come back to it.
The Polaris methodology is that after 6 weeks of the sprint, they have 2 weeks of 'rest'. Rest time is used for code that hasn't been completely finished, code that "smells". You use those two weeks to refactor what is fresh in your mind and whatever you feel needs to be made better.