Boasting a line-up with bright and brilliant people from every side of the PHP ecosystem and community, it would be hard for anyone to not bring home some valuable insights or new perspectives.
Image credits goes to the PHPBenelux team and blog.
For me the weekend started with a 3 hour workshop by Mathias Verraes on Model Storming, an “emergent practice in the Domain-Driven Design community”, which in its own right was quite good and had a very practical approach to the subject of modelling a business or problem domain in a simple and structured way that all parties can understand and relate to. This would turn out to be a somewhat recurring theme in a string of talks I followed.
Mapping in terms of a timeline of commands, actions, events, and other usual parts of modelling, it resulted in quite (human) readable explanations of how the domain works and what the proposed system should do. Without even thinking in ways of implementing (or really, really trying not to) it still resulted in models that could quite easily be translated to code, with all areas of special interest very clearly laid out.
Putting Thoughts into Practice
A string of talks (Let's Learn Testing, Refactoring with Design Patterns, Development, By The Numbers, Your (Coding) Standards Matter, Extract Till You Drop) went hand in hand with the Model Storming workshop to paint a big picture of how to (ideally) become the master of any existing project/codebase (or start a completely new one off) – regardless of it's size and complexity!
All models are wrong, but some are useful.– George E. P. Box
First, solve the problem. Then, write the code.– John Johnson
Modelling out the whole domain of the problem you're about to solve may seem like a tedious and unnecessary process and ultimately lost time for actually solving the problem, especially if you're a leader in your field. But the more you think you know about the domain and the more people you are working on the problem, the more likely you actually are to miss some important detail or make some arbitrary assumptions.
Don't try to see the writing on the wall, break out the post-its and actually write it all! Only when everyone who has knowledge of the problem can understand and agree on the model it can be assumed to be the least bit useful.
When the model is considered done, it probably isn't. But we can't wait on perfection for eternity, so the next thing to do should be ...... still not coding anything.
Going from The Most Awesomest Model In The World™ to the implementation of said model, caution is needed. To do right by both the problem, the model, and ourselves some steps should be taken to go from a legacy system to a nice one:
- Agree on a coding standard
- Find all the things the existing system do wrong, according to the standards
- Get the numbers on the existing system
- Find the most critical parts of the system
- Fit the parts of the system in the parts of the brand new and very sparkly model
- Choose your battles
- Write tests for (at least) the business critical operations
- Extract, extract, EXTRACT!
Tools of the Trade
In the words of Volker Dusch, agreeing on what standard to go by “really seriously doesn't matter. There is no one true standard so just pick one and stick to it” – the only thing that really matters is that it is specific enough to follow and preferably that it can be automatically checked using one or more tools.
Other tools are readily available to calculate all sorts of different metrics on your codebase, which can help you identify where the code is worst (in terms of complexity, readability, and maintainability) and those are pretty likely to be the places where the heaviest parts of the business logic reside.
Taking this newfound knowledge of the system it will most likely be much easier to map most parts of the existing system to parts of the freshly modelled system (as it should have been).
This mapping of code to model is great for showing just where to start in the actual refactoring of the existing code (hint: it's where the money is made). Starting from the top, write tests for the existing code – when they all pass and cover the code in a satisfactory way (i.e. 100 %) the refactoring can begin!
While running all the tests after each operation, no matter how minor and obvious it may seem, and committing the changes every time the tests pass, the refactoring is pretty much just a matter of moving small pieces of related logic to separate methods, make methods return as soon as possible to improve readability (and avoid code indenting further than allowed by the coding standard), and throw (properly named) exceptions instead of returning obscure data structures with homegrown error codes – in other words extract till you drop!
The title refers to a quote from Robert C. Martin about applying Extract Method and other refactors until every element in your system has just one responsibility:
“Perhaps you think this is taking things too far. I used to think so too. But after programming for over 40+ years, I'm beginning to come to the conclusion that this level of extraction is not taking things too far at all. In fact, to me, it looks just about right. So, my advice: Extract till you just can't extract any more. Extract till you drop.”– Mathias Verraes
The Actual Tools
PHP_CodeSniffer and PHPMD – Rule based code analysers that check the codebase for coding standard conformity and potential problems (e.g. code that is unused, too complex, or possibly buggy) respectively.
PHPUnit – The de-facto standard and framework for unit testing in PHP projects.
Jenkins CI and Jenkins PHP – The leading open-source continuous integration server and a ready-made setup for using it in PHP projects. The tools mentioned above can (and really should) be incorporated in Jenkins.
PhpStorm – A PHP IDE that can do magic for your productivity by running all kinds of static analysis and tools on the codebase in real time. It can also be set up to run the tools above automatically to give you instant feedback on your code quality.
A New Hope
Lastly the conference conveyed a nice feeling of hope, inspiration, and togetherness, all summed up and explicitly verbalised in the very first talk, the Keynote: Mentoring Developers on Elizabeth M. Smith.
Image credits: Wim Godden.
The talk was all about the practice of growing a good community by guiding and supporting developers of any skill level to grow to their full potential. Elizabeth had an incredibly personal approach to the subject, telling her own story of being pushed, helped, and mentored into becoming a very accomplished developer, showing pictures of her mentors and apprentices, accompanied by anecdotes from every step of her journey in the tech world.
The talk was littered with fun-size insights, which were very elegantly summed up in concise lists of things you can expect from an apprentice and what is needed from you as a mentor at the different stages, while also addressing the things that can go wrong in a mentoring relationship and how to handle it without turning the relationship into one of enemies.