Imagine a venn diagram of your last software project. Consider three parts: what the code should do, what the code actually does and what the developers think the code does. The greater the overlap the more successful and bug free your software is likely to be.

This talk examines how to increase this overlap. We'll look at the importance of type hinting, assertions and things called value objects. We'll then look at how these techniques can be combined with modern IDEs.

By the end of the talk you'll have picked up tips on how to write cleaner software with fewer bugs that does what it's supposed to do.

Comments

Comments are closed.

Despite apologising for not actually being a Drupal dev, Dave's talk was one of the most relevant and useful of the day. His approach to developing self-explanatory code is excellent and he was a very clear speaker. A good start to the day.

Johan Gant at 09:40 on 3 Jul 2017

A well delivered and put together presentation and I think I learned a bit in terms of PHP 7 syntax changes. Separately, I've seen a few TDD talks delivered now (PHP and non-PHP) and I think a really interesting/challenging subject might be a look at how TDD has been introduced into a real life project, or even a Drupal 7 project where it can be difficult to understand how to get the best out of it... instead of the more general/idealistic talks about TDD.

Swinging back to the talk itself, I think the section explaining the reasons why bugs need to be trapped early/often was particularly well illustrated. Nice one!

Rose Nichols at 11:34 on 3 Jul 2017

I was really interested in this subject and would welcome more PHP-focussed talks at Drupal conferences. The content was confidently and clearly delivered, and points made followed a logical progression which I was able to follow. Well paced throughout. I'm a big fan of seeing development principles demonstrated and explained using code samples. I took away a number of practical points and have an idea of areas where I can improve.

For next time: I was on board with the talk's premise after about 2.5 minutes (everyone wants to introduce fewer bugs into their code, and catch them earlier) so the intro could be slightly curtailed in my opinion. I liked the visual representation of this with the bars, but I think you explained it twice in the intro. Use the extra time for the conclusion, and/or to introduce more areas where we can code what we mean.

I also think you should double the amount of time you give people to digest all code examples (good and bad, but particularly the "bad" examples). Allow people to draw their own conclusions before giving them the answer, I didn't always have time to do this. It might seem like a long time to you as the presenter, but it really isn't! Maybe you could gauge it based on how many people are still looking at the screen vs. looking at you, generally if I'm looking at the speaker I'm happy for them to move on. Also, for those of us who don't have as many years of development expertise as yourself, leaving a slightly longer pause after making one main point and moving on to the next will give us time to absorb the point just made.

When taking questions from the audience, it can be useful to repeat the question for the room, in case some didn't hear it.

I am an Apprentice web developer based in Leeds. This was my first DrupalCamp. I chose this talk as in office I do a lot of QA related work. I found his presentation extremely easy to follow with informative slides. I use PHP Storm quite often in my work and from his talk, I learned a great deal more about it than I had known previously. This will go on to help me with my own coding in the future.

I also loved how there were great examples given by Dave Liddament to enhance his talk. I was able to follow these examples easily, making the strength of the talk very solid.

Overall, an excellent presentation that I was glad to attend.