A raíz del post del otro día sobre repetir el código, me vino el recuerdo de otro gran clásico, y no podía dejarlo, lo tenía que postear: tener un case o switch con muchas clausulas, o muchos ifs anidados, tampoco es ninguna una buena idea.
Aunque hace ya tiempo que no me dedico a ello, hubo una época en la que profesionalmente traté mucho con explicar, solucionar y detectar problemas como este. Tanto que problemas como este además de inspirar una tesis doctoral dieron para un libro.
No es bueno tener un case o switch con muchas clausulas, o muchos ifs anidados, porque, entre otros:
– Hace muy difícil entender el código, lo que lleva a que es más difícil mantenerlo, lo que lleva a que se aumenta el coste (€ $) del mantenimiento.
– Cada vez que hay que añadir un comportamiento más, una nueva clausula en el case o switch, hay que modificar ese fuente y recompilar. Lo que aumenta el coste del mantenimiento.
– Y porque está bastante probado que esta práctica suele llevar a la del otro día, a repetir el código. Que también aumenta el coste del mantenimiento.
Esta sospechosa práctica también forma parte de los “bad smells” (“malos olores”) de Beck y Fowler, y que citan como “switch statements”.
Y aunque os encontreis con el lado oscuro, quien os dirá que es imposible evitarlo… asegurar que si, que si hay otras maneras de codificar la lógica condicionar. Una de las más famosas es mediante el polimorfismo, seleccionando en tiempo de ejecución la parte condicional, vamos, lo que hacen los viejos patrones State y Strategy del Gamma. Y como en el caso del código repetido, esta práctica suele esconder algún problema de diseño y es fácilmente detectable con muchas herramientas de software libre.
Aunque hace tiempo que deje de tratar tanto con este tipo de problemas (que no de encontrármelos en revisiones y auditorías) parece que el mundo ha seguido luchando contra ello… hasta el punto de que incluso he encontrado videos en youtube sobre ello. Ya no hay escusa para seguir anidando numerosos ifs ; – ).
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Interesantes consejos.