Would you like someone to help you refactor some of your code? If you are going to be at RailsConf, then I am happy to pair with you for 30 minutes doing just that.
We will pair on your machine, on your Ruby/Rails codebase with an existing RSpec/Cucumber test suite. We will refactor code in either your specs or your app. Being a refactor, there should be little to no domain expertise required.
Refactoring your specs. Specs directly affect the shape of your code. Well-written specs lead to well-written code. Spending time to refactor your specs pays off dividends immediately in any code base. Unfortunately the last thing on just about everyone’s list is refactoring the specs. Until the suite is just so painful to work with that something has to be done.
Refactoring your code. When you are shipping code1, there is a gap that occurs between the code you write and ship now versus the code you could have refactored and shipped later2. The code is clean, tested, and working but there just happens to be an idiom that everyone uses, or a pattern that can be applied, or a known better (but not more correct) algorithm, or just additional refactoring that has only been enabled by the previous refactors. The shipping tension cuts off those additional refinements3, even those that are trivial in hindsight — looking at them later makes you wonder why you just did not make the change in the first place.
In response to this tweet from Steve Klabnik (@steveklabnik):
— Steve Klabnik (@steveklabnik) February 14, 2012
I quickly offered a spike showing how to restructure the code:
— Les Hill (@leshill) February 14, 2012
Seeing a random (and statistically meaningless :) sample of real world code is research for my next talk: Be Happier, Write Better Code. Real world code is code written under commercial stresses, from the intentional: Lean Startup! to the unintentional: Conway’s Law.
The goal is to see what real world code looks like.
At no point are you giving anyone else access to your code4. No identifying information will be used for the talk. Only you and I will be examining the code (there is no audience participation.)
Here are the rules:
To get started, sign into PrivatelyApp.com with your Twitter account and start a private conversation with @leshill. In private and in more than 140 characters tell me how I can help you.
If we come to an agreement, we will pick a 30 minute time slot. I am leaning towards time slots in the evenings (6 to 11 p.m.) on either Monday April 23, or Tuesday April 24.
1 Code that is clean, tested, and working — sloppy, untested code that just happens to work is at best an experiment.
2 Let’s call this gap Working Code Wins. An observation that a shipping trade-off was made. Another post perhaps?
3 Technical Debt is a related concept. Originally, Technical Debt meant coding your existing but incomplete understanding, and then modifying the code with the insight and understanding gained from experience; paying down the debt of your incomplete understanding. Now Technical Debt has been abused and diluted to mean anything undesirable in a codebase.
A more useful definition is deliberately choosing deficient designs or algorithms to acheive short-term goals. For example, implementing a simplistic and unscalable algorithm instead of a robust, complex, and scalable algorithm because you have 5 users and not 1 million users. If, by happy chance, you start up the hockey stick, you will have to pay that Technical Debt off. The debt comes in two forms: you implement the more complex algorithm anyway, and the implementation may turn out to be more difficult in the existing codebase than if it had been implemented up front.
4 The code never leaves your machine and you are the only person touching it.