Sometimes you need to take shortcuts to quickly prove a concept. I’m experimenting with a new view on Basecamp and I need some data to generate that view. I want all the messages on a project, grouped by day, and also the latest comment per message per day. I don’t know the “right” and performant way to put that query together. But I don’t need to worry about that. I’m just testing a concept here.
So I wrote a totally ugly, awkward implementation that gives me @posts_and_comments. And that’s ok. If this design is successful, the fact that I want @posts_and_comments isn’t going to change. What will change is the implementation that pulls that data out of the database and populates the instance variable. In order to make that future step as easy as possible, I’m hiding my ugly implementation behind a clearly named private method on the controller. The controller action calls `find_posts_and_comments_for_log` and as far as the view is concerned, nothing untoward is happening.
If the concept doesn’t work out, no problem. I didn’t spend too much time on the implementation. If the concept does work, the ugly implementation will be easy to replace later because it’s tucked behind a clearly defined method.
When your implementation is a total hack, put it behind a good interface. Then you can swap the implementation later without rethinking the design.