1 / 28

Code Review as a Great T ool in the Agile Toolbox

Code Review as a Great T ool in the Agile Toolbox. Matthias Sohn, Stefan Lay (SAP ) Matthias.sohnn@sap.com , stefan.lay@sap.com Twitter: @ masohn  @ stefanlay. Agenda. How we became agile What we learned from Open Source Why we embraced Code Review

madison
Download Presentation

Code Review as a Great T ool in the Agile Toolbox

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Code Reviewas a Great Tool in the Agile Toolbox Matthias Sohn, Stefan Lay (SAP) Matthias.sohnn@sap.com, stefan.lay@sap.com Twitter: @masohn @stefanlay

  2. Agenda How we became agile What we learned from Open Source Why we embraced Code Review How we scale up agile with Open Source processes

  3. Agile Feedback cycles Source: http://en.wikipedia.org/wiki/Extreme_Programming

  4. Agile Feedback cycles  Pair Programming Ralph and Karsten hackingon E4

  5. Agile Feedback cycles  Test Driven Development

  6. Agile Feedback cycles  Continuous Integration Q: Who iswho?

  7. Agile Feedback cycles • Code Review? • Sometimes formal Code Review (Fagan style inspection) • Pair Programming is considered to be more agile • Higher bandwidth (Faster feedback) • Leads to faster integration than Code Review • “Individuals and interactions over processes and tools”

  8. Agile Software Engineering • Engineering practices are key • SAP trained its developers • > 4000 participants • 1 week training • 3 weeks coaching • Focus on • Scrum • Pair programming • Test Driven Development • Continuous Integration • Acceptance Tests

  9. Code Review in Open Source MaintainerHierarchy / Contributors Public peerreview on mailinglist • Committer / Contributormodel • Public peerreview • Patch in Bugzilla • Gerrit • Github

  10. Code Review vs. Pair Programming

  11. Code Review vs. Pair Programming • Code Review • leads to small, self-contained increments • ensures that ideas can be understood from code • leads to review discussions visible to everybody • leaves room to develop alternative solutions • Ideal complement to Pair Programmingwhich is great to • explore unknown terrain • onboard new developer • combine complementary skills

  12. Code Review is asynchronous • Can be done when there is time • The whole team can review (also external reviewers) • Review takes time, but also leaves time • This leads to parallel workflow • Git perfectly supports this • Some aspects can be automated • Rule checking   • Build and test • Deployment to staging environment • All checks happen before submit

  13. Code Review Best Practices • Small changes are much easier to review • A change should logically do one thing (not many) • No change shall break build or tests • Split big changes into series of digestible changes • - These changes depend on each other • - Last change should switch the new feature on • Commit message should explain Why • - The What should be obvious from the code change

  14. Code Review and Scrum • Successful code review required for a task to be finished • Many Done Criteria already checked during code review • Make review visible on Scrum Board • Reserve time for review • Everybody should review

  15. Code Review and Scrum Scrum Board

  16. Code Review with Git and Gerrit • Gerrit is a Code Review system based on JGit • http://code.google.com/p/gerrit/ • Also serves as a Git server • Adding access control and workflow • Used by • Androidhttps://android-review.googlesource.com/ • Eclipsehttps://git.eclipse.org/r/ • Google, QualComm, SAP, WikiMedia…

  17. Code Review with Git and Gerrit

  18. Code Review with Git and Gerrit Gerrit usage at SAP started 2010 Projects: > 2.000 Users: > 4.000 Changes: > 300.000 Run by a small team of developers (us) Training is important (> 400 developers) Recently Git and Gerrit were approved as standard infrastructure

  19. Scaling Agile with Open Source Processes Agile processesworkgreatforsmallteams • Collaborationbetweenteamsof a large project? • High levelplanningofcrossteamtopics still necessary • Open Source likeprocessescanreplacedetailed top-down planning • Contributetocomponentsownedbyotherteams • Review relevant changesofotherteams • Scale up Pair Programming -> “Hackathons”

  20. Contributions between teams • Find projectinformationeasily • Standardizedinfrastructure • Contributor Guide

  21. Finding project info

  22. Finding project info

  23. Finding project info - Skalli

  24. Standardized infrastructure gitclone <URL> mvn clean install EclipseCBI: http://wiki.eclipse.org/CBI

  25. Contributor Guide Standardized Wheretogetthesources Howtosetuptheproject Howtobuild Review process Communication channels CorrectionProcess Codingconventions Howtotest Review rules … Project specific

  26. Conclusion Code Review brings additional valueto agile teams Gitand Gerrit help a lot Improvescollaboration within and betweenteams Standardizationhelpstoscale

  27. Questions & Answers

  28. Agile Manifesto Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan In a complexandchangingenvironmentfeedbackiskey!

More Related