Yo y el monstruo del código Legacy

Posted on by

Como muchos sabréis desde mediados de febrero he empezado una nueva aventura de la mano de Lifull Connect, más concretamente formo parte del programa de Apprenticeship impartido por Cokaido. 

El programa maneja tanto Hard Skills como Soft skills, aunque hoy me centraré en las primeras ya que están haciendo que me replantee mi visión de lo que es “Código de calidad” desde el primer día.

Casi por casualidad cuando comencé en el desarrollo de software, mi perfil fue enfocándose cada vez más en el mantenimiento de aplicaciones o gestión de código Legacy. Este inusual comienzo profesional creó en mi inquietudes que no veía en el resto de mis compañeros, 

¿Por que este código no tiene una mínima documentación ? 

¿No creéis que poner un nombre entendible en las funciones y variables hará el código más fácil de interpretar?

¿No hay test implantados, si no añadimos esta parte no creéis que pueden dejar de funcionar otras partes de la aplicación cuando hagamos cambios?

Sin querer fui enfocándose hacia la calidad del código, me convertí un poco en la tía pesada que cuando le tocaba  “reparar” un error intentaba dejarlo todo lo mejor posible. Pronto me di cuenta de que eso no era valorado en las empresas. No le daban importancia a que el código fuera sostenible, sino que se buscaba solventar el error o ampliación lo más pronto posible. De hecho el invertir tiempo en este tipo de cosas me penalizaba por que me hacía más lenta que mis compañeros.

Poco a poco comencé a amoldarme a esta manera de trabajar, solo invertía tiempo en refactorizar el código cuando me “sobraba” tras resolver el problema. Lo que obviamente no dejaba de ser una gota de agua en un océano, así que sin quererlo, generaba más código legacy aun intentando no hacerlo. 

Con el paso del tiempo me volví una experta en reconocer el código de la gente, solo con ver la nomenclatura que utilizaba, qué técnicas implantaba o cómo de sencillo o complicado era su código, ya sabia quien lo había creado. En ese momento también descubrí una “figura o ser” que me acompañaría durante toda mi carrera profesional “El Experto o Gurú”.

Cuando veía todo en una línea de código, funciones con mucha recursividad anidada, clases con dependencias imposibles o simplemente trozos de código que me parecían un galimatias en alguna lengua muerta, sabía que me había encontrado con él. Solía ser un empleado que llevaba trabajando en la empresa muchísimos años y que su forma de hacer las cosas no había evolucionado nada durante este tiempo, también era al que se recurría porque solo él entendía su código y podía explicar a los que veníamos detrás por que se hacían las cosas así o cómo funcionaba. 

Al principio me alucinaban sus conocimientos, y pensaba que me gustaría tener su experiencia o capacidad, el siempre sabia solucionar los problemas cuando me atascaba y destilaba ese aire de confianza que es tan atrayente.Pero llego el día en que esa persona al que todos recurríamos se fue de la compañía, dejando tras de sí un código incomprensible con un vacío completo de conocimiento. Todo estaba en su cabeza.

De repente me di cuenta de que no había apenas documentación de la aplicación sobre la que tenía que trabajar, y la que existía estaba desfasada. Cada vez que había una incidencia mi equipo y yo nos pasábamos horas destripando el galimatías que era ese código, dándonos cuenta de que en muchos casos el problema es que se habían añadido “parches” que solucionaban casos concretos pero no se había comprobado si afectaba a nada más, creando así una cadena de casos aleatorios que hacía que fallara por otro sitio muy diferente o variables de configuración pérdidas entre ficheros que había que ir buscando una a una.   

Al final,  el hecho de que esa persona se fuera de la empresa, repercutió en el trabajo de todos, ya que el conocimiento lo tenía solo en su cabeza. Su marcha conllevó retrasos en los  desarrollos y dificultó las tareas de mantenimiento. Para minimizarlo optamos por dividir la aplicación en partes para investigar por separado cada persona del equipo, lo que lateralmente creó pequeños “gurús”, ya que cada uno acaparaba sin quererlo el conocimiento de esa parte. 

No solo se crearon más “personas imprescindibles” sino que hacía muy difícil que nuevos trabajadores se unieran al equipo, ya que el traspaso de conocimientos era muy costoso de gestionar. 

Debido a estas experiencias invertía bastante tiempo en crear documentación, muchos comentarios en el código, quería que todo quedara lo más claro posible. Pero desde que he comenzado este curso descubrí que mi enfoque no era tan bueno como creía, técnicas como el TDD, Object Calisthenics o Golden Master, han hecho que mi forma de aproximarme al código legacy e incluso de crearlo desde 0 haya dado un cambio de 360 grados.

Así que iré compartiendo con vosotros a través de estas entradas del blog mis pequeñas aventuras y como estoy redescubriendo la “forma más eficiente” de programar .

AH! También estoy creando pequeños artículos sobre videojuegos, y charlas para Begginers…pero eso ya es otra historia.

Comments

Leave a comment

Your email address will not be published.
Required fields are marked *