As developers we have tools that can be used to reduce the impact of all these situations. We can write quality code as a team. In this session I will talk about some of the processes that we can use to write code that fails less often and fails in a helpful way. We will learn how we need to be responsible of our code and the code that our peers write, of setting expectations about the level of effort, of helping QA to cover edge cases, …

1. WRITING QUALITY CODE,AS ATEAM
DrupalCamp Spain 2014

2. WHAT I DO
• Drupal developer at Lullabot.
• Drupal contributor.
• Contrib maintainer.
• Web enthusiast.
• Occasional IRC trolling.

3. THIS IS NOT ABOUT
• Improving your code skills.
• Cookbook on drupalisms.
• How to make Drupal good at what it’s bad.

4. DISAPPOINTED?
There is a talk about responsive theming
right next door!

5. PROJECTS I AM IN
• Typically BIG sites.
• Media related.
• Limited user interaction with Drupal.
• Advertisements (random).

6. TEAMS I AM IN
• Usually the client has their own tech team.
• Drop-in (remote). Drupal expert.
• There are other consultants.
• Every team has its own culture.

7. THETEAM IS WHAT MATTERS

8. – Jim McCarthy
“You can’t have great software without a great team, and most software
teams behave like dysfunctional families.”

9. HOWTO KICK ASS INTHETEAM
• Know where your strength is.
• Make yourself available.
• Learn from other people’s code.

10. WASN’TTHIS ABOUT CODE?!
Enough of the self help talk!

11. SUGGESTIONS FOR WRITING QUALITY
CODE
• Track your tasks in a centralized and dedicated tool (PM).
• Follow git-flow (make it flexible).
• Test the code.
• Deploy often.

19. W

20. USEFULTOOLS
• drush: sql-sync, sql-drop, rsync, devify, …
• You will need to import databases from a system of record: mysqldumpp.sh, mysqlrestorep.sh,
mysqltransform.py.
• HUB
• Meme GIFs
• Google Hangouts.
• Pull request builder!

21. PULL REQUEST BUILDER
1. Someone sends a PR
2. Access check to create a dedicated environment: http://
qa32889.project.com
3. Tear down the environment.
4. Go count money!
Deployment with
only those
changes.

22. TESTINGYOUR CODE
• When you write the code and submit the PR.
• When another dev reviews your code and tests it in their local
environment.*
• When QA tests the user story.
• When QA does a regression/smoke test.
Ideally your code will be tested 4 times.

23. IT’S CHEAPER DOING IT!
By now you probably know that there is no such thing as «Quick
and dirty», there’s only «Dirty, and many times».

24. – Brian W. Kernighan
“Debugging is twice as hard as writing the code in the
first place.Therefore, if you write the code as cleverly as
possible, you are, by definition, not smart enough to
debug it.”
– ChristopherThompson
“Sometimes it pays to stay in bed on Monday, rather than spending the rest
of the week debugging Monday's code.”

25. XDEBUG

26. AVOID ENDLESS FEEDBACK
• Ask for your reviewer to be nit picky.
• Write lots of meaningful comments.
• Use long variables with meaningful names.
• Update the code explanations when making changes.

28. – Martin Golding
“Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live.”

30. SUGGESTIONS FOR WRITING QUALITY
CODE
• Track your tasks in a centralized and dedicated tool (PM).
• Follow git-flow (make it flexible).
• Test the code.
• Deploy often.

31. AUTOMATEDTESTING
• «Unit» test the key parts of your code.
• Use Simpletest for important features.
• Automate feature testing.

32. THE JOURNEY OFYOUR CODE
• It is born in your local environment.
• It’s sent to GitHub as a PR so others
can comment on it.
• It’s merged in the development
environment.
• From the development to
acceptance to stage.
• Deployed to PROD!
If you are being agile then you should do
this every sprint.