Your SlideShare is downloading. ×
Code review
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Code review

13,620
views

Published on

Многие жалуются на качество кода, автоматизированных тестов или продукта в целом, на количество ошибок, найденных конечными пользователями или отделом тестирования. Почему это происходит? Необходимо …

Многие жалуются на качество кода, автоматизированных тестов или продукта в целом, на количество ошибок, найденных конечными пользователями или отделом тестирования. Почему это происходит? Необходимо понимать, что для того чтобы не допустить подобных ситуаций требуются дополнительные усилия – необходимо следить за качеством кода и работать над его улучшением.

Code Review является одной из наиболее полезных и эффективных практик для ранней борьбы с дефектами в коде и повышению его качества. Использование Code Review на различных этапах разработки, начиная от дизайна и заканчивая написанием кода и тестов, помогает построить ранний цикл обратной связи и избежать потерь времени в будущем на исправление ошибок.

Дополнительным преимуществом применения Code Review является распространение знаний между членами команды и адаптация других командных подходов. Данная практика может быть интересна любому члену команды вне зависимости от его роли в проекте.

В докладе будут рассмотрены основные аспекты Code Review, способы проведения, инструменты и техники. Также будут продемонстрированы основные ошибки в использовании этой практики, полезные советы, приемы по внедрению и поддержке.

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
13,620
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
13
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Спецотряд
  • Так, что-то я не понимаю, что ты проверяешь этим тестом.
  • Строчки дока, количество найтденных ошибок, ....
  • Aleksey: before in most cases because of trunk should contain only good code.
  • Есликоднепроходитревьювторойраз, тоонсчитаетсяопасным и ревьювитсяещекем-тоЕслизамечанияпростые, тоониисправляются в паресразуприревьюЕслизамечанийоченьмного, тоониразбиваютсянаполноценныезадачичтобынезатягиватьЕсликоднепрошелревьювовторойраз и естьсерьезныезамечания, тоонобязательноделается в пареРевьюсчитаетсямаксимальнымприоритетом, нонепрерываеттекущейзадачи (ждемперерыва)Задачанеможетпровисетьнаревьюдольшечемдоследующегодэйлискрама 
  • Transcript

    • 1. How to improve quality of the product using “code review”
      Mikalai
      alimenkou
      Aleksey
      solntsev
    • 2. Alimenkou Mikalai
      Java Technical Lead/Scrum Master at Zoral Labs
      6+ years in software development
      4+ years of working by Agile methodologies
      Expert in Agile engineering practices
      Agile coach at XP Injection
      Solntsev Aleksey
      • Process Architect at Infopulse Ukraine
      • 3. Agile volunteer
      • 4. Certified Scrum Practitioner
      • 5. Initiator and coordinator of translation of the cult book "Scrum and XP from the Trenches" into Russian
      • 6. Agile coach at XP Injection
    • Agenda
      Introduction and common principles
      WhyCode Review works?
      WhyCode Reviewcouldn’t work?
      How to find reviewer?
      Practices, metrics, tips and tricks
    • 7. Where is quality better?
    • 8. Goals of code review
      • Improve quality of code
      • 9. Share knowledge
      • 10. Improve collective code ownership
      • 11. Check conformance
      • 12. Verify completeness
      • 13. Educate
      • 14. Reach a consensus
      • 15. Try other approaches
    • Classification
      Less formal
      Most formal
    • 16. Common principles: roles
      Third persons
      A reviewer
      An author
    • 17. 3
      main reasons why code review works
    • 18. Two pair of eyes are better then one
    • 19. «Teddy bear» effect
    • 20. Common denominator
    • 21. reasons why code review couldn’t work
      3
    • 22. Interpersonal conflict
    • 23. “Ego” effect
    • 24. Too bored procedure
    • 25. 7
      strategies how to choose a reviewer
    • 26. 1. «Daddy at home»
    • 27. 2. «Help yourself»
    • 28. 3. «Review contract»
    • 29. 4. «Control center»
    • 30. 5. «SWAT»
    • 31. 6. «Everybody dance»
    • 32. 7. «Adulterous relationship»
    • 33. 2
      ways to drivecode review
    • 34. 1. ATR (Author driver review)
      Yep, yep
      I’ve added a couple of new interfaces. There are the implementation.
      A reviewer
      An author
    • 35. 2. RTR (Reviewer driven review)
      Hmm… I don’t understand what you try to verify using
      this test.
      Actually, I’m also a little bit confused …
      A reviewer
      An author
    • 36. 7
      answers you shouldknow
    • 37. What should we start with?
      A reviewer
    • 38. What to review?
      Look at code changes/differences
      Review whole solution
      Identify methods/functions and classes
    • 39. How to organize code review?
      Use changes package (email, patch, etc.)
      Use separate branch in VCS
      Use distributed VCS
      Code exchange tools built in IDE
      Specialized instruments
    • 40. How to organize code review?
    • 41. Should we use metrics?
    • 42. How long?
      60
    • 43. Fast or slow?
      500
    • 44. Big or small commits?
      400
    • 45. How to start?
      1. Make common decision
      2. Start slowly
      3. Select only the most
      problematic modules
      4. Inspect and adapt
    • 46. 8
      tipsand tricks
    • 47. Before or after check-in?
    • 48. Track reviewers
      • Not for blame
      • 49. Easy to find person who also knows the code
      • 50. More responsibility for reviewer
    • Checklist – make your live easier
      Has error handling code been tested?
      Are objects accessed by multiple
      threads thread-safe?
      Are variables initialized before
      they are used?
    • 51. Comfortable conditions for reviewers
    • 52. All rules should be on WIKI
    • 53. Use pen and paper
    • 54. Use static code analysis
    • 55. Easy, tiger, easy
    • 56. And what …
    • 57. Books
    • 58. Q&A
      Email us:
      mikalai.alimenkou@xpinjection.com
      aleksey.solntsev@xpinjection.com