When one experienced and 5 junior developers are working on the project, the team leader can monitor the quality of the code manually, using the help of simple static analyzers like phpmd and phpcs. In this report, we will consider what to do next, with the growth of the team, when there are too many people for manual control, the teams already consist of strong developers. Approaches, methods of automation tools that we use on the open-source B2B eCommerce platform to control the quality of the code.

1. Code Quality Control in a PHP Project
Andrii Yatsenko, Oro Inc.

2. Andrey Yatsenko
Passionate about Symfony & DX
- Developer Advocate
- Trainer
- Conference speaker
- Mentor of Advanced PHP course on GeekHub
- Symfony 3 Certified Developer (Expert)

3. About Oro Inc.
7 offices in 5 Countries
(USA , Germany, France, Ukraine, Poland)
Global Partner Network
Open-source applications

4. www.oroinc.com

5. Code Quality
is about how good or bad the code is

7. 7/32

8. Code Quality Metrics
● Number of bugs
● Time of life without changes
● Support complexity

9. Code Support
● Read
● Maintain
● Extend
● Reuse
● Test

10. How to Control Code Quality?
● Developers ask the team lead when something goes wrong
● The team lead participates in plannings
● The team lead participates in plannings and reviews the code

11. The Team Grows

12. How to Improve Code Quality of a Big Team?

13. How to Know That the Code Quality is Improved (or Not)?
Measure:
● Number of bugs
● Time of life without changes
● Support complexity

14. How to Know That the Code Quality is Improved (or Not)?
Measure:
● Number of bugs
● Time of life without changes
● Support complexity
}Late Feedback

15. Code Support Complexity
● Readability
● Maintainability
● Extendability
● Reusability
● Testability

16. Control Code Support Complexity
● Readability (use coding standards, review the code)
● Maintainability
● Extendability
● Reusability
● Testability

17. Control Code Support Complexity
● Readability (use coding standards, review the code)
● Maintainability (review the code, write tests)
● Extendability
● Reusability
● Testability

18. Control Code Support Complexity
● Readability (use coding standards, review the code)
● Maintainability (review the code, write tests)
● Extendability (document extension points)
● Reusability
● Testability

19. Control Code Support Complexity
● Readability (use coding standards, review the code)
● Maintainability (review the code, write tests)
● Extendability (document extension points)
● Reusability (decouple to packages)
● Testability

20. Control Code Support Complexity
● Readability (use coding standards, review the code)
● Maintainability (review the code, write tests)
● Extendability (document extension points)
● Reusability (decouple to packages)
● Testability (write tests)

21. Automated Code Review Tools
● PHP Code Sniffer
● PHP Mess Detector
● PHP Code Fixer
● Copy/Paste Detector (CPD) for PHP
● PHPStan - PHP Static Analysis Tool
● PHP Semver Checker
● PhpStorm
● Symfony Insight

22. ORO Configs for Automated Code Review Tools
● PHP Code Sniffer - PSR2
● PHP Mess Detector
● PHP Code Fixer
● PHPCPD
● --min-lines 25
● --regexps-exclude Migrations/Schema/,Entity/
● PHPStan
● https://github.com/oroinc/phpstan-rules
● PHP Semver Checker

23. Code Review Types
● Formal inspection
● Regular change-based
Source: http://geek-and-poke.com/

24. Code Review

25. ● Automated tools
● Definition of done
● CR checklist
Code Review

26. Definition of Done
● Acceptance criteria are met
● All use cases are automated by Behat tests
● Unit tests cover at least 70%
● All changes are well documented
● New packages and new dependencies are approved
● CI builds are green

27. Code Review Checklist
● Functional Review
● Architectural Review
● Implementation Review
● Automated Tests Review
● Documentation Review

28. Code Review Checklist

29. Code Review Best Practices
Source: http://geek-and-poke.com/
● Limit the amount of the code under review
(max 2000 LOC)
● Spend on a review not more than 2 hours in
one time
● Start from the investigation the review scope
● Leave simple and explicit comments in PR
● Talk to author when something is not clear

30. Testing
Manual Automated

31. Manual Testing
● Covers cases that are hard to automate
(ex. time x30)
● Not effective when done only by the
developer
● Starts from ensuring what is automated
● Acceptance + Impact
● Pairwise testing

32. Automated Testing
● Unit - for architecture
● Behavioral - for business needs
● Performance - for reliability

33. Behat

34. Behat

35. Developer Documentation
● Can compensate for bad code quality
● Code comments are not documentation

36. Developer Documentation in ORO
● Feature description
● Feature usage examples
● Feature configuration
● CLI commands
● API resources
● General purpose interfaces
● Complex algorithms & data structures
● Useful links & other technical details

37. Class Comments Inspection
Checks if class/interface/trait documentation exists
and it has text doc that describes what this class is for
https://bit.ly/2FKFqz1

40. Refactoring
● Before adding a new feature or
fixing a complex bug
● Lowers the cost of
enhancements
● Improves architecture*
● After product goes to market
● Performance
● Bug fixing

41. Applying New Technologies During Upgrade
Only when there is a reason
● Security
● Developer experience
● Performance
● New features for the business

42. Conclusion
● Code quality is important
● Code quality is relative
● Code quality can always be improved
● You can control the code quality in different ways
● Review & pair programming
● Automated tests
● Manual control
● How to control depends on a project

43. References
Blog Posts
● Performing an Efficient Code Review, Part I. Best Practices
● Performing an Efficient Peer Code Review, Part II. Checklist
● Auto Testing OroCommerce-Based Application Behavior with Behat
Books
● Refactoring by Martin Fowler