Since I started working at Delicious Brains, it seems we have been hiring pretty much constantly. Prospective new hires go through a few weeks trial where they work on our products alongside the team. We have a couple of guides on our internal wiki that indicate our expectations for new developers, such as coding standards and GitHub workflow, but a recent conversation about Xdebug made me consider if, as a team, we should be more explicit about a minimum set of requirements for developers – both new and existing.

The Power of Xdebug

Jeff and a new guy on trial were digging into an issue that was hard to track down. I piped up on the Slack channel: “xdebug?”. Jeff’s response was solid gold:

Nobody knows how to use xdebug, Lain

‘Lain’ is my email support pseudonym where people don’t quite realise my name (Iain) is spelled with a capital ‘i’ when sans-serif fonts are used. It doesn’t bother me at ALL. After I stopped laughing, I needed to get to the bottom of this – I thought everyone used Xdebug?! I had even written about it on the blog before!

Turns out it really is one of those things you know you should set up, but is hard to do so, and easily forgotten if you run into problems. To be fair, I had an old work colleague set it up for me when I first started using PhpStorm back in 2013 (cheers Matt), and it was invaluable to have the setup done and a quick walkthrough of the benefits, instead of trying to hack through the installation solo.

As if I were responding to an imaginary Xdebug-Signal in the sky, I immediately jumped on a Skype call with Jeff and Matt to solve their setup woes. After 10 minutes of walkthrough they were set up and converted. No more error_log( print_r( …, 1) );!

This is not intended as a criticism of anyone’s existing methods, as anyone who uses Xdebug used to do exactly the same things to debug code issues. The thing about Xdebug is you can’t and don’t want to imagine how you debugged without it. It’s not a shiny new developer distraction tool that you can take or leave. Don’t want to use Sass? CSS is great as is. Happy with MAMP? Don’t worry about Vagrant. However, Xdebug is so powerful that not only will it save you time debugging, it does things that logging/printing simply can’t. On plugins as complex as ours, it’s vital that we equip ourselves with the best tools for the job.

I’m not just talking about enabling Xdebug and seeing a huge stack trace in your log files, but the ability to break code execution and step over, into code, inspect variables and globals, and evaluate expressions. There’s a long running joke in the team that I love PhpStorm a little too much, as I do mention how powerful it is probably once a day:

I accept that I’m bordering on fanatical evangelism most of the time, however, the integration of Xdebug in PhpStorm is just great. Great enough to repost this quick video:

Of course Xdebug integrates with other editors and IDEs like Sublime, but with all the other features baked into PhpStorm, it really is one of the best options for PHP and WordPress developers.

Here are some great resources for getting Xdebug setup with PhpStorm:

• https://www.jetbrains.com/help/phpstorm/2016.1/configuring-xdebug.html
• http://manovotny.com/setup-phpstorm-xdebug-mamp-debugging/
• http://www.sitepoint.com/install-xdebug-phpstorm-vagrant/

Code Reviews

Whenever code is pushed to our git repositories it is always in the form of a feature/fix branch that can then be reviewed, amended, and subsequently merged into the develop branch. We use the Git Flow technique for development of our products.

Code reviews can seem brutal and hyper-critical to developers on trial and even to long-time members of the team. These criticisms come from good intentions: to keep our standards high and to push each other as developers. They are never personal criticisms, rather constructive and helpful insights that are inherent to our open team culture. Let me run you through a few things the reviews focus on.

Coding Standards

One of our wiki docs is focused on our coding standards which are pretty close to the WordPress standards. Adherence to coding standards is one of the things we look for in new code, but that doesn’t mean all our plugin code is clean and tidy. We generally approach tidying up old code only if we touch it during a commit, and always ensure new code meets the standard. This way even our legacy code gradually improves, one function at a time.

We take that same approach when enhancing other areas of the code. If you’re working on an existing method and it has a missing or incomplete PHP DocBlock then it should be filled out. The same goes for refactoring. Small refactors on existing code that are part of a change you are working on are great, as long as they are fully tested. Big refactors are generally tackled in a separate, specific GitHub issue.

Code Quality

We use a number of tools to keep on top of our code quality. Scrutinizer is great at continually checking our PHP code whenever it is pushed. It can be a little particular and peculiar at times, but all in all it is a useful resource.

Our repositories use Grunt as a task runner and we leverange JSHint and JSCS to keep a handle on our JavaScript code.

Testing

Unit testing is fully embedded in our process now, and all public methods and testable code need to have a corresponding unit test when submitting code for review. The same goes when working on legacy code that is missing tests. Of course the tests also need to pass when TravisCI runs!

When it comes to functional and acceptance testing, we aren’t there yet but look to add it in the future.

A Minimum Requirement

As a result of the ‘Xdebug episode’ we have made sure everyone is set up and comfortable with it, as it’s a massive win for the development process. If you haven’t tried it yet or had issues in the past, I hope you think about using Xdebug – you won’t be disappointed.

Along with Xdebug, an editor of choice (cough, PhpStorm), and our code review standards I feel like we are in a good place for development, but of course there is always room for improvement which is why we must continue to push each other every day, questioning the tools we currently use, the ones we haven’t adopted yet, and being critical of each other’s code. Does this sound like the kind of environment you’d thrive in as a developer? We’re hiring.