Si tiene que comenzar a pensar en el rendimiento, está en problemas. Deberías estar pensando en el rendimiento todo el tiempo. De hecho, sospecho que los buenos programadores van a pensar en el rendimiento, incluso cuando no tenían la intención de hacerlo, de una manera «los hombres piensan en el sexo cada siete segundos».
Lo importante es qué acciones tomará en función de todo ese pensamiento. Los pensamientos son baratos, pero las acciones pueden romper el código y romper los plazos.
La mayoría de las veces, la única acción sensata será no hacer nada: identificó que su código no se llamará con la frecuencia suficiente para que los problemas de rendimiento sean observables, tal vez es un código de inicio que se ejecuta una vez por computadora para 1% de su base de usuarios potenciales, quizás sea un pequeño código de servidor redundante ahogado en un mar de accesos lentos a la base de datos, quizás sea solo una asignación de enteros en una sección de código no crítica.
Muy a menudo, sospecha que una operación determinada puede causar un problema de rendimiento que podría resolverse con un simple cambio. Existe, por ejemplo, la sensación persistente de que ejecutar una consulta SQL compleja en cada solicitud, o pedir dos veces el mismo dato de un diccionario, será malo para usted. Aquí es donde el conocimiento de las técnicas de optimización es útil, y quizás ocurra la conclusión más sorprendente:
Si conoce una técnica rápida que seguramente mejorará el rendimiento de un código, no lo haga.
Si puede pensarlo ahora, ciertamente puede hacerlo cinco minutos después. Mantenerlo fuera del código (pero, tal vez, en un // TODOcomentario) deja el código más limpio y le ahorra tiempo anterior para trabajar en otra función, sin perder tiempo si termina desechando ese código más adelante. Si el código original causa problemas de rendimiento cuando se prueba, regrese y aplique su técnica rápida.
No digo aquí que debas evitar escribir código que sea idiomático solo porque resulta ser más rápido. Escriba código idiomático de acuerdo con las mejores prácticas que mejoran la productividad y la legibilidad y reducen los errores. Es solo que si tiene que elegir entre un código idiomático por libro y una alternativa más rápida pero fácil de escribir, siempre busque legibilidad en lugar de velocidad.
La única situación difícil es cuando parece que no hay una manera fácil de mejorar el rendimiento del código y, sin embargo, es dolorosamente obvio que un fragmento de código se romperá tan pronto como se entregue: un recorrido completo de la base de datos en cada clic, cien solicitudes SQL por página en el sitio, o cualquier cosa igualmente terrible. Aquí es donde realmente necesitas detenerte y pensar un poco más. Por lo general, estos son problemas de arquitectura que no se pueden resolver a escala local de todos modos. Confirme sus sospechas con un pico o prototipo rápido, busque experiencias similares y soluciones comunes, y considere un cambio de arquitectura o una caída de características.