Writing faster managed code Claudio Caldato Program Manager CLR Performance Team.
Writing quality code, as a team.
32
WRITING QUALITY CODE, AS A TEAM DrupalCamp Spain 2014
description
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, …
Transcript of Writing quality code, as a team.
WRITING QUALITY CODE, AS A TEAMDrupalCamp Spain 2014
WHAT I DO
• Drupal developer at Lullabot.
• Drupal contributor.
• Contrib maintainer.
• Web enthusiast.
• Occasional IRC trolling.
THIS IS NOT ABOUT
• Improving your code skills.
• Cookbook on drupalisms.
• How to make Drupal good at what it’s bad.
DISAPPOINTED?There is a talk about responsive theming
right next door!
PROJECTS I AM IN
• Typically BIG sites.
• Media related.
• Limited user interaction with Drupal.
• Advertisements (random).
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.
THE TEAM IS WHAT MATTERS
– Jim McCarthy
“You can’t have great software without a great team, and most software teams behave like dysfunctional families.”
HOW TO KICK ASS IN THE TEAM
• Know where your strength is.
• Make yourself available.
• Learn from other people’s code.
WASN’T THIS ABOUT CODE?!Enough of the self help talk!
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.
W
USEFUL TOOLS• 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!
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.
TESTING YOUR 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.
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».
– 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.”
– Christopher Thompson
“Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday's code.”
XDEBUG
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.
– Martin Golding
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”
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.
AUTOMATED TESTING
• «Unit» test the key parts of your code.
• Use Simpletest for important features.
• Automate feature testing.
THE JOURNEY OF YOUR 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.
