Of course, you should read all you can about SOLID, Design patterns, Patterns of Enterprise Application Architecture, etc. Once you have a basic understanding of these topics you still have to write that code though, and write it well too! What is good code? Are there some guidelines, or rules of thumb, which you can follow while making your everyday coding decisions?

In this talk I’ll cover many of these coding guidelines, which aren’t usually covered by patterns or principles books. They should help you write better code and give you a richer vocabulary for reviewing other people’s code. Some of the subjects that we’ll discuss are: state, mutability, CQS, one-method objects, domain-first, API-driven, functional programming influences, object boundaries, (de)serialization, and many more!

Comments

Comments are closed.

Mike Lehan at 16:50 on 8 Jun 2019

Quality talk which outlines easy to understand but often unknown principles to write better software. In a perfect world this talk wouldn't be necessary - it'd just be "how it's done". I liked the graph splitting data and operations though I know some people may have differing views on it!

Dennis C. at 18:19 on 8 Jun 2019

Great talk! Lots of good takeaways and ideas for improving and simplifying your code

Arnout Boks at 23:20 on 8 Jun 2019

Great content and guidelines; talks like this should be mandatory for every programmer who does OO. I did seem to miss the FP influences though, I would definitely be interested in seeing more of those.

Alwin Drenth at 12:51 on 9 Jun 2019

Mattias is a great addition to the PHP community. Not missed a single talk of him in the last couple of years.

Can we clone Mattias to have more talks like this in the future? ;-)

THE GOOD :

Matthias Noback: enough said :)
No really, you're also a great speaker employing the right pace of speaking and keeping your slides simple is a way of engaging the audience : they have to listen a lot more to what you have to say, instead of reading it off your slides.
The talk was not too technical, nor too simple : you found the middle road.

THE 'LESS' GOOD :

Allthough your pacing was good, the talk itself was just a tad overtime, which prohibited questions by the audience, which is always a shame.
Personally, I found the subject interesting enough, but at the same time somewhat 'vague' : I am a great advocate of detailed code examples to demonstrate a point.

A great talk by a very well trained speaker about a very abstract subject, what more could you ask for for a last time slot on a conference? I however would have appreciated a bit more details (either in code examples or a few extra slides with a few details). I learned a few new things however, and will be spending some time exploring them, so I would say : Mission accomplished :)

Tim Huijzers at 00:25 on 10 Jun 2019

Some takes you choose to visit because it's an interesting subject, some talk you visit because of the speaker. With Mattias I always know it will be a good talk ans this one was not the exception. Very clear guidelines that are applicable with any code.

Matthias Noback (Speaker) at 10:33 on 10 Jun 2019

Thanks everyone for your comments! I liked your suggestions for making things less abstract (more code samples would help, I agree), to finish earlier and allow for questions, and to bring back the functional influences (they were there in a previous edition, but I forgot to add them to the rewritten version as well).

Pim Elshoff at 10:45 on 12 Jun 2019

Great content and well-explained, even though I half jokingly questioned the "state vs behavior" diagram. It's a dangerous model ;)

For 5 stars I would like to see two things improved. First off, as others pointed out as well, some polishing and examples here and there could improve things. However, secondly, I feel the talk is trying to cover too much ground. To put it in terms of cohesion: does everything in the talk belong there? Now I don't know necessarily if this is true or not. I "feel" this, writing this days after (sorry). But I "feel", again, that there are things you can scrap and still send someone off with the same message: OO is more than just shoving things into classes, and you need to think about these things.

To leave rationality even more and dive a bit more into I feel, and to mow the grass in front of my own feet as I'm thinking of a talk about this subject as well, I don't remember you diving into the why. Why do FP and OO and other paradigms end up aligning? Because the natural fit of the tools and the human process of problem solving: problem decomposition and solution composition. OO is a solution to this problem and if you learn anything else than that as the basis to OO, then you will do it poorly until you learn either the proper *goal*, or enough tricks to simulate it. In my remembering, feeling, yada yada, your talk is a good set of heuristics without the goal. I don't know if I remembered correctly, I don't know if this even matters, but there it is. Do with it what you will :)

I enjoyed your talk loads. You are a wonderful, soothing stage presence and an OO sage in this community!