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.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Yo creo que lo mejor es la opción es una variación de la 3. Vamos, que un HEAD (como se llama en los países anglosajones), lo revise todo y poco a poco vaya educando al resto. Porque para mí el 4 parece una anarquía, o al menos lento para tomar decisiones.
Cambiando de tema, ¿qué hacer cuando prácticamente todas las empresas caen en el 2 y en el 3? O sea, que les da igual la calidad, solo escurrir el bulto y hacer software basura, que mientras cobren… Normal que los técnicos buenos acaben hasta las narices y se vayan. Creo que la raíz es lo desorganizados de nuestra naturaleza.
Yo también creo que la 3 es bastante buena, fomentar las revisiones de código, programación por pares y que ciertas personas vayan mentorizando al resto.
Incluso para tirar hacia el 4 partiendo del 1 o 2, recomendaría empezar por el 3.
El 4 si que es más costoso de alcanzar, porque necesitas que más o menos el equipo esté al mismo nivel. Pero lo veo más rápido, como desarrollador no dependes del resto para hacer cambios. Eso sí, para lograrlo es muy recomendable tener una plataforma de integración continua y ciertas pruebas automáticas.
Yo soy partidaria de mezcla de 3 y 4: por ejemplo, que las decisiones importantes que afectan a todo el diseño del software estén consensuadas por todos, revisadas por los head que comentas, y el trabajo de la gente más junior también.
Y lo que dices de pasar del 1 o 2 a otro modelo, yo creo que al final es cuestión de que alguien quiera cambiar:
– que un grupo de gente esté hasta las narices y quiera cambiar la situación.
– que entre gente nueva, con otras ideas y con ganas de cambiar las cosas.
– o que los «jefes» se pongan alerta porque la gente se va, llega un momento en que los resultados no son buenos y todo el conocimiento del software está concentrado en ciertas personas (que puede que también se quemen y se vayan de la empresa).
Y en ese punto por presión de un grupo grande de gente hacia puestos más arriba de la empresa, o de arriba hacia abajo, se decide poner solución al asunto.
Yo creo que para pasar de una situación de escurrir el bulto y hacer software de mala calidad a algo mejor, el grupo de gente tiene que ver que cambiar esa situación va a ser una mejora para ellos: a nivel de forma de trabajo, de tranquilidad, de no tener que salir más tarde buscando por qué fallan cosas a última hora etc.
Y todo esto también depende del tipo de empresa que seas:
– si desarrollas tu producto, esto va a ser algo primordial, ya que al final tendrás que mantener el software.
– si eres una empresa de desarrollo subcontratada…al final dependerá de la calidad que te exija el cliente. Aquí es más complicado…si no les pagan más por hacer las cosas bien, o el cliente no les exige unos mínimos…es complicado tirar hacia otro modelo.
Donde dije 2 ó 3 quería decir 1 ó 2.
Cuánto más lejos estés de la 4 más inmaduro es tu equipo. Cuánto más inmaduro sea el equipo más desmotivación se generará con el tiempo y por supuesto peor calidad tendrá e irá teniendo con el paso del tiempo.
Él sólo hecho de plantearse que el código tenga un responsable con nombres y apellidos ya es un mal síntoma.
Otra cosa es que un código tenga un creador mayoritario, de modo que cuando otro desarrollador va a modificarlo pueda considerar apropiado pedir ayuda. Pero sólo en caso necesario y nunca pedir permiso.
Todo también depende de los escenarios con los que te encuentras. A veces las estrategías deben ser pensandas analizando tu situación actual. En caso tengas desarrolladores con muy buen nivel y otros con un menor nivel de conocimiento, se podría aplicar el número 3. Para que los que tienen mayor conocimiento empiecen a entrenar a los de menor nivel. Y así depende del escenario que tengas en tu empresa.
Saludos