el holgazán

Ahí van...

10. Optimizar el rendimiento suponiendo que se traducirá en escalabilidad/Ignorar el potencial impacto del rendimiento en la escalabilidad (y viceversa).
El rendimiento tiene que ver con mejorar los tiempos de respuesta a un usuario. La escalabilidad está relacionada con soportar muchos usuarios simultáneos.

9. Suponer que eres más listo que la infraestructura/seguir las reglas a ciegas.
Esto incluye no pensar en las implicaciones transaccionales al utilizar ficheros, construir tu propia función de pool de conexiones o no usar frameworks como Struts, Hibernate o Spring porque crees que puedes hacer mejor el trabajo tú mismo.
Por el contrario, a veces es necesario romper las reglas, como es el caso de usar FTP para integrar aplicaciones, etc.

8. Abusar de la base de datos/Evitar la base de datos.
A veces se utilizán las bases de datos para cuestiones para las que no han sido diseñadas, visto el coste y las limitaciones de escalar una base de datos. Debe evitarse su uso para tareas de "gran volumen y bajo valor", como el logging, almacenar el estado de conversaciones o haciendo cosas que podrían hacerse mejor con un sistema de ficheros. Debería usarse sólo si se requiere almacenar información persistente y transaccional.

7. Introducir un único punto de cuello de botella/Introducir un único punto de fallo.
No hay mucho más que decir sobre los cuellos de botella que incluyen acceso a base de datos, colas de mensajes o servidores web.

6. Abusar de las abstracciones/Evitar las abstracciones.
A veces las abstracciones hacen imposibles las cosas que son sencillas y ocultan su coste en el rendimiento.
Sin embargo, hay muchas abstracciones muy útiles que se ocupan de asuntos como la caché, la seguridad y la auditoría, minimizando el mantenimiento del código.

5. Suponer que se puede añadir DR (disaster-recovery) cuando se necesita.
Es prácticamente imposible que los sistemas de recuperación no afecten al rendimiento.

4. Usar una arquitectura de "talla única".
Las arquitecturas clónicas pueden ser un desastre, sobre todo cuando se tienen requisitos del estilo "24x7", "99%" o "hazlo como Google".

3. Usar grandes heaps de JVM.
Los mecanismos de recolección de basura para limpiar la memoria (garbage collection) pueden llevar mucho tiempo en la práctica para tamaños grandes de memoria de la máquina virtual. A veces un método "finalize" es capaz de mejorar el rendimiento en gran medida.

2. Suponer que la red funciona.
No se puede suponer que el ancho de banda de las redes será el máximo teórico.

1. Evitar características propietarias (de marca registrada)/Creer en las quejas que se escuchan sobre los productos.
Mucha gente teme encerrarse en un proveedor. Sin embargo, a menudo no es necesario cambiar.
Y, aunque la estandarización tiene sus beneficios, también puede causar problemas para un beneficio pequeño (considerar, por ejemplo, EJB2 vs Hibernate+Spring).


(De Cameron Purdy, en JavaOne, vía Shine blog).