The document outlines a developer's toolchain, highlighting local development processes using Git, Docker, and various coding standards based on PSR guidelines. It emphasizes the importance of static code analysis, testing, and API specifications, particularly with OpenAPI for versioning and schema generation. Additionally, it provides links to resources for deeper understanding of coding standards and API modeling.

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