Note: A slightly more readable version of this guide can be found here.
1. So, what are we doing tonight?
We’re going to be going through the exercises at exercism.io, with two twists:
- You’ll be writing you own tests (exercism.io gives you tests, but you’ll be ignoring them)
- We’ll be Pairing up to do them.
For the pairing, we’ll be using a method known as “Ping Pong Pairing,” so that each pair gets to write both tests and code, and it’s more clear when the “driver” should switch to another person.
2. What’s this Ping Pong Pairing?
Here’s an elegant description, from the c2.com wiki:
- A writes a new test and sees that it fails.
- B implements the code needed to pass the test.
- B writes the next test and sees that it fails.
- A implements the code needed to pass the test.
And so on. Refactoring is done whenever the need arises by whoever is driving.
3. How do I get started?
- Head on over to exercism.io
- Click the “Start Now (via Github) button
- Follow the instructions
4. And if I don’t want to / can’t sign up for exercism.io?
If you don’t want to sign up, or if you don’t have a Github account, you have two options
- Ask your pair to sign up and you can use their computer instead.
- The other option is to follow the instructions on the homepage in the “Try It!” section. It’ll walk you through how to do at least the first exercise without signing up.
5. What if I’m on Windows?
Don’t worry, there’s a Windows client. You can download the appropriate file from here (follow the instructions on that page).
If you don’t want to use that binary, you can signup for a nitrous.io account and install it on your free Linux box.
6. How do I pair up?
You can either
- Ask your neighbour if they’re up for pairing, or
- Await further instructions and we’ll pair you up.
7. What should I focus on with my code?
Here are a few quick tips (slightly updated from Tuesday):
1. A Single Responsibility
- Is your class doing only one thing?
- Is there something in your code that’s calling out to be its own thing?
- Extend this to methods, too: Each method should do only one thing
2. Descriptive Names for Variables and Methods
Avoid variable names like i, n, x, and use names like index, names_array, etc.
Use method names that describe what the method does.
3. Think about your public interface, put everything else in private
Your public methods are how people (including yourself) will be interacting with your class. Try not to pollute it with methods that really should be private.
# All other methods go here.
Your public interface should be stable, meaning that you can safely change your private methods as needed later (as long as you have tests to back them up).
4. Favour simplicity. Extract complexity into well-named methods.
5. Overall: Aim for clear intent in your code.
8. What do we do when we think we’re done?
First, run the original set of tests given by exercism.io. For example, for the Bob exercise:
Raise your hand to get the attention of a Code Reviewer. Someone will come over for a review.
Please feel free to let us know if you have any questions. Other than that, have fun! :)