There is not enough knowledge of programming languages to be good developers nowadays. It is important to understand the processes of continually improving the quality of the code and its performance. The ability to configure the development processes in a team more valuable than just writing code. To do this, you need to start using new tools or improve existing ones. We will go through all stages of development and find out what can be done better.

1. Developer’s
toolchain
Dmytro Dziubenko
PayCore.io

2. About me
● 3 years in Interkassa
● CTO at PayCore.io
● 10 years in production
● https://github.com/dzubchik

3. Local development
$ git clone git@vcs.company.name/mega-project.git

4. Local development
● Docker
● Docker-compose
● Task runner
● README.md

5. Docker

6. Docker-compose

7. $ make

9. IDE
● Correct php version
● IDE templates
● Hotkeys
● Refactoring
● Necessary plugins
● EditorConfig

10. Xdebug

11. Xdebug: conditions

12. Xdebug: dependencies

14. Codestyle

15. Codestyle diff
Do you see what really changed?

16. Codestyle
● PSR-1
● PSR-2
● PSR-12 (in review)
● Framework style guide
○ Symfony
○ Laravel
○ Zend
● Code should use four spaces for indenting
● Lines should be 80 characters or less
● Opening braces must go on the next line after the
function definition
● Closing braces must go on the next line after the function
body
● Control structure keywords must have one space after
them; method and function calls must not
● Boolean -> bool, integer -> int
● Class names are written using StudlyCase
● Constants - UPPERCASE_WITH_UNDERSCORE
● Function names are defined in camelCase
● Use UTF-8 encoding
● And much more...

17. Save them all
$ composer require friendsofphp/php-cs-fixer --dev
$ ./vendor/bin/php-cs-fixer fix src --rules=@PSR1,@PSR2 --dry-run
--diff

18. Codestyle
$ ./bin/php-cs-fixer fix --config=php_cs.php

19. Static code analyze
● Phpstan
● Phan
● Psalm
● Phpstorm Inspections
● Unpredictable function result
● Array shapes
● Class, method, function exists
● No syntax errors
● PhpDoc matches real types

20. Phpstan
● Easy to install
● A lot of plugins
● Zero configuration
● Can analyze a part of project
● Quick analyze
● Neon config format
● No custom annotations
● No array shapes
● No generic annotations

21. Testing
● Cover at least critical parts
● Write functional tests
● Write tests after something is broken

23. API standard
● Response format
● Pagination
● Sorting
● Filtering
● Updates
● Error responses
● Library for
%framework%

24. API standard
● Collection+JSON
● GraphQL
● HAL
● HATEOAS
● Hydra
● JSON API
● JSON-LD
● SIREN

25. JSON-API
● Easy to implement on start
● A lot of libraries
● Easy to understand
● Resource includes
● Not trivial no CRUD operations
● Hard to implement on production
● Not suitable for all data types
● Requires custom header -
application/vnd.api+json

26. Api specification (OpenAPI)

27. OpenAPI aka Swagger
● Schema
● UI
● Sandbox
● Versioning
● Code generation

28. Project lifecycle
Dev Ops

29. Database migration
● Make database dump accessible for developers
● Run migrations on CI
● Evolutionary Database Design

31. Error handling
● Sentry
● NewRelic
● Rollbar

32. Questions?

33. Links
● https://habr.com/ru/company/southbridge/blog/323554/
● https://habr.com/ru/company/badoo/blog/426605/
● https://fwdays.com/event/php-fwdays-2018/review/static-analysis
● https://github.com/Symplify/EasyCodingStandard
● https://github.com/php-fig/fig-standards/blob/master/proposed/extended-
coding-style-guide.md
● https://modeling-languages.com/modeling-web-api-comparing/
● https://martinfowler.com/articles/evodb.html
● https://phpstorm.tips/
● RAML
● ApiBlueprint

34. Symfony development