Lews_guide_to_delivering.md

#Lew's Opinionated Guide to Delivering Features#

---

1. First, understand the story.

Do you understand the story completely? If not, talk to the product owner to clarify your understanding.

Is the story a logically cohesive grouping of functionality? If not, can it be broken into multiple stories?

Do the points assigned make sense given your current level of understanding of the story? If not, can it be broken into multiple stories?

2. Organize your thoughts and approach to the story.

Create a task list in the story for the steps you will take.

Breifly review any existing code in the area you will be working.

3. Your coding journey should begin and end with a request (feature / acceptance) spec.

The first lines of code you write should be a failing test that drives the browser. Make sure it fails "correctly" before moving on to the implementation.

The test should be written such that when it goes green you will know the story is finished. However, you may have to update the spec as your knowledge about the feature deepens.

4. Let the tests drive you toward implementing more and more of the story.

Failing specs should cause you to "drill in" to the problem.

For example, consider a brand new page. The request spec might be failing due to a 404 Not Found which would drive you to create a controller. That in turn might have failing specs that would cause you to create a model or some other domain objects.

5. COMMIT!!!

Commit often. A great time to commit is after you have a spec or set of specs green. Even if the commit is tiny, don't hesitate. You can always squash some of the small commits later.

6. Refactor

After commiting is a good time to go over your existing implementation and make it better.

Remember, refactoring is making your code do the same thing in a better, clearer, cleaner way NOT writing new tests and making code do more things.

7. Once you have circled all the way back and your request spec is green...

Format your final commit, clean up any "wip" commits, etc.

git pull --rebase to get changes from origin/master

8. Run ALL of your specs

It is important to run the entire suite before pushing to origin/master. Never push a red suite.

9. Push to origin/master

10. Deploy to somewhere the product owner can review and accept your story

11. BEFORE YOU DELIVER, verify that things work as expected on the server where you deployed your story.

12. DELIVER!!!

There is no better feeling than pushing that deliver button in tracker.

13. CELEBRATE... hi-five your teammates, get a beer, play some "pong"
14. Grab the next story. Go back to step 1.

#Lew's Opinionated Rules to Live By#

---

1. TEST!!! Commit no code that was not tested BEFORE it was written (Yes, this includes javascript)
2. Never commit failing specs on purpose
3. Always run the entire spec suite before pushing
4. Write ugly but working code first, then refactor
5. Don't commit clever code, don't metaprogram
6. Never scaffold, your tests should drive you to write code

#You Should Also Do the Following When Possible#

---

1. Pair

My code suks, your code succs, our code sucks less.

2. Maintain a project style guide. Your code should be beautiful and your team's code should look like one person wrote it.

How many spaces do you indent things?

Do you use double or single quotes in strings?

Do you seperate end's at the end of blocks with an empty line or not?

3. Use Git like a boss

Master the following Git tools:

git commit --amend used for adding small changes to your most recent commit

git rebase -i used for re-ordering, re-naming and squashing commits

git reset used for 'uncommiting' local WIP (work in progress) commits

git add -p used for adding chunks of changes to breakup commits into logical peices rather than one monolithic diff

4. Use your editor like a boss

You should know how to do the following in your editor:

Do all your editing without a mouse

Run your specs - you should not need to switch to the terminal to run your specs

Kill an entire line

Edit multiple lines at once

Select a word or part of a word

Switch between spec files and implementation files in one command

I don't even know how to test javascript! Looks good man.

Good stuff Lew!

A good addition to committing early/often is to work on a feature branch in git.

git checkout -b add-awesome-thing

When you're ready to deliver the feature, you can choose to merge several tiny commits into one (or even a few) cohesive commits.

git rebase -i master
# change order of commits, squash commits together, change commit messages, etc.

git checkout master
git merge add-awesome-thing
git push