I've been working on and maintaining a site for tracking Cub Scout progress called Den Manager (not terribly exiciting if you don't have an account). I first wrote the site in Rails almost four years ago. About two years ago I did a pretty major refactor to reorganize the achievements so that it'd be easier to add additional awards. Finally, a month ago I migrated the site to the latest version of Rails and made a few "minor changes." This latest round of changes didn't go so smoothly, and yes I'm to blame. I didn't buy into the Rails religion completely in 2006 so I've got basically no test coverage (I'm working to rectify that now but it's hard to backfill test on years of work some of which has been through multiple refactors). But I don't want to talk about my personal failings in this post ;)
As I was fixing these latest problems I had an interesting thought.... The need for a refactor can be spotted when a small change causes many breakages in different places. In my case I changed one attribute on a class from a string to a symbol and it broke in dozens of different places (many of which I didn't spot for a few weeks because of missing test coverage). Had I had better coverage I wondered if you could build a system that monkeyed with code and intentionally introduced random bugs and then counted the number of breakages. You'd run a system like this in a CI type environment and you'd report up bugs in a particular module and how many failures it triggered. Sorting by the number of failures and you have potentially interesting candidates for refactoring.
No comments:
Post a Comment