Revision de Código

 La revisión de código es una actividad desarrollada por un actor diferente al autor del mismo y que es un prerrequisito para que el código llegue a usarse en producción.

Esta es mi experiencia hasta ahora con esta actividad.

Motivaciones

La documentación al respecto no necesariamente menciona estas motivaciones. Son las que he podido ver en mi experiencia personal.

Control Social

La revisión de código cuando es realizada por un superior con objetivo de aprobar/desaprobar el trabajo de su subordinado es meramente una herramienta de control social. Esta motivación tiende a ser enmascarada usando otras y no aporta al producto final.

Control de la Calidad

La revisión de código, cuando es realizada por un par del autor con el objetivo de evaluar desde otra perspectiva, es una herramienta de control de la calidad del producto.

Algunos aspectos de la calidad del código que se pueden beneficiar de la revisión son:

  • legibilidad
  • mantenibilidad
  • cohesión, consistencia
  • reducción de errores en producción (4 ojos ven más que 2)

Compartir Conocimiento (evitar fallas de punto único)

  • (la persona menos familiarizada con el código existente revisa el código de una persona muy familiarizada con este)
  • Mentoría (se revisa el código de la persona menos familiarizada con el código existente)

Críticas:

  • Requieren Tiempo (impacto en el tiempo que demora un cambio en llegar al cliente)
  • Incrementan los Cambios de Contexto (revisar el código tiene más prioridad que escribir código, evitar bloquear al revisado)
  • Posible Des-balance de Responsabilidad (si el peso de revisar el código recae sobre una persona).

(Falsas) Críticas:

  • Posible Daño Emocional al recibir una crítica (si alguien en tu equipo no acepta una crítica constructiva o alguien en tu equipo emite criticas que no son constructivas, tienes un problema social, no de revisión de código).

Elementos en Contra

Existen elementos que trabajan en contra de que la revisión de código sea efectiva:

  • el cambio al código es muy grande, lo que lo hace difícil de revisar.
  • existe un plazo a cumplir en la revisión de código, lo que puede influir en la calidad de la revisión en si misma.

Comments

Post a Comment

Popular posts from this blog

Mis Practicas Profesionales - Acerca de las Pruebas

 Recientemente, mis prácticas profesionales han sido puestas a análisis por mis pares y siento que deberia ofrecer un contexto y los criterios que me han guiado hasta aquí. Voy a comenzar tratando las pruebas. Aquí va: Creo que la evolución actúa como una fuerza natural sobre todo lo que hacemos. De ahí que mi práctica profesional ha evolucionado con el tiempo. Lo que voy a describir puede que deje de hacerlo o que lo adapte en un futuro. En mi experiencia pasada los productos se han desarrollado o modificado para alcanzar objetivos económicos: ya sea la realización de una ganancia o la eliminación de un gasto. Este para mí es el vector de selección natural de mis prácticas profesionales. Es el lente a través del cual me analizo en retrospectiva continuamente. Hablemos en términos simples. Hablemos de implementar una nueva funcionalidad en un producto existente. Esta nueva funcionalidad responde a una necesidad del cliente objetivo del producto. Para mí esto requiere que antes de entre
Read more

Mi aproximación al diseño de APIs RESTful

El diseño de APIs siguiendo el estilo arquitectónico REST es tema de debate constante en la red. Existen innumerables publicaciones sobre el tema tanto post personales como artículos respaldados por organizaciones. Separar la paja del grano en este tema es difícil dado que la fuente canónica de información son documentos académicos. Me encantaría leer algo mas aterrizado a la práctica del mismo Roy Fielding pero respeto su compromiso con la comunidad y su incansable trabajo en los procesos de estandarización. En este post voy a compartir con ustedes mi propia aproximación al problema. La parte en negritas sería la descripción necesaria de la API. El caso de estudio para este post será la clásica aplicación de Cosas Por Hacer . Lo primero es modelar el recurso Cosa Por Hacer o Todo como se le conoce en Ingles. Aquí vamos a asumir que es algo tan simple como que tiene 2 atributos: el titulo y la bandera de completado. Lo segundo sería identificar las acciones y el posible flujo de
Read more

My take on Time Series Database requirements

Some time ago, doing some research related to my current work, i stumble upon this excellent article by Baron Schwartz on the topic of Time Series Database requirements. This article is in my opinion the best thing on my reading list for that subject and in this post i will try to expose my own take on this matter building on top of it. Definition of Data Type Baron identify series using two elements: source identifier and metric identifier. I have seem this used on existing products, but from my perspective this is needed for organization purposes and not for series identification. For me the only hard requirement on this matter is that series can be uniquely identified. Therefore a single series identifier is sufficient. You can always provide organization using some kind of namespacing over identifiers (consider the following identifiers “source1.metric1” and “source1.metric2”) or using an independent component to build the relations between series and other elements (groups, a
Read more