Mi código funcionaba, pero a pesar de todo bastó una revisión de código para darme cuenta de cuánto podía ser mejorado...

1. Code reviews
Improving as a developer through code reviews

2. I am Anallely Olivares
Backend developer
You can find me at @tsunllly and
anallely.olivares@globant.com
Hello!

3. Mi código puede ser
mejorado y mucho!
Una revisión de código bastó para darme cuenta
11

4. Conocía teoría
◉ Buenos nombres
◉ Funciones: una sola cosa, bien hecha
◉ DRY
Mi código funcionaba, pero a pesar de todo bastó
una revisión de código para darme cuenta de
cuánto podía ser mejorado...

5. Mi peer se tomó la molestia
antes después

6. A partir de esta experiencia empecé
◉ a aplicar ese estilo al siguiente código
◉ a valorar el conocimiento del equipo
◉ a ver como una inversión el tiempo dedicado a
las revisiones de código

7. Elementos de un code review
Hay que conocerlos para realmente sacar provecho de la práctica
12

8. Actors
CODER
● Una sola funcionalidad o aspecto
● Cuidar número de líneas
● Ser claro en el objetivo del
código
● Buenos commit messages
● Pre code review
○ Formato
○ Nombrado de variables
REVIEWER
● Actitud positiva
● Entender el problema a resolver
● Priorizar
● Aportar soluciones

9. Bad / Good commit messages

10. Bad examples
◉ “bug fix”, “more work”, “minor changes”, “ups”, “wtf”
◉ “Work on feature blah blah” x 20
◉ Change X constant to be 10
◉ [PPE-7006] - fix :v

11. Good example (Spring boot)

12. “
Separate subject from body with a
blank line
1/7

14. “
Limit the subject line to 50
characters
2/7

16. “
Use the imperative mood in the
subject line
3/7

17. ● Refactor subsystem X for readability
● Update getting started documentation
● Remove deprecated methods
● Release version 1.0.0
● If applied, this commit will refactor subsystem X for readability
● If applied, this commit will update getting started documentation
● If applied, this commit will remove deprecated methods
● If applied, this commit will release version 1.0.0
● If applied, this commit will merge pull request #123 from user/branch
Close the door!

18. “
Meaningful: Describe what was
done so we can effectively glance
through the history and find what
we need.
?/7

19. Recomendaciones adicionales
◉ Usar una herramienta como JIRA
◉ En los PR/commits podemos agregar ID ticket
◉ No commits sin bug/tarea/historia asociada

20. Estado del arte
Estudios y estadísticas de los code reviews
13

21. Revisar de 200 a 400 líneas / 60 minutos
◉ El cerebro solo puede procesar efectivamente
estas líneas por evento
◉ Después de las 400 líneas el porcentaje de
defectos encontrados disminuye
◉ 200 - 400 líneas en 60 minutos -> 70-90% defect
discovery

22. Es mejor cuando el autor comenta
◉ Antes de iniciar el code review hace anotaciones
de lo que hizo y por qué
◉ Brindan contexto
◉ Commit messages
◉ Se encuentran errores aún antes de empezar

24. Usar checklists
◉ Disminuir errores frecuentes
◉ Organizar prioridades
◉ Recordar omisiones
◉ Se puede ir incrementando con la experiencia

25. Establecer un proceso para la corrección
◉ Recuperar tiempo invertido
◉ Code review tool
◉ Tomarlo en cuenta en el flujo kanban o scrum
◉ Incrementar pruebas unitarias
◉ Historial de bugs

27. Establecer una cultura positiva
◉ Cultura de colaboración
◉ Estar en el mismo contexto
◉ No críticas negativas
◉ Bugs son cosa de todos los días
◉ Mejorar la calidad del código / aprender
◉ Romper malos hábitos
◉ Junior -> Senior

28. Code review es la forma #1 de mejorar la calidad

29. También es la #1 para incrementar la colaboración
◉ Share technique knowledge
◉ Share project knowledge
◉ Mejora la sinergia
◉ Entender procesos mentales

30. Obstáculos para hacer code reviews

31. Beneficios de los code reviews

32. Errores comunes
Encontrados en code reviews de código JS
14

33. “
Functions and objects are passed
as arguments to other functions
without any type validation.

34. ¿Existen?
¿Son del tipo?

35. “
ParseInt without base

36. Be prepared for crazy inputs!!

37. “
Some of the code is heavily
blocking

38. Nominee 1
Nominee 2
Nominee 3
Advocate Screen
October 15, 16:45
Nominee 1
Nominee Screen
October 15, 17:45

39. A listing of blocking code

40. “
You’re testing for explicit numeric
equality of a property using the
== operator, but you should
probably be using === instead

42. “
Using array.length in for loops

44. “
Reduce switch use

46. “
Use elegant ways to build strings

48. “
Say no to hadouken code

50. Code Reviews Checklist
Aspectos básicos y avanzados
15

51. Basics
◉ ¿Se sabe lo que se está revisando?
◉ ¿El código funciona?

52. Basics

53. More basics
◉ ¿Está debidamente comentado?
◉ ¿Variables no usadas?
◉ ¿Logging innecesario?
◉ ¿Las condiciones de paro son correctas?
◉ ¿Funciona en los edge cases?
◉ ¿No hay librerías o código que ya hace esa
función? → filters :(

54. Advanced

55. Unit tests
◉ ¿Existen?
◉ ¿Están probando realmente?
◉ ¿Code coverage adecuado?
◉ ¿Condiciones extremas?

56. Embrace code reviews
Es una forma de aprender y unir
16

57. Cultura positiva
◉ No seas overcrítico
◉ Se realista
◉ No te burles
◉ Se constructivo
◉ Aporta soluciones: pseudocódigo, patches
◉ Soluciones primero, estilo después
◉ No digas algo solo para no quedarte callado

58. Involucra a más personas

59. ◉ 9 Lessons From A Review Of JavaScript Code
https://www.smashingmagazine.com/2011/10/lessons-from-a-review-of-javas
cript-code/
◉ Best Practices for Code Review
https://smartbear.com/learn/code-review/best-practices-for-peer-code-revie
w/
◉ The State of Code Review 2017
https://smartbear.com/resources/ebooks/the-state-of-code-review-2017/?ut
m_source=x-related
◉ How to Write a Git Commit Message https://chris.beams.io/posts/git-commit/
Fuentes

60. Any questions ?
You can find me at
◉ anallely.olivares@globant.com
◉ @tsunllly
Thanks!