Opinionated Guide to Delivering Features
- 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?
- 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.
- 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.
- 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.
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.
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.
- 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 --rebaseto get changes from origin/master
- Run ALL of your specs
It is important to run the entire suite before pushing to origin/master. Never push a red suite.
Push to origin/master
Deploy to somewhere the product owner can review and accept your story
BEFORE YOU DELIVER, verify that things work as expected on the server where you deployed your story.
There is no better feeling than pushing that deliver button in tracker.
- CELEBRATE... hi-five your teammates, get a beer, play some "pong"
- Grab the next story. Go back to step 1.
#Lew's Opinionated Rules to Live By#
- Never commit failing specs on purpose
- Always run the entire spec suite before pushing
- Write ugly but working code first, then refactor
- Don't commit
clevercode, don't metaprogram
scaffold, your tests should drive you to write code
#You Should Also Do the Following When Possible#
My code suks, your code succs, our code sucks less.
- 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?
- Use Git like a boss
Master the following Git tools:
git commit --amendused for adding small changes to your most recent commit
git rebase -iused for re-ordering, re-naming and squashing commits
git resetused for 'uncommiting' local WIP (work in progress) commits
git add -pused for adding chunks of changes to breakup commits into logical peices rather than one monolithic diff
- 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