With Grails, Rails, Python, etc offering developers the chance to change code, hit refresh and see the changes I often wonder if reload truly a feature that is a must have these days? It seems like it is one of the main selling point by most of the folks pushing those frameworks.
I think this is not a requirement, and doesn’t really increase productivity. Here’s why:
- This promotes less tested code as you can code an entire app without testing at all by simply hitting refresh
- The testing cycle is lengthy by nature, so you do any testing during development, it is going to take some time
- Rather than using reload, if you use the development cycle of write, test, run or test, write, run, than starting up the application incurs minimal overhead in addition to running the tests
So, what are we really trying to accomplish while developing? Better code, less code, better tests, faster development. These things seem to imply great conventions and excellent extensibility and not reloading.
4 thoughts on “Do we really need code reloading?”
I agree that instant reloading of code while writing production code isn’t all that important. I found it quite neat when I first started Rails, but lately I’m instead in the mode of running autotest and TDD.
Where I do find reloading invaluable, however, is when I’m in an exploratory mode. For me, this is often when I’m trying to isolate the cause of a bug before writing tests to expose and fix the bug. Being able to drop debug statements into the file and reload can be quite useful.
I’d also imagine that reloading is a real boon during prototyping. When you’re in that mode, you aren’t really writing many tests, so having a shorting code-compile-run cycle is beneficial.
I disagree that it’s not important – I find it annoying anytime I can’t just hit refresh and see changes. What happens when you’re not working on backend code? Should I have to go through the entire process?
It’s probably true what you say about “This promotes less tested code as you can code an entire app without testing at all by simply hitting refresh.”
But to me, that says something about the way we test – not the convenience of the code.
If it’s harder to do the right thing (testing) than the wrong thing (less testing), we shouldn’t make the other deployment harder so the testing seems easier.
We should make the testing easier.
I don’t know how we might do that, but it makes more sense to me to concentrate there than making our life harder in other areas so testing seems like the path of least resistance (or at least, not that much harder).
@Doug – Good points and I think I agree on most of those points. I don’t really code like that, but I think a lot of folks do. There are times though that I wish I just had a simple playground for testing something out quick.
@Sammy – It sounds like you have different perspective than Doug. You want a way of testing and reloading that are both easy. I think these are valid, but I guess my point is that in most cases when I’m coding I take a different approach. I don’t even start up the application until it is tested and if things don’t work I head back to the tests. After a year or so of rails and grails dev I found that if I did get into the cycle of reloading, I’d look back at the end and realize that my tests were borked and I’d have to go back and update them all. Therefore my cycle was code, test, run where the amount of time that it took to run after testing was extremely small (3-5 seconds).
However, there is something to be said for the case when you are functional testing a piece of code that is nested deep inside the application and requires you to log in, click 10 times, edit something and hit submit. I think case I could definitely see how reloading would be great. At the same time, it makes more sense to me to reload via running the tests. That way you are covered in both areas.
We have unit testing hooked up to our code reloading. If the code fails to parse, then the changes made to it are not put in place. And correspondingly, if the code fails its unit tests, then the changes made to it are not put in place.