When should I write my own PHP components?
In the “olden days”, you’d start a new project with just the bare language: a compiler and maybe a couple of third party libraries downloaded as .zip files if you got lucky.
Solving business problems in the modern PHP ecosystem usually starts with a search on packagist.org to see if anyone has done this before. Most often they have, and their solution is elegant, useful, and well supported by a responsive community. You can save days to months of development time by using these components, and maybe contributing enhancements or bug fixes.
Is there ever a case for building your own components when there are already many mature alternatives available? I think there is, but only in rare cases.
Below is a list of questions to ask before you roll your own:
- Have you looked at all the alternatives? Have you read the code carefully for several options to thoroughly understand the design issues and trade offs the author(s) have made? Be clear about exactly what you’d lose if you picked any one of them.
- Are you an expert developer? Can you write code that is leaner and better than the others, implementing just the features you need without the clutter of supporting the broad range of use-cases and compatibility issues a generic component is required to cater for?
- Have you checked your pride level? Write a readme.md file explaining your reasons for building your own and what is special about it. Often this process of justifying yourself will make you step back and say “oh, maybe this is not so special after all”. Maybe you can use an existing alternative.
- Does it follow a standard interface so you can replace it any time you want with minimal disruption to your code? The PHP FIG have a growing suite of standard interfaces for commonly solved problems. Things can move a little slowly though. A number of unofficial *-interop (eg container-interop, http-interop) standards are well thought through starting points until the official standards are released.
- Does it use standard interfaces for any dependencies it requires (eg caching)? This makes it easy to test, and easy to switch out the dependencies as the ecosystem matures or your specific project needs change.
- Can you share it? Does it stand alone well enough you can put it in its own repository with minimal dependencies and share it on packagist.org? Perhaps others will find it useful too. If it cannot be shared, maybe you have too much domain logic mixed up in your design. See if you can pick apart the ideas. You may find an existing component will work if you do.
There are many benefits of third party components:
- Someone else has written the code so you don’t have to. This gives you speed.
- Other people are maintaining the code so you don’t have to (unless you want to).
- The code is (usually) battle tested in production in a large number of projects.
- Someone else has already solved the tricky design issues. It is likely general enough to handle your changing requirements as your project matures.
- It usually has high test coverage. It is unlikely to have significant bugs that will cost you time.
- There will be less code in your project that you need to look after.