Coding tip: Clean interface for an ugly implementation Dec 16 2010
15 comments Latest by AAology
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.
Got a web design project in mind? Find a web designer on Sortfolio. Browse by visual style, portfolio, budget, and geographic location.
Over 1 million people use 37signals' simple web-based software to collaborate on projects, track contacts, and organize their business with an intranet.
15 comments so far
jenny 16 Dec 10
Presumably you would have a unit test for that method, and it would be even easier to swap out the implementation later.
Anonymous Coward 16 Dec 10
tldr; use encapsulation
Youssef Sarhan 16 Dec 10
I 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 16 Dec 10
When 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 16 Dec 10
I 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 16 Dec 10
how 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 16 Dec 10
nevermind, just found it… maybe incorporate it into the sidebar?
Anonymous Coward 16 Dec 10
Pete: 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 16 Dec 10
Indeed, Information Hiding is something I spend a lot of time on when refactoring.
Romain 16 Dec 10
Defining 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 16 Dec 10
John – 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 16 Dec 10
This 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 16 Dec 10
A 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 16 Dec 10
Here 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 16 Dec 10
if 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
Comments are closed