Qué entiendo por sobre ingeniería
Los desarrolladores de software tenemos un doble desafío cuando escribimos nuestras aplicaciones. Por un lado, escribir código que funcione y sea entendible, y por otro, evitar la sobreingeniería. En el ambiente muchas veces nos referimos a este problema como “mandar cohetes a la luna”. Obvio, en el caso de que el requierimiento no sea mandar un cohete a la luna, aunque generalmente no es el caso. Yendo a casos más concretos, entiendo por sobreingeniería la acción de complejizar el código para tratar de solucionar problemas que no tenemos en el presente, y que es poco probable que tengamos en el futuro.
Cómo detectar la sobre ingeniería
Se me ocurren varias maneras de detectar la sobreingeniería. La primera, un poco inútil y anecdótica es la cantidad de patrones de diseño que tenemos aplicados en nuestro código, que no responden a un problema real que tengamos. Tanto la falta de aplicación de los patrones, como su excesiva aplicación son señales de mal código. Los patrones de diseño son herramientas que responden a un problema determinado. Si los usamos para problemas que no tenemos, solo estamos empeorando la calidad de nuestro código, porque lo hacemos más abstracto y probablemente más difícil de leer. Pero claro, una vez que está escrito el código, si bien lo podemos refactorizar, implica un esfuerzo adicional. Entonces, como hacemos para detectar la sobreingeniería en un punto del desarrollo que nos sea útil?
Detectar la sobre ingeniería en una instancia útil
El momento más útil para detectarlo es cuando estamos pensando el diseño y cuando estamos escribiendo el código. Ese es justamente el momento en donde suele surgir el problema. Como trato de detectarlo antes de que sea tarde? No tengo un método concreto, pero si varias situaciones que me sirven de patrón.
- Pensar y re pensar qué problema estoy tratando de solucionar con mi diseño. Contrastar la solución que estoy obteniendo para ver si soluciona el problema o lo empeora.
- Si estoy usando un patrón de diseño, que este sea emergente del problema que trato de solucionar.
- Preguntarme iterativamente “cómo puedo hacerlo más simple? Partiendo de la base de que seguramente hay una opción más simple para cada código que escribamos, solamente que puede no salir a la luz en ese momento.
- Pedirle opinión a otro desarrollador. A veces solamente con explicar el problema a otra persona se nos ocurre la solución más simple (también conocida como la técnica del pato de goma)
- Suenan las alarmas cuando escucho la frase “por las dudas hagamos [bla bla bla]” . En el nombre del por las dudas se realizan muchas sobreingenierias. Está bueno tratar de hacer software robusto, pero para eso también tenemos que saber priorizar los problemas que vamos a resolver, y qué vamos a generar con considerar ese nuevo caso en nuestro código.
Y ahora qué hacemos?
Les propongo que la próxima línea de código que escriban se pregunten lo siguiente:
Para qué estoy escribiendo esta línea de código? Si tienen respuesta, ahonden un poco más: …Y para qué? …Y para que? Es normal en algún punto quedarse sin respuesta, o darnos cuenta de que vamos mal encaminados con nuestra solución. Ese es el punto ideal para reemplazar las líneas de código por conversaciones con otros desarrolladores, analistas funcionales y usuarios, porque probablemente estemos equivocando el rumbo.