Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Code Review and other aspects of project organization

136 views

Published on

Code Review - a case study of SAOS (Court Judgment Analysis System)

Published in: Software
  • Be the first to comment

  • Be the first to like this

Code Review and other aspects of project organization

  1. 1. Code Review and other aspects of project organization – a case study of SAOS (www.saos.org.pl) Łukasz Dumiszewski, ICM, University of Warsaw, XI.2014
  2. 2. Plan of the presentation  Code Review – theory  Code Review in SAOS  Conclusions Duration: about 1h Helpful knowledge: git, GitHub (at least superficial)
  3. 3. Code Review - definition From wikipedia: Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software.
  4. 4. Code Review – pros  Fewer errors  Better code design  Code standardization (tests, comments)  Code clarity (division into sections, sensible variable names, short methods)  Code and meaning of every module known to everyone  Improvement of programming skills  Better team collaboration
  5. 5. Code Review – cons  Longer time of functionality delivery (but maybe it only seems so)  Negative emotions (arguments, creator’s ego hurt)  Revising someone else’s code may be dull/ frustrating
  6. 6. Code Review – different approaches  Formal code review  Lightweight code review
  7. 7. Code Review – formal Formal code review Meetings, line-by-line code inspection by the whole team Pros: Better code: cleaner, fewer errors, sensibly designed Cons: Takes long time, possible negative emotions
  8. 8. Code Review – lightweight Lightweight code review over-the-shoulder/ e-mail/ tool-assisted/ pair-programming Pros: Better code: cleaner, fewer errors, sensibly designed and takes less time than the formal method Cons: Some time still needed, negative emotions can also appear
  9. 9. Code Review – good practices Smart Bear http://smartbear.com/SmartBear/media/pdfs/best-kept-secrets-of-peer-code-review.pdf http://smartbear.com/SmartBear/media/pdfs/WP-CC-11-Best-Practices-of-Peer-Code- Review.pdf 1. Review fewer than 200-400 lines of code at a time 2. Aim for your inspection rate of less than 300-500 LOC/hour 3. Take enough time for a proper, slow review, but not more than 60-90 minutes. 4. Authors should annotate source code before the review begins. 5. Establish quantifiable goals for code review and capture metrics so you can improve your processes. 6. Checklists substantially improve results for both authors and reviewers. 7. Verify that defects are actually fixed! 8. Managers must foster a good code review culture in which finding defects is viewed positively. 9. Beware the “Big Brother” effect. 10. The Ego Effect: Do at least some code review, even if you don’t have time to review it all 11. Lightweight-style code reviews are efficient, practical, and effective at finding bugs.
  10. 10. Code Review in SAOS – what is SAOS? SAOS is an online Polish Court Judgment Analysis System that gathers judgment data from different indpendent court applications, and allows for searching, browsing and analysing the data through the web user interface or RESTful API. See: www.saos.org.pl www.github.com/CeON/saos
  11. 11. Code Review in SAOS – motivation  Pluses as mentioned before  Wish to familiarize ourselves with CR practices  Wish to see if it really works
  12. 12. Code Review in SAOS – technique  Methodology: Scrum  Approach: Lightweight / tool-assisted /  Tool: GitHub pull requests
  13. 13. Scrum methodology – short definition Iterative and incremental agile methodology of managing product development. In this methodology the development of a product is divided into smaller consecutive iterations; lasting max one month, called sprints.
  14. 14. The Scrum methodology in SAOS  One week sprints  Daily scrum meetings  Summing up the previous day  Plans for the next  Weekly sprint meeting  Summing up the sprint  Choosing tasks for the next week  Assigning CR partners to one another
  15. 15. The Scrum methodology in SAOS – details  Tasks and sprints are GitHub’s issues and milestones  Each task takes max 2 days  While planning a sprint the time for the Code Review (20%) is taken into account  Code Review has the highest priority (so the colleague doesn’t have to wait)  Every task must pass the Code Review The 4 lasts points are preconditions of successful CR
  16. 16. Lightweight CR in SAOS – core principles  There is not ‘commit’ without CR  Rotation of CR partners  CR has the highest priority  One CR for one task  And… we take it seriously
  17. 17. Lightweight CR in SAOS in practice 1. Review fewer than 200-400 lines of code at a time One CR for one task and each task is short (no more than 2 days) 2. Aim for your inspection rate of less than 300-500 LOC/hour Depends on the programmer, generally met. 3. Take enough time for a proper, slow review, but not more than 60-90 minutes. 20% of time devoted to CR. 4. Authors should annotate source code before the review begins. We don’t do it. 5. Establish quantifiable goals for code review and capture metrics so you can improve your processes. We don’t do it. Better tool needed. 6. Checklists substantially improve results for both authors and reviewers. https://github.com/CeON/saos/wiki/Code-review#the-code-review- common-checklist
  18. 18. Lightweight CR in SAOS – in practice cont. 7. Verify that defects are actually fixed! Met. A task is not accepted until all remarks are closed. 8. Managers must foster a good code review culture in which finding defects is viewed positively. CR is just one of the tasks. Finding bugs is considered to be a positive characteristic, every bug corrected is one step to closer to perfection. They who make not mistakes make nothing  9. Beware the “Big Brother” effect. We know each other’s skills. This is a code review and not a code writer review. 10. The Ego Effect: Do at least some code review, even if you don’t have time to review it all More time devoted to code clarity, checking the test coverage. 11. Lightweight-style code reviews are efficient, practical, and effective at finding bugs. Some bugs avoided. More in the conclusion.
  19. 19. GitHub pull requests - definition GitHub functionality that allows to compare and see the code differences between two branches or repositories. Main features:  Preview of changes (all or a selected commit)  Commenting on changes  Statuses (closed, open)
  20. 20. GitHub pull requests - approaches  Fork repository model A programmer works on a cloned repo. They are not permitted to make changes in the main repo – some designated people may do this. OK for large teams or open-source projects.  Shared repository model Everybody works directly on the main repo. New functionalities are developed on separate branches. OK for small teams.
  21. 21. GitHub pull requests – fork repository model Repo Repo clone Local Repo LOCAL Pull Request REMOTE (gitHub) Pull Pull/ Push
  22. 22. GitHub pull requests – shared repo model Description of this process: https://github.com/CeON/saos/wiki/Code-review LOCAL Pull Request REMOTE (gitHub) Push master feature master feature Repo Repo 1 2 3 4 5 6
  23. 23. Code Review in SAOS - observations  CR only makes sense if the team treats it as part of its responsibilites (motivation, strict rules)  CR takes time, about 20%, 1 day a week  Minor problems with starting a new task can occur if the task is related to another one just passed to CR  To a high degree CR relies on a reviewer’s skills, their knowledge of a given domain.  Tasks have to be short (we decreased the max time for a task from original 3 to 2 days, to make it shorter and thus easier to revise)
  24. 24. Code Review w SAOS – observations cont.  No significant problems related to negative emotions occurred. Some positive ones have: „I have learned something new”, „I didn’t know you can do it this way” or „It’s good to know somebody will take a look at this.”  The pros listed at the beginning of the presentation proved to be true. In particular: code standardization, observance of rules (writing tests etc.), familiarity of each programmer with the whole code.
  25. 25. Code Review in SAOS – observations cont.  The time devoted to CR has not been wasted, it has paid off (cleaner, faster & easier to extend and more reliable code; programmers know the whole system)  In the longer term CR has had very positive influence on the team collaboration and programmers’ skills.

×