O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

It's all about feedback - code review as a great tool in the agile toolbox

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 31 Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

Semelhante a It's all about feedback - code review as a great tool in the agile toolbox (20)

Anúncio

Mais recentes (20)

It's all about feedback - code review as a great tool in the agile toolbox

  1. 1. Code Review as a Great Tool in the Agile Toolbox Matthias Sohn, Stefan Lay (SAP) Matthias.sohn@sap.com, stefan.lay@sap.com Twitter: @masohn @stefanlay
  2. 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. 3. Agile Feedback cycles Source: http://en.wikipedia.org/wiki/Extreme_Programming
  4. 4. Agile Feedback cycles Pair Programming Ralph and Karsten hacking on E4
  5. 5. Agile Feedback cycles Test Driven Development
  6. 6. Agile Feedback cycles Continuous Integration Q: Who is who?
  7. 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. 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. 9. Code Review in Open Source Maintainer Hierarchy / Contributors Public peer review on mailing list Committer / Contributor model Public peer review • Patch in Bugzilla • Gerrit • Github
  10. 10. Code Review vs. Pair Programming
  11. 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 Programming which is great to • explore unknown terrain • onboard new developer • combine complementary skills
  12. 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. 13. Code Review Best Practices - Author Small changes are much easier to review A change should logically do one thing (not many) Split big changes into series of digestible changes - These changes depend on each other - Last change should switch the new feature on
  14. 14. Code Review Best Practices - Author No change shall break build or tests Commit message should explain Why - The What should be obvious from the code change Classify maturity of change: POC, WIP, RFC
  15. 15. Code Review Best Practices - Reviewer Comment everything you observe Classify comments: style nit, optional, can be fixed later, unrelated change
  16. 16. Code Review Best Practices - Reviewer Constructive feedback: Propose alternatives Don’t submit if there are unanswered comments
  17. 17. Code Review Best Practices - Team Self organized team: All team members feel responsible to review Explicit invitations for - specific topics - reviewers from other teams Invited review has high priority Leave enough time for others to review
  18. 18. 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
  19. 19. Code Review and Scrum Scrum Board Story Bug Fix Review Story A Story B Story C … Open In Progress In Review Done
  20. 20. 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 • Android https://android-review.googlesource.com/ • Eclipse https://git.eclipse.org/r/ • Google, QualComm, SAP, WikiMedia…
  21. 21. Code Review with Git and Gerrit
  22. 22. 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
  23. 23. Scaling Agile with Open Source Processes Agile processes work great for small teams Collaboration between teams of a large project? • Contribute to components owned by other teams • Review relevant changes of other teams
  24. 24. Contributions between teams Find project information easily Standardized infrastructure Contributor Guide
  25. 25. Finding project info
  26. 26. Finding project info
  27. 27. Standardized infrastructure git clone <URL> mvn clean install Eclipse CBI: http://wiki.eclipse.org/CBI
  28. 28. Project specific Standardized Contributor Guide Where to get the sources How to setup the project How to build Review process Communication channels Correction Process Coding conventions How to test Review rules …
  29. 29. Conclusion Code Review brings additional value to agile teams Git and Gerrit help a lot Improves collaboration within and between teams Standardization helps to scale
  30. 30. Questions & Answers
  31. 31. 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 complex and changing environment feedback is key!

Notas do Editor

  • Focus on thecorevalue „feedback“Letsfocus on theloops relevant forcoding
  • DirectfeedbackFoureyesprincipleKnowledgetransfer
  • Feedback: DoesthecodewhatisexpectedCode ismostimportantartefactGood designTests asdocumentationGoodtestcoverage
  • Feedback: Doesmychangework after integration?StablebuildEarlyintegration -&gt; solvemergeproblemsasearlyaspossibleBuildpipeline
  • Matthias:Review takesplacebefore a changeisintegrated
  • Often PP isconsideredas a good form of Code Review-&gt; But Real Code Review in OS ismore
  • Code isread 10 timesmoreoftenthanwritten
  • Stefan:Asynchronous?Hu…
  • Value-Stream baseddailyscrum -&gt;talk also aboutreviewcolumnReview columnisfor external reviews (mostlyunplanned) -&gt; Open Source andInner Source
  • Maybe
  • Maybe
  • Maybe
  • StandardizedReleasebuild

×