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.
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
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
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
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
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
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
38.
39.
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