On the one hand, my initial reaction mirrored that of a number of the commenters on the article: just make a change and commit it directly, from your browser? You didn't test the change? You didn't even write any new tests? Heck, you didn't even compile it? Impulsive change is a dangerous behavior, and software is astonishingly hard to build; without the protection and warm cocoon of my multi-platform build system and my extensive suite of regression tests, I shudder at making any change to my software, even the smallest, most trivial, most elementary. I've seen too many times how "this couldn't possibly be the wrong change" comes back to bite.
On the other hand, this is the entire point of having a Version Control System, such as Subversion, Mercurial, or Perforce. Go ahead, and make a change! If it doesn't work, we can change it again. If we want to know what you changed, we can look at the differences between the two versions. If we decide we don't like that change, we can go back to the previous version. If we decide we aren't sure, and want to run more experiments, we can make a branch, and evaluate the two possibilities independently. Modern version control systems work extremely hard to ensure that digital objects can be changed safely, conveniently, and securely.
Furthermore, making the barrier to submit as low as possible encourages incremental evolution of software. In this I find much to appreciate in the writings of the Extreme Programming school:
So always do the simplest thing that could possibly work next.
...
Break your system into small testable units.
...
The best approach is to create code only for the features you are implementing while you search for enough knowledge to reveal the simplest design. Then refactor incrementally to implement your new understanding and design.
Keep things as simple as possible as long as possible by never adding functionality before it is scheduled.
If you make the barrier to submit high, if you make it too hard, too scary, too imposing to submit, then I've seen all too well what happens: people hold on to their changes. They keep them on their machine, accumulate more changes, wait forever to submit. When they finally submit, their changes are too late, and too large. It's hard to comprehend a large change, and it's hard to figure out exactly what caused a small and subtle change in behavior in a multi-thousand-line submit. Worse, when a problem is found late in the process, there is terrible resistance to going back and fixing it: "it's too late, we already built this; we can't change it now" Aargh!
Can I see myself making a change directly in the browser, then submitting it? No, absolutely not.
But I often find myself in the situation of wanting to propose a change. For example, while evaluating a bug report, or discussing a potential project on a mailing list, I often want to say:
Hey, you know this code over here? What if we made a change like this? Would that be taking us in the right direction?
And for purposes like this, I'll routinely whack out a change in my editor, then directly paste the diff output into my message, or into the comments field of the bug report, or into my design spec, or into my project tracking system. Kind of like "a picture is worth a thousand words", a little bit of concrete discussion about the actual code is far better than paragraphs and paragraphs of abstract text. Show me the code!
So in the end I find myself a clear proponent of Google Project Hosting's new "Edit File" feature. Is it the way I work? Not exactly. But is it a useful tool with the right intentions? Absolutely.
No comments:
Post a Comment