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

32

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?

Crashworks
fuente
2
Comentaristas: si te gusta la pregunta, vota. Si tiene una respuesta, déjela como una respuesta , no como un comentario. De lo contrario, solo deje un comentario si cree que la pregunta se aclaró o mejoró, o si tiene un enlace a un recurso relacionado.

Respuestas:

34

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.

MainMa
fuente
2
Respaldando este comentario, creo que la mejor manera de asegurar que al menos los desarrolladores (y probadores) estén al tanto de estos problemas es hacer que SIEMPRE prueben en hardware anterior o inferior de los requisitos o en Máquinas virtuales . Como desarrollador, es difícil para mí decir estas palabras, pero algunas veces no trabajamos para solucionar un problema hasta que lo experimentamos por nosotros mismos. Por lo tanto, al menos obligar a sus desarrolladores a probar sus aplicaciones en sistemas de baja calidad les obligará a encontrar soluciones eficientes debido al bajo rendimiento que experimentan directamente.
RLH
3
No sugeriría eso a diario, ya que disminuirá el rendimiento general del departamento de control de calidad y deprimirá a los empleados que trabajan en máquinas lentas. En mi humilde opinión, bastar las métricas de rendimiento como requisitos es suficiente, si se especifica correctamente (es decir, en qué máquina se debe realizar la prueba de rendimiento automática, con qué carga, cuántas veces tomar un promedio, etc.).
Arseni Mourzenko
1
Trabajo con un requisito que tiene un requisito de rendimiento formal (no funcional). Es un software vital en tiempo real. Las especificaciones son "respuesta dentro de x en promedio, y y 95% del tiempo". El software sigue siendo lento en comparación con lo que podría ser, pero sabemos cuándo mejorar el rendimiento, ya que se convierte en un defecto, al igual que cualquier otra cosa que el sistema hace incorrectamente. Dejar que los desarrolladores decidan es una muy, muy mala idea. La mayoría de los desarrolladores, dejaron allí sus propios dispositivos, más de ingeniero en todos los sentidos, y por triplicado con problemas de rendimiento.
mattnz
3
Otro problema con el rendimiento es que no puede probar el rendimiento en nada que no sea un sistema trivial hasta que se complete la integración final, a menudo mucho después de que los desarrolladores de software hayan terminado su trabajo. Tomar una aplicación de teléfono - funciona bien en escueto fábrica brillante nuevo teléfono, como algunas aplicaciones descargadas y la memoria se llena, y el desarrollador de software se le culpa de la escritura de software de mierda ......
mattnz
2
El problema aquí es que NUNCA obtienes "requisitos correctamente escritos y completos". No en una aplicación de cualquier tamaño o complejidad.
CaffGeek
12

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.

Jaap
fuente
Lo sé muy bien, solo cronometraje +1
mKorbel
8

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.

CaffGeek
fuente
3
¡Solo se arregla cuando el PM le da una "característica" llamada "rendimiento mejorado"!
FrustratedWithFormsDesigner
44
Para cuando el primer ministro quiera mejorar el rendimiento, la única forma real de hacerlo es reescribir :)
Job
El punto clave aquí es que para la mayoría de las aplicaciones de consumo, el rendimiento no es una característica que vende software. No es algo que se vea brillante en la lista de verificación de "Cosas que hace este software". Los juegos de computadora son un brillante ejemplo de este pensamiento. Los requisitos del sistema para juegos han aumentado constantemente con el tiempo, lo que significa que los juegos nuevos son más lentos con el mismo hardware que tenía antes, porque una velocidad de fotogramas más alta no va a mover esa caja del estante, sino entornos realistas renderizados en tiempo real con detalles fractales Will ...
Malachi
1
+1 Aquí es donde realmente ayuda tener un competidor con buen desempeño. Cuando los PM ven eso, se asustan y te piden que hagas algo al respecto.
Mike Dunlavey
1
@Chad, la probabilidad condicional es alta, pero la absoluta es baja. Trabajo en una aplicación que comenzó como un programa C de 16 bits para la versión de Windows "apenas después de nacer". Avance rápidamente hasta hoy y muchos años y docenas de programadores después, tiene una combinación de C, C ++, C #, VB.Net y muchos proveedores de SQL. Reescribir algunas partes clave de la aplicación en F # no parece una idea terrible ahora ...
Job
4

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 ...

Cualquiera lo puede hacer. Solo necesitan hacerlo realmente .

Mike Dunlavey
fuente
4

Haz que el rendimiento sea un requisito.

Robert Harvey
fuente
+1: es tan simple como eso. "La función X debe completarse en milisegundos Y".
don; no olvide especificar el entorno en el que se ejecutará; por ejemplo, tenemos un NFR que funcionaría según un estándar cuando se ejecuta en una red con una latencia de 40 ms (es decir, una WAN). Si no lo haces, los desarrolladores presentarán algo que solo funciona bien en una supercomputadora.
gbjbaanb
2

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.

Karl Bielefeldt
fuente
Además, incluso los grandes programadores necesitan una excelente instrumentación y herramientas de creación de perfiles para obtener información sobre los problemas de rendimiento. (Existen muchos paradigmas de programación con características de rendimiento que desafían el análisis de seguimiento de la pila). Estas herramientas generalmente están disponibles para las plataformas Linux en estilo de código abierto, pero en las plataformas patentadas y personalizadas, estas herramientas a menudo se les niegan a los empleados.
rwong
No estoy de acuerdo con el sentimiento expresado. Obtener el máximo rendimiento puede ser muy difícil, pero a menudo hay mucha fruta baja. Así que solo realice un perfil simple (tal vez la técnica que Mike Dunlavey sugirió anteriormente) e intente solucionar los problemas obvios. A menudo eso será de gran ayuda.
sleske
2

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

Tim Williscroft
fuente
2

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).

geoffjentry
fuente
2

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.

GNAT
fuente
downvoter: ¿se le ocurrió trabajar con probadores profesionales que cubren las necesidades del equipo de desarrollo en control de calidad y en pruebas de rendimiento? Si no, considere intentarlo
mosquito
1

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.

SoylentGray
fuente
1

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.

scunliffe
fuente
1

¿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).

jqa
fuente
Los ejemplos que di fueron todos los casos en que el rendimiento fue pobre en un entorno puramente local: el DVR se queda atrás al navegar por el menú de programas grabados localmente. iTunes es lento solo busca datos locales, no mira la tienda. Incluso en el "modo avión", sin ninguna red, el iPhone 3G tarda tanto en mostrar fotos que a veces el perro guardián del sistema operativo matará la aplicación antes de que pueda iniciarse. Todos estos son ejemplos de casos en los que los programadores sabían exactamente a qué hardware apuntaban cuando escribieron el código, y el iPhone, especialmente porque empeoró con cada actualización.
Crashworks
@Crashworks: alguien ha eliminado esos ejemplos de su pregunta. ¿Puedes agregarlos nuevamente con detalles? El ejemplo de la foto parece que está sucediendo algo más, como una dependencia que falta o está tratando de buscar algo en Internet y se está agotando el tiempo de espera. ¿Ha ejecutado una depuración para ver qué está pasando? Una buena historia es cuando MS lanzó HyperV, un revisor de VMWare señaló alegremente que a pesar de que lo instaló el día después de su lanzamiento, tuvo que descargar un montón de actualizaciones de Windows. ¿Por qué? el proceso de activación de HyperV reutilizó un dll IE8. Hay muchas trampas en entornos modernos.
jqa
1

¿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?

Paddy3118
fuente
0

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.

Wayne Koorts
fuente
0

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).

hotpaw2
fuente
0

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.

James Anderson
fuente
0

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).

Squee
fuente
-1

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).

Jerry Coffin
fuente
1
Es fácil caer en la trampa de obsesionarse con cosas que no importan, pero si un teléfono celular se envía con una IU tan lenta que las llamadas entrantes van al correo de voz antes de que el botón "Responder" responda, claramente alguien no pudo mejorar el rendimiento cuando lo hizo. importar.
Crashworks
44
En cuyo caso, la compañía debería comprarme una espada decente, porque voy a pasar la mayor parte de mi tiempo compilando.
David Thornley
La mitad del problema es que es difícil de probar en una máquina de desarrollo. Las máquinas de desarrollo tienden a ser grandes y rápidas, por lo que un desarrollador nunca verá el problema. Es difícil arreglar algo si no puede ver medir (verse afectado por) el problema y mucho menos cómo su solución cambiará el comportamiento.
Martin York
77
Esto fue sugerido en un comentario de Slashdot (sobre algo) años atrás. La respuesta fue: "los desarrolladores deben desarrollar en máquinas rápidas y probar en máquinas lentas".
user16764
1
@ user16764: A menudo se presta muy poca atención a dar a los desarrolladores entornos de prueba que son diferentes de su entorno de desarrollo. A mi esposa le costó mucho obtener una cuenta de administrador (para desarrollar) y una cuenta más limitada (para pruebas), y antes tenía problemas constantes para poner accidentalmente algo en una reparación de mantenimiento que no se ejecutaría en un usuario común cuenta.
David Thornley