Deuda imprudente
Es el tipo de deuda en el que el desarrollador actúa de forma imprudente y consciente. Esto suele llevar a un proyecto que tiene mala calidad y es poco tolerante al cambio. Usualmente se puede detectar cuando se escuchan frases del tipo: «no hay tiempo para eso», «copia y pega eso», o el clásico, «tenemos que terminar esto como sea».
Deuda imprudente e inadvertida
Se genera por el desconocimiento o falta de experiencia, y es la más peligrosa de todas. Son creadas bien por un perfil de tipo junior o lo que es peor, por un falso senior.
Deuda prudente y deliberada
Se da cuando sabemos que la deuda existe y somos conscientes de ella. El peligro de esta deuda es que si no se paga a tiempo, más «intereses» pagaremos después. Nos debería saltar la alarma de este tipo de deuda técnica cuando localizamos mensajes del tipo: //TODO, «ya refactorizaremos luego», …
Deuda prudente e inadvertida
Es normal no tener el conocimiento total de cómo quedará el proyecto al comenzarlo. La deuda prudente e inadvetida es la deuda que a medida que vamos progresando nos damos cuenta de ella y decimos cosas del tipo: «no sé si ahora es un buen momento para empezar de cero tal cosa», «o si vale la pena implementar en este punto tal arquitectura o tal patrón, o seguimos adelante».
Ahora la pregunta clave…
¿Cómo se paga una deuda técnica?
Con refactorización. La refactorización es simplemente un proceso que tiene como objetivo mejorar el código sin alterar su comportamiento para que sea más entendible y tolerante al cambio.
Usualmente para que una refactorización fuerte tenga el objetivo esperado es imprescindible contar con pruebas automáticas. Cuando no se tienen pruebas automáticas o no somos capaces de implementarlas es cuando aparece el famoso dicho de «si funciona, no lo toques».
Esto es producto de no tener un código fuerte y tolerante a cambios. Si no tenemos una forma robusta y ordenada de trabajar, ni pruebas automáticas, es común decir: si haces algo ahí no sabemos cómo si funcionará eso o no el día de mañana. Muy típico cuando mantenemos un software desarrollado por otros.
La mala calidad en el software siempre la acaba pagando o asumiendo alguien. Ya sea el cliente, el proveedor con recursos o el propio desarrollador dedicando tiempo a refactorizar o malgastando tiempo programando sobre un sistema frágil.
El punto para crear software robusto y tolerante a cambios pasa por el CLEAN CODE.
Algunas definiciones de Clean Code o Código Limpio
Estas son algunas definiciones de Clean Code que nos gustan mucho:
El Código Limpio es aquel que se ha escrito con la intención de que otra persona (o tú mismo en el futuro) lo entienda – Carlos Blé.
Nuestro código tiene que ser simple y directo, debería leerse con la misma facilidad que se lee un libro – Grady Booch.
Programar es el arte de decirle a otro humano lo que quieres que la computadora haga – Donal Knuth
Cuando hablamos de código limpio, obviamente se procura que el programa haga lo que esperamos, pero nos preocupamos extra en que nuestro código sea muy fácil de leer.
Continuará en la parte II. ¡No te la pierdas!