March 26, 2020
Revisiones de código efectivas
Single-responsibility principle es, sin duda, uno de los principios de diseño de software que más me gusta. Aplica muy bien a un montón de escenarios, tanto a escala "micro" (funciones, clases) como "macro" (arquitectura, microservicios). Si estáis lidiando en un escenario donde las pull requests son, habitualmente, más grandes de lo que os gustaría y por tanto, necesitan de mucho tiempo para ser revisadas (convirtiéndose casi accidentalmente en cuellos de botella) os ánimo a probar la aplicación de SRP.
¿Cómo encajaría en este contexto? A mí me gusta enunciarlo de la siguiente manera:
Una pull request debe contener cambios relacionados con una única responsabilidad.
Como veis, dentro del enunciado anterior, tendrían cabida code reviews con multitud de cambios pero (y este pero es importante) siempre y cuando estén relacionados con una única responsabilidad. Y es que, en la práctica, la complejidad a la hora de revisar una pull request no está tanto relacionada con el número de cambios, sino con el volumen de responsabilidades que están siendo cambiadas a la vez (es decir, un renaming por aquí junto a un cambio en el código de esta función por allá).
Como ejemplo, uno de los sospechoso habituales de generar un montón de cambios: renombrar un método, clase, etc. Si este cambio se traduce en una única pull request, estaremos facilitando mucho la vida de la compañera que tenga que revisar nuestro código ya que todos los cambios están relacionados con una única responsabilidad y sólo deberá poner el foco en garantizar que la acción se haya hecho correctamente (¡imaginad que, además, tuviera que validarlo junto a otro montón de cambios de diversa índole que acompañen a la pull request!).
La complejidad a la hora de revisar una pull request no está tanto relacionada con el número de cambios, sino con el volumen de responsabilidades que están siendo cambiadas a la vez.
Conseguir un flujo así implica que tengamos que quitar de nuestra cabeza la idea de que 1 feature equivale a 1 pull request y eso es algo que sólo podemos conseguir si desacoplamos nuestro repositorio de nuestra estrategia de entrega de software.
Por supuesto, todos los consejos habituales sobre cómo realizar buenas revisiones de código aplican también con este enfoque (y si queréis un repaso completo sobre cómo realizar la pull request perfecta, os recomiendo esta charla de Patricia Gao).