Primero haga que funcione, después hágalo rápido. Esto es cierto incluso si se está seguro de que una trozo de código es realmente importante y se sabe que será un cuello de botella es el sistema. No lo haga. Primero, consiga que el sistema tenga un diseño lo más simple posible. Entonces, si no es suficientemente rápido, optimícelo. Casi siempre descubrirá que «su» cuello de botella no es elproblema. Guarde su tiempo para lo verdaderamente importante. Bruce Eckel, Thinking in C++
Recuerdo un desarrollo donde el responsable (que no era codificador) quería optimizar al máximo la velocidad de una aplicación, era una obsesión para él. Así que se entro en una restructuración del código tras otra, con tal de obtener un poco mas de velocidad. Al final el resultado fue que se gano aproximadamente unas pocas horas de procesamiento por cada año de operación, lo que en un escenario real, viene a ser nada, por otro lado se obtuvo un código fuente completamente incomprensible y extremadamente difícil de modificar. Cuando llegaron los inevitables cambios, cada cosa que se movía era un problema nuevo, cada pequeño cambio un desastre inesperado, incluso al final el sistema comenzó a ser extremadamente lento. Al final el sistema se descarto, porque era inusable e inmantenible.
Dos términos que definen la calidad del software son la escalabilidad y la mantenibilidad, a veces son usados para referirnos al mismo aspecto del software, a que pueda “cambiar” con facilidad, y sin problemas.
- La mantenibilidad son las modificaciones que hacemos a un sistema para que siga funcionando con el propósito para el cual fue diseñado (para resolver la necesidad de el negocio para que fue creado)
- La escalabilidad es la facilidad con la que podemos agregar nueva funcionalidad a un software para que se adapte a las nuevas necesidades de un mercado y para que nuestro negocio no se quede estancando y obsoleto.
Hay que considerar dos cosas, y más en estos precisos momentos:
- Todos los negocios al competir entre ellos evolucionan, cambian constantemente para adaptarse a las necesidades de sus clientes (o crear necesidades nuevas).
- Todos estos negocios se sustentan, de una forma u otra en software que los hacen posibles.
Si el software no es capaz de adaptarse para sostener los continuos cambios de un negocio, va a fallar como sistemas y posiblemente falle el negocio siendo reemplazado por una empresa que si pueda suplir las necesidades del consumidor.
En nuestra vida profesional, vamos a estar más tiempo manteniendo software que creando software de cero. La idea de que se crea un software y nunca se va a tocar, porque “funciona bien a la primera”, es una falacia.
Aquí es donde es fundamental, que el software sea mantenible, si invertimos poco, arquitectónicamente hablando, en la construcción del software, invertiremos mucho en su mantenimiento, y viceversa. Consideran que si vamos a pasar más tiempo mantenimiento un sistema que creando, parece lógico, que debemos optar por abaratar el costo en el mantenimiento.
Volviendo al tema de la velocidad de los sistemas. La preocupación por la velocidad del software, es una “piedra en el zapato”, que a acompañado al desarrollo del software desde sus inicios. El hardware era extremadamente lento (y caro), y había que hacer software rápido, aunque sea sacrificando su propia mantenibilidad (con lo que también hacíamos software caro). Esta idea del de la necesidad de software rápido se incrusto como un paradigma inmutable en la mente de los programadores, aunque ni siquiera tuvieran que haber vivido la lentitud de un hardware tan extremo como en sus inicios.
Así parece que de forma sistemática, cada vez que ser creaba un lenguaje de programación más abstracto con el hardware, se le criticaba de forma inevitable por su lentitud. “C es más lento que ASM”, “C++ es más lento que C”, “Java es más lento que C++”, y así seguirá en un futuro, seguramente.
Las optimizaciones por obtener velocidad, pueden llegar a ser muy confusas, y a veces muy ligadas a situaciones extremadamente particulares (tanto para el software, como para el negocio). Y aquí hay que poner en una balanza varias cosas.
- ¿Realmente mi software es lento?
- ¿Realmente necesito que mi software sea más rápido?
- ¿Cuál es el costo de optimizar el software? O ¿Qué voy a sacrificar para obtener más velocidad?
- ¿Cuál es el beneficio de la optimizar el software, es real?
Aquí es donde hace sentido, la observación de Bruce Eckel, “Primero haz que funcione, después hágalo rápido”. Asegúrate siempre de programar un software bien construido, que puedas modificar fácilmente.
Un software lento, bien construido, siempre podrás modificarlo para que sea más rápido. Un software rápido mal construido, no vas a poder modificarlo.
Si te ha gustado la entrada, ¡Compártela! ;-)
Reglas de la Ingeniería de software (índice): https://desdelashorasextras.blogspot.com/2019/12/reglas-de-la-ingenieria-de-software_15.html
No hay comentarios:
Publicar un comentario