Pages Menu
Categories Menu

Posted by on Feb 6, 2015 in General | 1 comment

¿Cómo puede llegar a funcionar esto de la responsabilidad colectiva del código?

En el post de la semana pasada (¿Quién es responsable del código?) comentaba los enfoques de responsabilidad de código que me he encontrado en las empresas.

Y para mí, uno de los mejores ambientes de trabajo en los que he vivido y en los que más he aprendido, ha sido en uno en el que todos éramos responsables de todo el código.

En este caso, la empresa que lo adoptó desarrollaba su propio producto y por su negocio quería orientarse a lo ágil.

Una responsabilidad colectiva de todo el código requiere perder un poco el ego. Es más sencillo en nuevos desarrollos, e implica ganas y un cambio de mentalidad en desarrollos que ya llevan su tiempo y que creen que un enfoque así les aportaría valor.

– Aquí, en vez de enfadarme cuando modifiquen mi código, tengo que alegrarme porque otros han conseguido mejorarlo.

– En vez de imponer mi punto de vista de diseño, hemos de discutir diferentes alternativas y llegar a un acuerdo.

– En vez de encontrar algo que está mal hecho, y dejarlo como está porque no es cosa mía, tengo que dejar el código mejor que como lo encontré.

Esto requiere un compromiso en el equipo. No solo arreglar el código que esté mal, sino que al escribir código nuevo, lo programe de la mejor forma que sepa.

¿Y qué pasa si no conozco el código? ¿Cómo hago para que también sea mío?

En muchas ocasiones hay ciertas partes de código que solo las conocen unas pocas personas de la empresa. ¿Si no conoces el código, cómo vas a ser responsable de él? ¡Si puede que por un mal entendimiento lo rompas!

Para solucionar esto, aprovéchate del pair programming. Para mí es una técnica muy buena, y que me ha servido muchísimo para mejorar la forma en la que desarrollo, saber cosas nuevas, etc.

Consiste en que programes colaborativamente con otra persona, en este caso con más conocimiento que tú, para que te vaya aconsejando y resolviendo tus dudas, y así aprendas de ella.

Cuando alguien coja una tarea que implique código que no entiendes, sal voluntario para hacer pair programming con esa persona.

Pregunta dudas, e incluso, cuando termines de desarrollar algo sobre lo que no estés seguro, que alguien te revise el código, lo que se llaman peer reviews.

Por otra parte, refactorizando el código también puedes aprender sobre el software.

Si además tienes una batería de pruebas unitarias, una plataforma de integración continua con pruebas automáticas o buena documentación actualizada, confía en ellas para entender qué hace el código.

Si no tienes nada de esto, cualquier momento es bueno para empezar poco a poco.

Piensa que si todo el código tiene mala calidad, no hay pruebas unitarias ni nada, y sois un equipo considerable, pequeñas mejoras constantes de cada uno al final supondrán una mejora muy grande.

¿Y cómo esta actitud me beneficia como desarrollador?

Piensa que todo el código es tuyo, con lo que puedes mejorarlo y aportar nuevas ideas y soluciones. ¿Has aprendido una nueva tecnología que crees que os ahorraría sufrimiento y tiempo? ¿Podrías mejorar el diseño de ciertas clases? ¿Crees que existen otras librerías mejores que las que utiliza una parte del código?

Además, aunque seas un gurú de algo específico, por ejemplo, de base de datos, aquí no tienes por qué solo escribir código de base de datos en el proyecto. Si te apetece escribir un poco de código de interfaz de usuario sencillo, encuentra alguien con quien hacer pair programming e ir aprendiendo.

Así se promueve que no tengas por qué trabajar siempre en lo mismo. Y aprender un poco de todo es bueno a la hora de mejorar tu CV.

Por otra parte, si todo el mundo es responsable de todo el código, cualquiera puede hacer cambios ya que aunque sea experto en una materia, tiene conocimiento general de toda la aplicación. Con esto evitamos que personas concretas tengan que acarrear siempre la responsabilidad de arreglar un bug en una parte de código que ha escrito. Al difundir el conocimiento entre los miembros del equipo, cualquiera podría hacerlo.

Ana M. del Carmen García Oterino

Ana M. del Carmen García Oterino

Ingeniera Software QA at BQ
https://www.linkedin.com/in/amgarciao

Apasionada por la calidad del software (procesos, producto y equipos) y buenas prácticas en general.

Especializada en testing, automatización de pruebas e integración continua.
Ana M. del Carmen García Oterino

1 Comment

  1. Esta filosofía de trabajo es excelente, es un “ganar todos”. Yo he vivido situaciones en las que por ejemplo, el proceso de extracción de datos para generar un informe estaba tan “parcelado”, que una sección concreta de un programa era “mía”, y el resto era “de otro equipo”; siempre me pareció absurdo.

Post a Reply

Tu dirección de correo electrónico no será publicada.

Share This