Code review

[malor]

https://abseil.io/resources/swe-book/html/ch09.html

• Процесс кодогляду
  • сутність практики
  • кількість рецензентів
  • LGTM і "власник" коду
  • інструменти для кодогляду
  • види кодогляду (нові фічі, зміни поведінки, багфікси)
• Переваги кодогляду:
  • коректність змін
  • зрозумілість коду для сприйняття (code comprehension)
  • узгодженність коду (code consistency)
  • росповсюдження знань
  • психологічні і культурні аспекти (cиндром самозванця, робота на "аби працювало хоч якось")
• Недоліки кодогляду:
  • поширені проблеми (https://vgallet.github.io/posts/code-review/)
  • In my experience, code review creates more problems than it solves. Code review is only good when developers work mostly in an asynchronous way and in different time zones. But in most cases, developers are working in the same team, on the same project at the same time and code review is only a way to avoid exchanges with colleagues. Nowadays, code review is a cargo cult.
  • Most of the time code review should be replaced by pair programming or better still ensemble programming (also known as mob programming). In that way, you have at least two people working on the same piece of code and you always have: knowledge sharing, both business and technical knowledge; proof-reading; developing cohesion and team spirit
• Найкращі практики:
  • Ввічливість і професійність
  • Маленькі зміни
  • Хороші описи змін
  • Автоматизація
  • Мінімум рецензентів