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.
jenny
on 16 Dec 10Presumably you would have a unit test for that method, and it would be even easier to swap out the implementation later.
Anonymous Coward
on 16 Dec 10tldr; use encapsulation
Youssef Sarhan
on 16 Dec 10I had a very similar discussion about this with a friend last night. Hack your way to concept. Once the interactions are working then start ironing out out the standards.
Mark Wilden
on 16 Dec 10When I was first learning OOP, a wise programmer once told me “OOP lets you write bad code.”
He meant exactly what you did. Do what works, make sure its badness doesn’t leak out anywhere, then fix it later – if necessary.
John Bower
on 16 Dec 10I do usually follow this approach specially when working alone however it is subjective and requires discipline as you have to ensure the work is refactored in the future and not put as a low priority backlog task.
When working in a in a team it may help to manage the initial implementation and refactoring as one atomic task.
Pete
on 16 Dec 10how about adding search functionality to Basecamp. Today I wanted to search for FTP access for a project, and I had to scour through several dozen messages before I finally found it.
Pete
on 16 Dec 10nevermind, just found it… maybe incorporate it into the sidebar?
Anonymous Coward
on 16 Dec 10Pete: Basecamp has search. Click the search tab. There’s one on the Dashboard to search all projects at once, and one in each project just to search that one project.
Phil McClure
on 16 Dec 10Indeed, Information Hiding is something I spend a lot of time on when refactoring.
Romain
on 16 Dec 10Defining clean interfaces to hide implementation and provide a modular design is sort of programming 101. I doesn’t hurt to have periodic reminders, though ;-)
Hibuscus
on 16 Dec 10John – I agree this works better for a solo programmer, I’ve seen it go wrong for teams, especially teams with frequent turnover. The client pushes for a quick prototype, when it works they love it and rush it to market and then focus on the next quick prototype, and no one remembers to go back and clean up the spaghetti mess of hacked-together code that drove the original prototype, which the poor new programmer has to maintain. So yes, discipline is also required for this to work well.
John Lein
on 16 Dec 10This is one of my favorite working processes when building Rails apps with developers. Once I have a nice method name I can hack in my junky code for use in mocking up views with real content while passing off the method to the programmer to build the proper code. I don’t have to wait on them to build something to my specs, and they don’t have to mess around with hooking their final code up to my views. Makes for a smooth project sharing flow.
Michael
on 16 Dec 10A key here is documenting the crap code that needs to be rewritten and making sure that it doesn’t accidentally make its way into production.
Sometimes this proof-of-concept code ends up being deployed either accidentally, or intentionally because “it’s working OK at the moment, let’s spend time on something that’s broken instead.”
I agree that this is a great way to get from point A to point B, but you’ve got to be disciplined enough to come back and clean up your mess instead of moving on to something sexier.
GregT
on 16 Dec 10Here are a few more coding tips similar to the one presented:
1. Code that compiles is better than code that doesn’t compile.
2. Code that is one continuous string of tokens with no whitespace or formatting is harder to read.
3. Code that is copied and pasted over and over is not generally a good thing.
You’re welcome.
AAology
on 16 Dec 10if u must deliver a dirty implementation for a shortcut to a clean concept, tuck it behind a clean interface. whats harder, maybe slightly, is knowing when the shortcut stops being a shortcut
This discussion is closed.