Development principles, patterns and practices

- from good to great -

Anders Jönsson

This presentation will be like:

(We have pieces to eat)

Hopefully it can act as a catalyst for further discussions within the team

Agenda

1. Introduction
2. Pair programming
3. TDD/BDD
   1. Concepts
   2. Unit/integration/aac tests
4. TestText
5. Coding
   1. Patterns and principles
   2. Guidelines
   3. Code sharing
   4. Static code analysis
6. Continues integration
7. Wrap up
8. 
   Ask questions whenever you want

Introduction

Why?

Pair programming

Pair Programming: an idea from the depths of hell that actually works surprisingly well." -- Animesh Karna

Higher quality and more fun

Roles

Driver

writes the code

Navigator

keeps track of where we are and where we are heading

You should

• Switch roles often
• Stop and reflect on the problem
• Research
• Discuss different way of solving the problem
• Switch pair every day (keep one as story responsible)

You should NOT

• Pick on the drivers code while writing
• Grabbing the keyboard from the driver
• Tweeting, mailing, texting, etc while you are paring

When to pair

Mindset: all the code that goes in to production

Optional to pair on trivial tasks (e.g. updating documentations, batch updates, etc)

It's not so easy, but very fun

Further reading

• http://c2.com/cgi/wiki?PairProgrammingPingPongPattern
• http://oredev.org/videos/the-pair-programming-show
• http://pragprog.com/magazines/2011-06/pair-programming-in-a-flash
• http://martinfowler.com/bliki/PairProgrammingMisconceptions.html

TDD/BDD

TDD = Test Driven Development

BDD = Behavior Driven Development

What it is

It's a design process (with the test suite as a bi-product)

What it's not

It's not a process of writing absurd/silly test

TDD vs BDD?

Process

* tests

• Unit tests
• Integration tests
• Automated acceptance tests

Enough of that, what can we actually use in our environment?

1. Automated acceptance tests
2. Page object pattern

Further reading:

• http://dannorth.net/introducing-bdd/
• http://specificationbyexample.com/key_ideas.html
• http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd
• http://code.google.com/p/selenium/wiki/PageObjects

TextTest

Can be used in environments where TDD/BDD is hard or "impossible"

Demo

Before refactoring

LOG: calculate price
LOG: adjust price
LOG: adjust price for VIP
LOG: calculation done	
					

LOG: calculate price
LOG: adjust price
LOG: calculation done	
						

Coding

What can we do in this environment?

Guidelines

More important than you may think

Establish coding guidelines and follow them

Some guidelines

• https://code.google.com/p/google-styleguide/
• http://isobar-idev.github.com/code-standards/

Patterns and principles

• Principles
• Patterns
• Code smells

The ones we are going to talk about today is just a tip of the...

S.O.L.I.D

Separation of Concerns

Is a design principle that comprises the process of separating a computer program into distinct features that overlap in functionality as little as possible

Single Responsibility Principle

States that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class

Feature envy

The whole point of objects is that they are a technique to package data with the processes used on that data. A classic [code] smell is a method that seems more interested in a class other than the one it is in. The most common focus of the envy is the data

Demo

Can you find the envy part in this code?

(this example will not work in your environment, but I think you can get the picture)

State pattern

This pattern is used in computer programming to represent the state of an object. This is a clean way for an object to partially change its type at runtime

Demo

Before and after

Further reading:

• http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
• http://c2.com/cgi/wiki?DontRepeatYourself
• http://en.wikipedia.org/wiki/Software_design_pattern
• http://c2.com/cgi/wiki?CodeSmell
• http://c2.com/cgi/wiki?DontRepeatYourself

Code sharing (NOT review)

It's about

• Overall knowledge sharing (about the code and the domain)
• Learning from each others (coding, design, technologies, etc.)
• Increase consistency in the code base
• Point out good things
• Get a collective code ownership

Static code analysis

Before you commit, you could use tools like jshint and jslint

Further reading:

• http://jshint.com
• http://jslint.com
• https://github.com/philbooth/complexityReport.js

Continues integration

Some of the benefits

• reduce risks
• team code cohesion
• deployable software

On every commit you can

• Build
• Run tests
• Run static code analysis
• Deploy to a machine
• Create documentation
• ...

Example of some CI products:

• http://www.jetbrains.com/teamcity/
• http://jenkins-ci.org/

Example of some build languages:

• http://gruntjs.com/
• http://rake.rubyforge.org/
• http://ant.apache.org/

Further reading:

• http://martinfowler.com/articles/continuousIntegration.html
• http://www.slideshare.net/drluckyspin/continuous-integration
• http://continuousdelivery.com/

Wrap up

Decide actions

I use this everyday

• http://jsbin.com
• http://jspref.com
• http://pivotal.github.com/jasmine/
• http://phantomjs.org/

Books

• Foundations of Programming (free e-book) by Karl Seguin
• The Pragmatic Programmer by Andy Hunt
• Clean Code: A Handbook of Agile Software Craftsmanship by Robert C Martins
• The Clean Coder: A Code of Conduct for Professional Programmers by Robert C Martins

Questions?

Thank you for your time!