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, …
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.
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.
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.”
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.
27.
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.”
29.
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.