Better Faster Code reviews

Everyone knows you need to do code reviews, but with more than 2-3 developers, and in a sprint with 10+ tasks in the backlog, this is becoming an issue. This presentation will be about how we have managed to overcome this challenge and how we have made code reviews fast, efficient, and a part of our daily routine (without adding them to the list of tasks). We will emphasize on the Git approach and the methodologies around this and similar tools. We will share all our trials, fails and wins and discuss how we can make this work for you too.

Transcript

1. Better, Faster 
 Code Reviews In an Agile World Marius Constantin Stanojko Markovik a.k.a Tancho
2. Facts about code reviews: Pros: • They're important for the team • They help educate • They help spot bugs early • They improve estimates Cons: • They take time • They can cause fights • They’re difficult to explain to management • They slow down progress
3. Have you ever had this in the morning ?
4. Ok, reviewing this code will take 2 hours. 
 Easily… 
 
 Oh joy…
5. Have you ever had this in the morning ?
6. Requirements • Early feedback From Code Reviewers From PR owner • Quick to review • Easy test coverage overview • Follow our coding style rules
7. Let’s take a practical example Let’s assume we have a story in our sprint in which we want to be able to configure our application parameters and behavior remotely. Story subtasks: • Fetch and persist the Config. • Make the application behavior configurable according with the config file
8. How this looks in our JIRA board
9. feat/mobile-724/mobile-725/fetch.. feat/mobile-724/mobile-726/make.. feat/mobile-724/app-config master App-config PR1 PR2 PR3 Hot fix Hot fix Cherrypick Hot fix
10. Some Guidelines • Rebase subtask PRs and merge them to keep the history in the feature branch • Squash to master = 1 commit = 1 feature • Use a TDD approach to refactor your code without introducing any bug in your current logic • Use a lot of tooling and learn to trust it
11. • How do you split a big PR • How do you keep your history • How do you end up with a feature per commit Enter Jenkins… Quick Summary until this point What else can we do before the actual review?
12. Some Tooling Magic
13. Start End Fetch code Run unit - tests Analyze Checkstyle Findbugs Lint Pmd Sonar Sloccount Assemble Compile: SDK Demo apps Integration Tests Running Espresso Tests Publish Artifacts Save: sdk_aar files ProGuard files demo_apps_apks Maven Deploy Publish Reports Publish Analysis Reports on GitHub PRs page Our Pipeline Only on release Branches
14. Jenkins approves Sonar reviews Why Is This Important?
15. Last but not least: Train your team, And reinforce code reviews 
 on a daily basis.
16. Thank you ! Enjoy the rest of 
 Android Makers…