Deuda técnica /Technical Debt

Cuando, Cómo , Por qué ? Como la evitamos ?

Cuando pensé en desarrollar este tema, fue porque creo que la mayoría de los desarrolladores no somos muchas veces consciente de la significancia de este Issue, de este concepto y del peso y su impacto en nuestras tareas.  Muchas veces siquiera no tenemos en cuenta , en las estimaciones, el costo de “saldar” esta deuda.

Creo que todos en algún punto del proyecto empezamos a generar este “debe” en nuestros desarrollos, y surgen por distintas causas, desde las no mal intencionadas , como deadlines, ignorancia, una mala noche con los niños,  etc hasta quizas las propias de no tan buenas causas, como ser decidia, estar en discordia con el proyecto , con el sueldo, y otro sin fin de motivaciones.

Que es deuda tecnica?

Es hacer cosas de manera no correctas ( hardcodeos, codigo mal diseñado, sin test, hacks, en general muchos “if’s”) pero que funcionan y en general solucionan un tema “muy caliente” que por circunstancia contractual, muchas veces queda en el “provisorio / para siempre”. Esto nos afecta, ya que indiscutiblemente es un parche, para las implementaciones a futuro. que luego evolucionarán sobre estas malas implementaciones , volviendo mas dificil arreglar cosas que fueron, desde su nacimiento, mal concebidas.

Cómo prevenirla , cómo la soluciono?

Es importante entender que no siempre surge de un apurón, ya que  tambien muchas veces simplemente surge por que no sabemos que estamos creando la misma.Creo que todos en mayor o menor medida estamos creando siempre deuda técnica, desde el vamos basado en la creencia que todos podemos mejorar en nuestra profesión. El tema es hacer algo que no nos complique en demasía pensando en el futuro.

Nosotros iremos descubriendo que algo que fue maravilloso en una epoca, ahora lo vemos como algo simplemente mal.

Atacar este problema debe ser tanto una cuestión de conciencia personal como algo que lo debemos ver como un subject del equipo

Algunas ideas

A nivel de desarrollador :

* Si somos concientes del apurón y que estamos haciendo las cosas mal es dejar el comentario en dicho codigo diciendo: esto esta feo, y soy conciente de ello, pero hay que sacarlo andando, un HIPER TODO.

* Tener en la cabeza de tratar de desarrollar en capas y en lo posible con Single Responsability como idea principal. Es decir  , si sabemos que estamos metiendo hacks como loco, OK, pero dejemoslo en una clase aparte. Que esa clase / esa capa contenga nuestro desman.

* Testing: Como no señores!! testear!! nada como un par de test conteniendo la funcionalidad, que de última nos quede , sobre la funcionalidad hackeada, un test que nos contenga la validez de la funcionalidad. Esto nos permitirá luego que ????... Si.. Refactorizar!. Y si usaste TDD, ya tenes acotado al menos parte del escenario con problemas.

A nivel de Equipo:

* Code Review : Hay herramientas que son increibles, tuve la suerte de trabajar con esta metodología y no tengo cons en este aspecto. Es un mito totalmente falso el hecho de la perdida de tiempo. Si estan las cosas bien pautadas. La calidad y aprendizaje del equipo en general es simplemente impresionante. Y nada mejor que arreglar las cosas cuando las intencionalidades e ideas estan frescas.

* Que el equipo acepte y lo incluya en las estimaciones el testing y code-coverage. El Code Coverage, sin ton ni son , no tiene sentido, pero al menos si rompemos algo que al menos sepamos, por medio de los test y esta herramienta , que puede ser útil , inteligentemente aplicada, hay una contención sobre nuestras falencias. 

La deuda tecnica existe , y lo mas complicado para repararla es encontrar el tiempo para repararla. El tiempo invertido en testing, es nuestro cheque al futuro para poder hacer refactors que mejorarán el proyecto. Los mismos, aceptemoslo, son inevitables.

Cómo conclusión es responsabilidad de los desarrolladores con más experiencia y el team leader hacerse cargo de esta deuda, de estar atento de más alla de la implementaciones, tener regulado este problema tiene como recompensa una lista acotada de bugs, y que un cambio de requerimiento no sea un miedo a tirar abajo un castillo de naipes. Esto sobre todo en proyectos grandes . Los test son nuestros seguros contra la deuda, pero ella indudablemente existirá. Cómo la gestionemos , que sepamos concientemente que existe es nuestra responsabilidad para con el proyecto y para con nuestros pares