¿Quién es responsable del código?

El código fuente, es la base sobre la que los profesionales de la informática trabajamos diariamente. Esa base que en función de lo bien que esté hecha (hablamos de calidad del código, buen diseño, etc.) nos permitirá trabajar más cómoda y rápidamente, o nos quemará y frenará nuestra productividad.
Todos en algún momento hemos vivido malas experiencias relacionadas con el código en sí:
– sitios en los que se desarrolla rápido para que funcione algo ahora mismo, pero no con la calidad con la que debería hacerse;
– código que nadie entiende;
– situaciones en las que llega un momento que de no controlar la calidad del software, hay que parar el desarrollo y refactorizar módulos enteros;
– yo desarrollo mi código, y si tiene bugs son responsabilidad mía, pero cuando la funcionalidad está en producción mi trabajo ha terminado;
– ¿para qué voy a refactorizar, hacer pruebas unitarias, meterme en ese jaleo, si nadie más se preocupa por ello?
– yo limpio lo mío, pero lo de los demás no. No me pagan por ello.
En estos casos, ¿quién es el responsable de asegurarse de que todo vaya bien? ¿Quién es responsable de definir estándares de calidad y ver que se cumplan?
Puede parecer una tontería, pero creo que tener esto claro es muy importante en un equipo software.
Hablamos de definir unas pautas, un orden, para que un grupo más o menos grande de personas pueda trabajar coordinado sobre una misma base de código. Algo del día a día, como la estrategia de control de versiones, las promociones entre entornos de desarrollo, los flujos de trabajo, etc.
He vivido y visto falta de motivación, y gente muy quemada por optar por un modelo de responsabilidad de código erróneo.
Estar en un entorno de trabajo en el que todo el mundo se echa las culpas el uno al otro, e intenta “librarse” de realizar mejoras, no es sano.
Y con esa mentalidad es complicado desarrollar software de calidad.
La calidad del software no es algo que se consiga de la noche a la mañana, con una refactorización enorme y milagrosa. Es mucho más efectiva una constancia colectiva, ya que de la otra manera, pondremos un parche y volveremos a la misma situación inicial tras unos meses.
Por el contrario, también he vivido buenas experiencias. Sitios en los que la forma de trabajo y responsabilidades estaban perfectamente definidas, facilitando enormemente el día a día de desarrollo, en un ambiente más feliz.
Así que, para definir responsabilidades, párate a pensar: ¿quién va a trabajar en qué código? ¿cuánto trabajo puede repartirse entre los miembros del equipo? ¿quién será responsable de la calidad del código?
El enfoque que se tome impactará en el rendimiento y éxito del equipo a corto plazo, y a largo plazo impactará en la calidad del código del producto que desarrolléis.
Normalmente, al hablar de responsabilidad de código me he encontrado 4 posturas:

1 – “Nadie en concreto es responsable del código, yo solo hago lo que me obligan a hacer.”

Aquí yo hago las funcionalidades que me piden, y si surgen errores relacionados con lo que he desarrollado los soluciono.
Una vez que ha pasado el tiempo y hay que mejorar la calidad, el diseño y demás, que lo haga quien le toque. El miembro del equipo al que el jefe obligue a hacerlo.
Siento decir esto, pero esta es la peor actitud que se puede tener, la que he visto que más desmotivación produce en un equipo.
En este caso, el código suele ser un campo de minas. Con esta mentalidad, olvídate de calidad en el software.

2 – “La responsabilidad sobre una pieza de código es de quien la ha desarrollado.”

En este modelo, en cada módulo hay que indicar qué desarrollador lo ha hecho. Dicho desarrollador, mientras que esté en la empresa, es el “dueño” de ese módulo, de tal manera que cada desarrollador solo puede modificar el código que ha creado.
Si alguien necesita cambiar el código de otro, tiene que hablar primero con el dueño del módulo y que el dueño dé el visto bueno a esa solución.
Esto no solo pasa a la hora de refactorizar el software, sino también si la funcionalidad que alguien está desarrollando requiere cambiar el comportamiento de un módulo de otra persona.
Aquí la calidad del código tiende a ser mejor, es cierto, ya que cada módulo tiene nombres y apellidos y al desarrollador le puede dar muy mala imagen que le asocien a un código pésimo.
El problema que le veo a este enfoque son las dependencias tan fuertes que existen entre desarrolladores.
Primero está el retraso que supone tener que buscar al dueño del módulo cuando tienes que cambiar algo. Después, que solo la persona que desarrolla un módulo sabe cómo funciona.
¿Qué pasa si esa persona que conoce una parte crítica de la aplicación se va de vacaciones? ¿Se pone mala? ¿O simplemente se va de la empresa?
¿Cuánto tiempo vas a perder formando a una persona que lo haga igual de bien que ella?
Además, los errores que aparezcan relacionados con ese módulo solo puede resolverlos el dueño del código.
Imagina que hay gente en la empresa que lleva desde que se inició, con lo que la mayor parte del núcleo de la aplicación es suyo. ¿Solo esas personas conocen el núcleo de la aplicación? ¿Todos los errores que se encuentren recaerán sobre ellas, mientras que el resto de desarrolladores pueden estar ociosos?
Por cosas de este tipo, la gente acaba quemándose y marchándose de la empresa.

3 – El dueño del módulo solo revisa y vigila su calidad. Cualquiera puede realizar modificaciones.

En este caso, los módulos siguen asociados a personas concretas, pero cualquier desarrollador puede modificar el código de otro.
Es responsabilidad de los dueños echar un vistazo a los cambios que hacen otras personas, responder sus dudas y controlar la calidad del código del módulo.
Por otra parte, la gente que modifica código que no es suyo debe comentárselo a los dueños y preguntarles dudas.
No he trabajado con este modelo, pero creo que podría ser algo bueno por lo que empezar, intermedio entre la postura 2 y 4 (que explicaré a continuación).
Este enfoque es ideal si en tu equipo hay programadores juniors o con menos experiencia. Tienen libertad para modificar cosas, pero les ayudan y revisan la calidad para que vayan adquiriendo experiencia y mejorando como profesionales.

4 – Todo el mundo es responsable de todo el código.

En mi opinión, este es el pensamiento más ágil, la cultura interna que consigue mayor calidad de código. Y he participado en situaciones en las que se ha conseguido esta cultura de equipo.
Aquí el código fuente es responsabilidad de todo el equipo, y todo el mundo puede cambiar y refactorizar lo que otros han realizado. La calidad del software es responsabilidad de todo el mundo. Todo el equipo es responsable de entender el software a alto nivel y de su calidad del código.
Esto no significa que otra persona sea responsable de tu código. Significa que tú como desarrollador eres responsable de todo el código (al igual que el resto del equipo).
Si encuentras código repetido, nombres que no se entienden, código mal diseñado…no importa quién lo escribió. El código es tuyo. Si tienes una mejor solución, es tu deber proponerla y mejorar el software.
Obviamente esto requiere buena comunicación en el equipo, y prácticas como la Integración Continua, con pruebas automatizadas, ayudan muchísimo para adquirir esta cultura.
Además de compromiso de todo el equipo: no solo mejorar el código de los demás, sino programar soluciones con la mejor calidad posible.
—
Ahora, te preguntarás, ¿cómo puede llegar a funcionar la responsabilidad colectiva sobre el código? ¿podemos aplicarla siempre? ¿qué técnicas la fomentan? El viernes que viene hablaré sobre ello.