En cierta medida escribir software es como escribir cualquier otra cosa. Si alguna vez os habéis enfrentado con una hoja en blanco, probablemente os hayan entrado dudas y, seguramente, hayáis dado mil y una vueltas a como queríais trasladar vuestros pensamientos a un papel.
No sé vosotros, pero yo no será ni la primera ni la última vez que después de releer lo que he escrito, veo que no se entiende nada. O abuso de las subordinadas o el lenguaje empleado no es el adecuado. Me meto en un proceso iterativo, en el que borro, reescribo y reorganizo.
Con el software pasa algo parecido. Pensamos, escribimos, pasamos las pruebas, funciona, pero… no acaba de estar bien, es necesario plantearlo de otra manera. Al hacerlo así, muchas veces nos pasamos de frenada. Con lo cual, toca revisarlo otra vez y reestructurar, reescribir y aclarar.
Nuevamente buscamos lo mismo que con la escritura, que se entienda o, más bien que, especialmente, lo entiendan otros. ¿Y por qué? Pues porque el software tiene una vida que, en cierta medida, escapa al de otro tipo de obras humanas. Es necesario adaptar, modificar y adecuar a objetivos no previstos inicialmente.
Lamentablemente, todo lo que no hayamos hecho nos condicionará y, entonces, hablaremos de refactorización cuando en realidad hablamos de rehacer. Hacer las cosas bien lleva tiempo, no son sólo procedimientos y buenas prácticas, sino que se requiere educación y especialización.
Esto no quita para que de repente ignoremos el negocio, el software es una herramienta al servicio de éste. Tanto unos como otros debemos ser conscientes de la importancia de la colaboración, de un alineamiento del que ninguno de los involucrados podemos ni debemos de escapar. Necesariamente, hablamos de una planificación y ajuste de expectativas, focalizándonos en aquello que, realmente, da valor.
Discusión sobre este post
Sin posts