¿Es una buena práctica seguir las técnicas de optimización durante la codificación inicial o se debe concentrar primero en la realización de la funcionalidad?¿Es una buena práctica hacer la optimización durante la codificación inicial?
Si uno se concentra exclusivamente en la funcionalidad durante la codificación inicial, ¿qué tan fácil o difícil es cuidar la optimización más adelante?
Optimice su diseño y arquitectura, no se encerre en un diseño que nunca se ampliará, pero no micro optimice su implementación. En particular, no sacrifique la simplicidad y la legibilidad para una implementación micro-optimizada ... al menos no sin una evaluación comparativa de su código (idealmente, su sistema completo) primero.
La medición es realmente el punto clave cuando se trata de rendimiento. Los cuellos de botella casi nunca están donde usted espera que estén. Hay muchas maneras diferentes de medir; la optimización sin ninguna medida es inútil.
+1 no solo para citar a Knuth. Si veo esa cita una vez más, me volvería loco;) –
@Dominic Rodger Esta http://stackoverflow.com/questions/2092562/is-it-a-good-practice-to-do-optimization-during-initial -coding/2092576 # 2092576? :) – jensgram
optimización prematura es la raíz de todos los males
Para elaborar más en esta famosa cita, hacer la optimización temprana tiene la desventaja de que le distraiga de hacer un buen diseño. Además, los programadores son notoriamente malos a la hora de encontrar qué partes del código causan más problemas, por lo que intentan optimizar cosas que no son tan importantes. Siempre debe medir primero para descubrir qué debe optimizarse y esto solo puede suceder en fases posteriores.
Corolario: lo anterior no pretende endosar * diseños de mala calidad, inaceptablemente lentos * – ZJR
Donald Knuth dijo:
Debemos olvidarnos de pequeñas eficiencias, dicen que alrededor del 97% del tiempo: la optimización prematura es la raíz de todo mal
Ver http://en.wikipedia.org/wiki/Program_optimization para las cotizaciones por Knuth.
Si cree que la optimización puede hacer que su código sea más difícil para (a) entrar en primer lugar, o (b) mantener en el largo plazo, entonces es probable que lo mejor sea hacerlo primero. Tener buenos procesos de desarrollo, como Test Driven Development, puede ayudarlo a realizar optimizaciones más adelante.
Siempre es mejor hacer que funcione bien y lento, que incorrecto y rápido.
Depende de lo que vea como "optimización". La microoptimización no se debe realizar en etapas tempranas, y luego solo si tiene una razón válida para hacerlo (por ejemplo, resultados del generador de perfiles o similares).
Sin embargo, escribir un código limpio y bien estructurado siguiendo las mejores prácticas y las pautas comunes de codificación es una buena costumbre, y una vez que esté acostumbrado, no tomará mucho más tiempo que escribir código descuidado. Este tipo de "optimización" (no es la palabra correcta para él, pero algunos lo ven como tal) debe hacerse desde el principio.
Con razón dijo Donald Knuth "La optimización prematura es la raíz de todo mal", y hace que la velocidad de su código sea lenta. La mejor forma de optimizar es visitando nuevamente la base de código y refactorizando. De esta forma sabrá qué parte del código se usa a menudo o es un cuello de botella y se debe ajustar.
La optimización prematura no es una buena cosa. Y eso va especialmente para la optimización de bajo nivel. Pero en un nivel superior, su diseño no debe bloquear ninguna optimización futura.
Por ejemplo.
La recuperación de colecciones debe ocultarse detrás de la llamada a métodos, al final siempre puede decidir guardar en caché la recuperación de colecciones o no. Después de tener una aplicación estable y (!) Ha desarrollado pruebas de unidades de regresión. Puede perfilar la aplicación y optimizar los puntos de acceso. Y recuerde que después de cada paso de optimización debe ejecutar su conjunto de prueba de unidad completa.
¿Es una buena práctica seguir las técnicas de optimización durante la codificación inicial o se debe concentrar primero en la realización de la funcionalidad?
Si sabe que el rendimiento es crítico (o importante), considérelo en su diseño y escríbalo correctamente la primera vez. Si no considera esto en su diseño y es importante, está perdiendo el tiempo o "desarrollando una prueba de concepto".
Parte de esto se reduce a la experiencia; Si conoces las optimizaciones y las áreas problemáticas de tu programa o si ya has implementado funcionalidades similares en el pasado, tu experiencia ciertamente te ayudará a crear una implementación más cercana al resultado final la primera vez. Si aún necesita una prueba de concepto, no debe escribir el programa real hasta que esté completo: saque algunas pruebas para determinar qué solución es la adecuada para el problema, luego impleméntela adecuadamente.
Si uno se concentra exclusivamente en la funcionalidad durante la codificación inicial, ¿qué tan fácil o difícil es cuidar la optimización más adelante?
Algunas correcciones son rápidas, otras merecen una reescritura completa. Cuanto más necesite cambiar y adaptarse después del hecho, más tiempo perderá en volver a probar y mantener un programa mal implementado. Las bibliotecas que son más fáciles de mantener y sustentar las demandas suelen ser aquellas en las que el ingeniero entendió qué diseño es el ideal y se esforzó por alcanzar ese ideal durante la implementación inicial.
¡Por supuesto, eso también asume que usted está a favor de un programa de larga duración!
Pregunta similar (en realidad no es un duplicado): http://stackoverflow.com/questions/895574/what-are-some-good-code-optimization-methods – TRiG