¿Cómo pueden los equipos de desarrollo evitar un rendimiento lento en las aplicaciones de consumo?

Cuando pregunté previamente qué es responsable del software lento, algunas respuestas que recibí sugirieron que era un problema social y de gestión:

Este no es un problema técnico, es un problema de marketing y administración ... En última instancia, los gerentes de producto son responsables de escribir las especificaciones de lo que se supone que debe obtener el usuario. Muchas cosas pueden salir mal: el gerente de producto no pone la respuesta del botón en la especificación ... La gente de control de calidad hace un trabajo mediocre al probar la especificación ... si la gerencia del producto y el personal de control de calidad están todos dormidos al volante, nosotros los programadores no podemos compensar eso. - Bob Murphy

La gente trabaja en aplicaciones de buen tamaño. A medida que funcionan, los problemas de rendimiento se arrastran, al igual que los errores. La diferencia es que los errores son "malos", gritan "encuéntrame y arréglame". Los problemas de rendimiento simplemente se sientan allí y empeoran. Los programadores a menudo piensan "Bueno, mi código no tendría un problema de rendimiento. Más bien, la gerencia necesita comprarme una máquina más nueva / más grande / más rápida". El hecho es que si los desarrolladores periódicamente buscan problemas de rendimiento ( que en realidad es muy fácil ), simplemente podrían limpiarlos. - Mike Dunlavey

Entonces, si este es un problema social, ¿qué mecanismos sociales puede establecer una organización para evitar enviar software lento a sus clientes?

Con requisitos completos y correctamente escritos, no existe una distinción entre errores y bajo rendimiento . Debido a que especifica el rendimiento como un requisito no funcional, el bajo rendimiento se convierte en un error como cualquier otro error, y QA lo detectará y los desarrolladores lo resolverán antes del lanzamiento.

¿Hay algún problema social? No lo creo. El problema principal es que los requisitos están incompletos. Trabajando durante años como profesional independiente, nunca vi un requisito no funcional que dijera que una tarea específica debe realizarse en N segundos como promedio en promedio. Si el gerente / cliente / parte interesada o cualquier otra persona no se preocupa por el activo de rendimiento, ¿por qué yo, como desarrollador, lo haría, ya que a las personas que deben preocuparse por él no les importa en absoluto?

Hay otro factor que influye en el bajo rendimiento: el hecho de que los desarrolladores trabajan en PC costosas que funcionan bien . Cuando trabajas durante años en una PC de cuatro núcleos con 8 GB de RAM, una SSD de gama alta, el último sistema operativo, etc., es muy difícil imaginar cómo se ejecutará tu aplicación en Windows XP en una PC de doble núcleo con 512 Mo de RAM y un viejo disco duro lleno al 90% y no desfragmentado por años. Desafortunadamente, en algunos países, el último caso es el que vemos para la mayoría de los consumidores de una aplicación. Cuanto mayor es la brecha entre las PC de desarrollador y las PC de consumo, más complicado es para un desarrollador cuidar el rendimiento de su aplicación.

El problema(?):

• El cliente (o usuario final) no se queja (suficiente)
• Por lo tanto, el gerente del proyecto (/ producto) no lo considera un requisito
• Por lo tanto, el desarrollador no tiene tiempo para arreglarlo.

Tienes que comenzar desde el principio, educar a los clientes. Pero si compran el iPhone en lugar de un teléfono más rápido y menos brillante, los desarrolladores tienen razón en dedicar su tiempo a la apariencia en lugar del rendimiento. La organización no es el problema.

Por supuesto, algunas cosas pueden ayudar de todos modos. Esperar las pruebas automatizadas es molesto, por lo que si tiene pruebas automatizadas, los desarrolladores tienen comentarios constantes sobre los problemas de rendimiento y es más probable que lo resuelvan (como un problema técnico, no como una característica).

Pero no puedes hacer todo. Es optimizar o agregar funciones, y aquellos que gastan el dinero deciden.

Pero algunas buenas noticias: he notado que las aplicaciones SaaS / Cloud / Buzzword ayudan mucho aquí. Cuando las personas eligen entre unas pocas aplicaciones web similares y prueban en vivo en lugar de crear primero listas artificiales de características 'requeridas', la respuesta les influye más rápidamente y, por lo tanto, el rendimiento llamará más la atención.

Lamentablemente, creo que el mayor problema es que no puedes hacer todo. Tiene una fecha de envío y sabe que es lenta, pero NECESITA obtener las funciones X, Y, Z en el mercado.

En tu mente, lento puedes arreglarlo más tarde, pero la aplicación al menos funciona.

Por lo tanto, le preocupa la funcionalidad y la estética (porque los usuarios se centran en la estética con demasiada frecuencia). La próxima versión arreglará el rendimiento.

Pero el PM solo le da una lista de características, y no hay tiempo para arreglar el rendimiento.

Y el círculo vicioso continúa.

Estoy de acuerdo con otros, en que deberíamos encontrar maneras de hacer que los desarrolladores se preocupen más por el problema, como hacer que prueben en hardware más lento y tener objetivos de rendimiento. Todo está bien, pero realmente, cuando se trata de ajuste de rendimiento,

La gente tiene que saber cómo, y no

Puede que piensen que sí, pero solo mire todas las preguntas y respuestas relacionadas con el rendimiento en StackOverFlow y en este foro. Es doloroso cuántos muestran muy poco sentido común sobre el rendimiento.

No es algo de lo que hablar, la gente necesita aprender al hacerlo . El único momento en que están en ese modo es cuando están tomando una clase o aprendiendo cosas nuevas de un libro o blog.

Por lo que la única manera que puedo pensar para resolver este problema es conseguir el asimiento de las personas que enseñan programación, y enseñar a ellos cómo hacerlo.

Dios sabe, lo he intentado en estos foros, como en ...

• El método básico super simple
• Un aumento de velocidad 43x - hacer que con su perfilador
• Las razones por las cuales, con detalles nauseabundos

Cualquiera lo puede hacer. Solo necesitan hacerlo realmente .

Haz que el rendimiento sea un requisito.

Escribir código de rendimiento es difícil. Requiere una comprensión sólida de conceptos como subprocesos, manejo de eventos asíncronos, almacenamiento en caché y complejidad asintótica. A juzgar por los grupos de programadores con los que he trabajado, alrededor del 20-40% de cualquier grupo no entiende esos conceptos lo suficientemente bien como para incorporar consideraciones de rendimiento como algo natural en su trabajo diario.

Sin embargo, esos programadores obviamente siguen siendo útiles para la empresa, pero se asignan a tareas que no se consideran críticas para el rendimiento, por lo que terminas con un reproductor de Blu Ray que puede reproducir transmisiones de Netflix sin fallas sin perder ningún fotograma, pero lleva 30-60 segundos para abrir el elemento del menú que muestra su cola.

A menos que sea una compañía de software de gran alcance que pueda permitirse despedir al 20% de su personal y reemplazarlos con desarrolladores más experimentados (y más caros), la única forma real de solucionarlo es la capacitación de desarrolladores y la presentación de informes de errores. No sé cómo es en otras compañías, pero aquí, si los desarrolladores vemos un problema de rendimiento que no tenemos tiempo o prioridad comercial para solucionar, tenemos pleno derecho a presentar nuestro propio informe de errores. Puede tomar un par de lanzamientos para llegar a la parte superior de la cartera de pedidos, pero generalmente se abordan eventualmente.

Si el rendimiento es un requisito, pruébelo.

De lo contrario, Wally puede escribir un bucle infinito y salir temprano "Lleva un tiempo". El puede reclamar.

Su prueba de aceptación de software debe tener una prueba de aceptación detallada para varias características de rendimiento de la operación.

Si no hace esto, no está desarrollando ningún rendimiento en el producto.

El rendimiento (como el consumo de recursos) debe presupuestarse en subsistemas. Luego, las pruebas de aceptación del subsistema pueden verificarlos.

Luego, puede realizar una prueba temprana y, a menudo, de rendimiento. Incluso las pruebas unitarias pueden verificarlo.

Así que ahora los desarrolladores lo tienen como criterio de aceptación y pueden organizar su enfoque para adaptarlo.

Donde estoy trabajando ahora, la prueba de esfuerzo de rendimiento es 2 veces más grande que cualquier conjunto de datos de clientes que conocemos. Regularmente rompe una nueva versión del producto. Buena prueba

Recuerdo una vez a mediados de los 90 y pasaba un tiempo tratando de optimizar algo y un compañero de trabajo me dijo: "Esto se está ejecutando en pentiums, ¿a quién le importa?" .... eso fue una revelación. Lamentablemente, fue solo la punta del iceberg, he escuchado esa actitud a lo largo de mi carrera, aunque la parte del "pentium" ha cambiado con el tiempo.

La única forma de que el desarrollador promedio se preocupe es conseguir que la falta de rendimiento sea vista como un error por parte del cliente. Dependiendo de la aplicación y la audiencia, esto puede ser una tarea fácil o difícil (he visto ambas). Si al público no le importa el bajo rendimiento, los desarrolladores nunca lo harán (rápido, bueno, rápido, elija dos).

Pero no debería tomar una carta del control de calidad para que un programador se dé cuenta de que un retraso de 3 segundos entre la pulsación de tecla y la respuesta es inaceptable

De acuerdo, no debería. Debería tomar más que eso: una prueba de que el retraso obtenido es relevante para los usuarios finales .

Dado que no proporcionó ningún contexto, parece completamente posible que el retraso en el entorno de desarrollo / control de calidad sea causado por sus problemas locales de acceso lento a disco / memoria / red. Si ese es el caso, su control de calidad y desarrollo simplemente desperdiciarán sus esfuerzos arreglando cosas que simplemente no importan para los usuarios finales.

Confiar en los desarrolladores en las pruebas de rendimiento es tan productivo como tirar un dado para elegir una pieza de funcionalidad para acelerar. Ah, y es casi tan confiable como eso: "los desarrolladores generalmente tienen una intuición horrible sobre dónde estarán realmente los problemas de rendimiento en una aplicación" ( Brian Goetz ).

• He estado en un proyecto en el que la administración poco convincente alguna vez decidió que sus brillantes expertos en marketing y programadores inteligentes son lo suficientemente buenos como para manejar las preocupaciones de rendimiento de los clientes. Qué gran lección fue. Rechazo de liberación, medio año de esfuerzos destinados a la basura, y la compañía casi pierde un socio estratégico. Al final, invitaron a profesionales (expertos en benchmarking, estadísticas, experiencia de usuario, optimización de bajo nivel, cosas así) y los profesionales arreglaron ese desastre.

¿Deberían todos los programadores hacer su propio control de calidad para que puedan ver tales problemas de inmediato?

El hecho de que sea factible no significa que sea el camino a seguir. Más bien lo contrario: en mi experiencia, esta fue una de las formas más confiables de perder productividad de los programadores . Casi tan bueno como reuniones interminables e incluso mejor que entrevistar candidatos.

• Como ex-tester, una vez pensé que no debería ser un problema combinar actividades de desarrollo y control de calidad. Parecía que la diferencia entre las pruebas de desarrollo de rutina y el control de calidad sistemático no importará mucho. Pensé que la separación dev / QA es simplemente una tradición en la industria del software. Aprendí de manera bastante difícil que esto no es así. La separación resultó ser una cuestión de enfoque y productividad, y bastante seria.

Si hay un problema de rendimiento, solo dame un punto de referencia y establece el rendimiento objetivo y haré todo lo posible para alcanzarlo. No soy tan bueno en las pruebas de rendimiento, pero sé un par de cosas sobre la optimización.

Creo que el 99% de las veces el problema es el alcance del alcance. Con el dvr por ejemplo. Pensarías que esto es fácil, pero luego TIVO o un competidor presenta una nueva característica que es bien recibida. Lo siguiente que sabes es que una nueva característica está en el plato. Puede o no ser compatible con el producto existente y no estamos rehaciendo el producto existente que llevará mucho tiempo. Por lo tanto, la función se atasca y absorbe el rendimiento. Claro que los datos están ahí para obtener la información, pero si no se pensó en obtener esa información, entonces hay una buena posibilidad de que no sea fácil de obtener. Así que ahora tiene un proceso complejo para generar esa información cada vez que se acerque a la lista de programas.

Ignorando a los desarrolladores que no parecen importarles ...

Creo que muchas veces los desarrolladores que trabajan en el código no tienen las herramientas para medir el rendimiento de forma continua.

p. ej., si es posible medir el tiempo de respuesta de su aplicación (p. ej., es una aplicación basada en la web, o consulta una base de datos, etc.) - ¿Actualmente recibe notificaciones (correo electrónico, SMS, lo que sea) que indiquen los "10 principales" peores realizar (o sobre un umbral determinado) respuestas?

En muchos, muchos casos, los desarrolladores no obtienen esta información de las implementaciones del "mundo real" y, como resultado, es muy fácil ignorar la información que no se ve.

Sin embargo, si todos los días / pocas horas recibe un correo electrónico que indica que la pantalla "x" tarda 13 segundos en cargarse y está ejecutando la siguiente consulta SQL, SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...es mejor que crea que un desarrollador podría (y con suerte) solucionaría por completo eso.

Así, aunque me gustaría creer que todos los programadores hacen rendimiento tomar en serio creo que la falta de visibilidad al tema (s) es a menudo el culpable.

Nota: Creo que esto es algo a lo que tanto los desarrolladores deberían solicitar acceso (o incluso desarrollar dicha función) como la administración debería proporcionar / financiar dichas herramientas.

¿Puedes encontrar mejores ejemplos donde podamos culpar a los programadores? Además de Eclipse, y un comentarista ya ha señalado que son los complementos los que lo hacen (mi primera instalación de cada nueva versión de Eclipse se ejecuta como un rayo, pero cuando agrego las otras herramientas comienza a disminuir), sus ejemplos pueden no ser programadores y relacionado con el código pero relacionado con el medio ambiente.

Los días de ejecutar un programa en una computadora de forma aislada y determinar si es 'rápido' o 'lento' se han ido. Los otros ejemplos que proporcione dependen de su entorno: la congestión de red actual, si los servidores de back-end están sobrecargados, tarjetas de red mal configuradas, un cable defectuoso, la cantidad de otras personas que lo usan en su vecindad o cientos de otras variables. p.ej. nuestro proveedor de hosting cobraba extra por las conexiones de gigabit del servidor, pero finalmente determinamos que todo pasó por un antiguo dispositivo de firewall con puertos de 10Mb. Estos problemas cambian y son difíciles de encontrar.

De acuerdo, hay muchas cosas que los programadores pueden hacer (minimizar el ancho de banda, trucos de interfaz de usuario que mejoran la capacidad de respuesta y muestran progreso para dar la impresión de que es rápido). Pero cuando llegas al mundo real, hay todo tipo de circunstancias que solo aprendes por experiencia (y observas cómo tus suposiciones se desmoronan frente a ti).

¿Cuánto estás dispuesto a pagar por un mejor software? ¿Cuánto esperará el mercado por un mejor software? ¿Qué poco cruft querrá agregar a la próxima versión?

Es un mercado feroz por ahí donde se hacen muchos compromisos. Si es realmente una mierda, entonces el mercado fallará (o debería) fallar el producto. ¿Quizás haya suficientes clientes que puedan vivir con el status quo?

Creo que la respuesta más general a este problema es también la más difícil de administrar, que es que cada programador debe tener en cuenta el rendimiento con cualquier cosa que hagan. También me doy cuenta de que es un poco policía.

Dependiendo del tamaño del proyecto y del equipo correspondiente, creo que puede tener mucho valor tener programadores de rendimiento dedicados.

Como ejemplo, he trabajado en un equipo donde el equipo del proyecto (incluidos unos 30 desarrolladores) tenía al menos 2 personas dedicadas a la optimización del rendimiento. Esta aplicación en particular también era bastante propensa a problemas de rendimiento, ya que había multitud de componentes de interoperabilidad, no solo a través de servicios web, sino también en términos de capas heredadas con varios componentes de mapeo de datos y adaptador.

La experiencia de primera mano es importante. Proporcione a los desarrolladores una computadora rápida para compilar y construir, pero una computadora sobrecargada realmente lenta (como puede tener cierto porcentaje de usuarios) para ejecutar sus aplicaciones. (Esto se puede hacer en entornos de desarrollo basados ​​en la nube / servidor mediante la partición de máquinas virtuales o servidores por función). Déles un teléfono celular con una batería medio descargada y pídales que lo usen solo durante los días de prueba inicial de la aplicación móvil.

Si los desarrolladores simpatizan con el cliente con respecto al rendimiento y la duración de la batería, entonces no considerarán el rendimiento como una especificación de gestión semi falsa para colocar al final de la lista de prioridades. (Como en: "oye, pensé que era una optimización prematura" hasta demasiado tarde).

Deje de comprar las cosas y comente sobre el bajo rendimiento en las revisiones en línea que encuentre.

Si los dispositivos aún se venden, entonces el software es "lo suficientemente bueno" como para no invertir más tiempo y dinero. Si las malas críticas sobre el rendimiento reducen significativamente las ventas, entonces el software "no es lo suficientemente bueno" y necesita reparación.

Las únicas métricas que interesan a un productor de bienes de consumo son las ventas y las ganancias por unidad.

Estoy de acuerdo en que a los programadores se les debe enseñar mejor sobre cómo maximizar el rendimiento, etc.

Pero creo que la solución no está dando a los programadores un hardware casi agonizante para el uso diario. Qué estresante será si su estudio visual falla dos veces al día, tardó x segundos en construir el material, y segundos para abrir la solución, z segundos para cambiar las ventanas. Tampoco creo que haya sido muy rentable para la empresa, ya que el hardware es barato y el tiempo de los programadores es costoso.

Dado que la siguiente mano que manejará el código es el equipo de QA (prueba), ¿no sería mejor enseñarles sobre la importancia del rendimiento, tener un estándar de cuál es el estándar de rendimiento aceptable, etc., como un estándar empresarial (bueno, en un mundo perfecto , el estándar de rendimiento debe estar en las especificaciones, pero eso no sucede muy a menudo)? (es decir, la página / pestaña de cambio de ee empresarial normal debería ocurrir instantáneamente, "la actualización de guardado debe ocurrir en x segundos", si es una aplicación crítica, entonces ...). La computadora en la que se ejecutan los equipos de control de calidad debe ser la computadora de usuario típica. (no queremos molestarlos dándoles un 386, pero no les demos un núcleo cuádruple con 8 GB de ram por ejemplo). ¿No se desahogarían con los programadores si se cabrean lo suficiente con la actuación?

Creo que el cliente / gerente de proyecto debería obligar al programador / equipo qa / desarrollador / representante del equipo de la compañía a hacer su presentación en el hardware típico más bajo que tengan. (la computadora más débil de la empresa, por ejemplo). Si se reescribe, necesitarán recopilar datos sobre qué tan rápido es hacer el proceso x en el software anterior y compararlo con lo rápido que es en el nuevo software (podría ser más lento, ya que el nuevo software puede involucrar un proceso comercial adicional, pero debería haber una ventana aceptable).

Lo he dicho antes, pero lo diré de nuevo: creo que una de las mejores maneras de manejar esto es simplemente hacer que sus desarrolladores trabajen en hardware (relativamente) de última generación.

Para su programador típico, la mayoría de las consideraciones oficiales de rendimiento son secundarias a simplemente: "¿es molesto cuando intento ejecutarlo?" Si lo encuentran molesto, lo arreglarán (al menos intentarán). Si están contentos con la forma en que funciona, lo mejor que obtendrás es un intento poco entusiasta de arreglarlo. Esto también ayuda a encontrar problemas temprano, antes de que se vuelvan mucho más caros de solucionar.

Si llega al punto de que el control de calidad tiene que aplicar reglas en las que los desarrolladores realmente no creen porque piensan que el rendimiento es adecuado, es muy probable que la mayoría de las "soluciones" que obtenga obtenga formas creativas de eludir las reglas, No son soluciones reales que mejoran la vida del usuario final.

Al mismo tiempo, debo agregar que rara vez he visto esto como un problema. En todo caso, he visto a los desarrolladores pasar demasiado tiempo tratando de mejorar el rendimiento donde realmente no me importaba lo suficiente como para molestarme (un pecado del cual a menudo también soy culpable).