PHP is one of the easiest programming languages to use ever and powers more than half of the internet. With this ease of use, certain common patterns emerge that become harmful. This is especially true when your product or service is not expected to die soon. Some anti-patterns are coding, others are related to operating your service, especially with new docker stacks. We will go over some of the most common pitfalls with a focus on enterprise development.

2. Anti-patterns in php
Sep, 2020
Ahmed

3. Who is this guy
?
● Ahmed
● In the industry for about 9 years, I
worked as SRE, PM but mostly
Software engineer.
● I love all languages but PHP a little
bit more.
● Opensource advocate.

5. ● Low cost, high-risk actions.
● Composer.
● Inheritance.
● Standardization
● Testing
● Logging
● Observability
● Continuous integration
● Containers
Anti-patterns in php

6. Low cost, high-risk actions
Anti-patterns in php

7. PHP is easy and makes everything sounds that everything will work correctly on
it's own.
Low cost, high-risk actions

8. Low cost, high-risk actions
After you deploy your app to production, always expect:
- To be asked to extend certain feature.
- Add new feature.
- To get bug reports and be able to understand it and fix it.

9. Low cost, high-risk actions
Every technical action makes it easier or harder to :
- Quickly modify the code base and make the PMs/CXOs happy.
- Make you and your teammates happy when they fix a bug.

10. So, while coding ...
Anti-patterns in php

11. Composer
Please, please, do not use the Death Star,
The Death Star is a bomb waiting to explode in the
team face
always use version constraints.

12. Composer
Please do not edit composer files manually at all
Please, please, use composer commands, they are super easy.
“The new composer package is working locally but not working on the server”

13. Extending classes
● Each parent should not many children. It becomes hard to change the
parent even with 100% testing coverage.
● System design is thrown out of the window with the overuse of inheritance,
easy solutions like visibility change for the sake of easiness over-power the
design and leads to GOD-classes eventually very easily.
● This is the exact recipe to create a bad monolith

14. Extending classes
Inheritance is not the only way
to extend a functionality.
Also taxes are high
on inheritance these days.

15. Extending classes
Inheritance is not the only way
to extend a functionality,
for example composition.
https://en.wikipedia.org/wiki/Composition_over_inheritance
Fun Fun Function: Composition over Inheritance

16. Depending on the environment
Avoid depending on the environment, for example
Instead: you can use environment variables
“I can not test it, It works only on PROD”

17. Standardization
https://xkcd.com/927/

18. Standardization

19. Standardization

20. Standardization
API with no OpenAPI/Swagger specs is not an API.
But It’s a good way to waste time and frustration everyone.
https://github.com/zircote/swagger-php
https://api-platform.com/

21. Standardization
Kafka messages without avro schema is the best way to make debugging a
nightmare.
Also please do not serialize 1 MB of data in kafka please, Kafka is not MySql.

22. Testing
Testing positive cases only
is not great idea

23. Logging

24. Logging
“It’s not working”

25. Logging
“We do not know what happened”.
“This is my best guess”.
“It’s only 1 customer of 1000, I’m sure he need to clear the cache.”

26. Logging
Logs are insurance policy,
you don’t care about it till you need them, then it’s too late.
Bare minimum: please please log any failures to perform external operations or
operations impacting business process.
(dbs, , kafka, curl, … )

27. Logging
Example of stressful and also useless logging messages
“Error happened”
“Order not processed”
“Life is hard”

28. Logging
Log level matters,
if everything is WARNING or ERROR then nothing is important.

29. Observability
“Do you know that your website is down ?”
“A customer called and said he sees something in checkout says 503.”

30. Observability
Create alert for website downtime.
Also watch the business impact,
“no orders in the last hour”.
Simplest tool is uptimerobot , similar tools.

31. Observability
Watching/having-and-alert for error logs.
Simplest tool is sentry.io, similar tools.

32. Continuous integration
The team discussed best practices, and after a lengthy discussion, they agreed.

33. Continuous integration
Best practices are amazing, but we are humans, we always do mistakes.
“We are only humans” said by ahmed , 11 sep 2020
Automate anything you can in your application pipelines, save your team the
hassle.
Gitlab ci, bitbucket ci, circle ci, buildkite ci, …..

34. Containers
Docker is a company with a tool after it’s name.
The technology name is containers.
Please use “containers” instead of “docker”.

35. Containers
In short, containers images are compressed archives contains
- your application code itself
- The binaries that run it (php fpm)
- The binaries config (php.ini)

36. Containers
Please use aggressive opcache options on docker/containers on PROD
Opcache.validate_timestamps => 0
Each deployment is a new container with new memory,
no need to worry about this.

37. Containers
Storage in containers are ephemeral,
please do not attempt to write on it or use for anything,
even for logging, especially for logging.
Use GCS or AWS S3 or anything else.
Send logs to centralized logging.

38. Containers
Containers startup time should be very very small
In other words:
Composer install on container startup is a bad idea.
Npm install on on container startup is a a bad idea.

39. Containers
The same container image must be
deployable to production, staging and local.
If not, debugging becomes impossible and testing extremely hard.

40. More resources
Video: PHPUnit Best Practices (Sebastian Bergmann)
Video collection: Best practices in PHP
Article: Eliminating Visual Debt

41. Questions ?
Thank you for listening
Twitter: ama_abdou
WWW: ahmd.io